⁃ Business requirements define what the organization wants or needs to be able to do

once the project is completed. They describe the changes in capabilities that will result from
the project. Technical requirements, on the other hand, define solutions for how each project
need will be satisfied.

A Business Requirement Document (BRD) focuses on the business perspective as it holds the
details of the business solution for a project.” Business requirements document also
emphasizes on the needs and expectations of the customer. In simpler terms, BRD indicates
what the business wants to achieve.

What should a business requirements document include?

Your business requirements document template should provide detail about your project, but
it should also be concise. The goal of the BRD is to give readers the most information in the
least amount of words.

Many people may read a BRD, including stakeholders involved in the project, executives you
need approval from, and clients influenced by the end results. Learn more about each
component to include in your template below.
1. Executive summary
The executive summary is a high-level statement outlining what your project is and its
purpose. Those who don’t have time to read the BRD in its entirety should understand what
you plan to accomplish by reading your executive summary.
Even though your executive summary is the first thing in your BRD, you should actually only
write it after writing the other sections. That way, you can review everything and ensure you’ve
created a comprehensive opening statement.
Read: How to write an executive summary, with examples

2. Project objectives
Your project objectives are the business goals you want to achieve by putting your project
into action. It’s important to state your project objectives before kicking off any work so you
can use them to measure your progress.
List your project objectives as SMART goals to ensure that they’re:
• Specific
• Measurable
• Achievable
• Relevant
• Time-specific
Measuring your project objectives can help determine whether you need to adjust your
workflow to better meet your goals. For example, if one of your objectives was to increase
your customer base by 10% by the end of the quarter, you can look at your numbers when the
quarter ends and clearly see whether you hit your goal or not. You can then look at the actions
you took along the way and determine the reasons why you may have fallen short.
3. Project scope
Your project scope communicates the boundaries of your project on your business
requirements document. By defining your project scope, you’ll keep everyone on the same
page and prevent scope creep, which is when your project expands outside of the boundaries
you set for it and becomes hard to control.
Details to outline in your project scope include:
• Timeline
• Budget
• Deliverables
• Project requirements
• Project team
You can also make a list of project exclusions—or things you specifically want to leave out of
your project—like business processes or risky strategies you want others to avoid when
they’re working on the project.
4. Business requirements
The business requirements are the meat of your BRD template. In this section, you’ll list the
actions required to accomplish your project. Depending on the project complexity, this list
may be just a few items or it may be extensive.
In addition to listing your requirements and describing them, rank them by priority and assign
each item a level of importance based on how critical they are. This will help others
understand which requirements they need to complete first.
If one of your requirements is to code a website, you may assign this task as a number one
priority. You can also label this task as highly critical because, without coding your website,
you won’t have a foundation to complete other business requirements.
5. Key stakeholders
Project stakeholders include anyone with an interest in your project. These are likely the
people who will read your BRD template to understand what the project is about. Your key
stakeholders may be:
• Team members working on the project
• Project managers leading the project
• Executives approving the project
• Clients influenced by the finished project
In this section, list the names and job roles of each stakeholder and describe their duty in
relation to the project. This section will give everyone clarity on who else is involved and can
improve team communication.
Read: What is a project stakeholder analysis and why is it important?

6. Project constraints
You likely presented an overview of your project constraints within your project scope, but
here, you’ll explain these boundaries in more detail. When the reader reviews this section, they
should see the shape of the project and its limits.
Project constraints may include:
• Project risks
• Team availability
• Resources
• Project dependencies
• Deadlines
• Project budget
Project constraints help stakeholders visualize the complexity of the project and how easy it
will be to achieve project objectives. Anyone involved in the project should first review the
project constraints.
7. Cost-benefit analysis
Ending your business requirements document with a cost-benefit analysis is a strategic move.
If you’re using your BRD to get approval for your project, this section may be the deciding
factor. Clients and executives care about the project objective, but if you can’t prove that
you’ll make a profit, then all is lost.
To create a cost-benefit analysis:
• Describe all the costs associated with your project
• Explain the associated benefits
• Write the total expected cost of your project
• Estimate the expected ROI by subtracting your estimated costs from your estimated
income

-FUNCTIONAL REQUIREMENTS DOCUMENT

FUNCTIONAL REQUIREMENTS DOCUMENT
Overview
The functional requirements document (FRD) is a formal statement of an application’s
functional requirements. It serves the same purpose as a contract. The developers agree to
provide the capabilities specified. The client agrees to find the product satisfactory if it
provides the capabilities specified in the FRD.

Quality is meeting requirements. For that reason, the FRD is the central document in system
development. It is used for the following:

• Designing and developing tile application system.

• Evaluating the product in all subsequent phases of the life cycle.
• Determining the success of the project.

The FRD has the following characteristics:

• It demonstrates that the application provides value to the State in terms of the business
objectives and business processes in the 5-year plan.
• It contains a complete set of requirements for the application. It leaves no room for anyone
to assume anything not stated in the FRD.
• It is solution independent. The ERD is a statement of what the application is to do—not of
how it works. The FRD does not commit the developers to a design. For that reason, any
reference to the use of a specific technology is entirely inappropriate in an FRD.

A requirement is a condition that the application must meet for the customer to find the
application satisfactory. A requirement has the following characteristics:

• It provides a benefit to the organization.

• It describes the capabilities the application must provide in business terms.
• It does not describe how the application provides that capability.
• It does not describe such design considerations as computer hardware, operating system,
and database design.
• It is stated in unambiguous words. Its meaning is clear and understandable.
• It is verifiable.

1 GENERAL
1.1 Project Description
Provide a brief overview of the project.
1.1.1 Background
Summarize the conditions that created the need for the application.
1.1.2 Purpose
Describe the business objectives and business processes from the CONOPS document and
the CBA that this application supports.
1.1.3 Assumptions and Constraints
Assumptions are future situations, beyond the control of the project, whose outcomes
influence the success of a project. The following are examples of assumptions:

• Availability of a hardware/software platform

• Pending legislation
• Court decisions that have not been rendered
• Developments in technology

Constraints are conditions outside the control of the project that limit the design alternatives.
The following are examples of constraints:

• Government regulations
• Standards imposed on the solution
• Strategic decisions
Be careful to distinguish constraints from preferences. Constraints exist because of real
business conditions. Preferences are arbitrary. For example, a delivery date is a constraint
only if there are real business consequences that can happen as a result of not meeting the
date. For example, if failing to have the subject application operational by the specified date
places the State in legal default, the date is a constraint. A date chosen arbitrarily is a
preference. Preferences, if included in the FRD, should be noted as such.
1.1.4 Interfaces to External Systems
Name the applications with which the subject application must interface, State the following
for each such application:

• Owner of application (if external to the Agency)

• Details of interface (only if determined by the other application)
1.2 Points of Contact
List the names, titles, and roles of the major participants in the project. At a minimum, list the
following:

• Project Manager
• Development project leader
• User contacts
• Agency employee whose signature constitutes acceptance of the FRD
1.3 Document References
Name the documents that were sources of this version of the FRD. Include meeting
summaries, white paper analyses, and other System Development Life Cycle deliverables, as
well as any other documents that contributed to the FRD. Include the Configuration
Management identifier and date published for each document listed.
2 FUNCTIONAL REQUIREMENTS
The functional requirements describe the core functionality of the application. This section
includes the data and functional process requirements.
2.1 Data Requirements
Describe the data requirements by producing a logical data model, which consists of entity
relationship diagrams, entity definitions, and attribute definitions. This is called the
application data model. The data requirements describe the business data needed by the
application system. Data requirements do not describe the physical database.
2.2 Functional Process Requirements
Process requirements describe what the application must do. Process requirements relate
the entities and attributes from the data requirements to the users’ needs.

State the functional process requirements in a manner that enables the reader to see broad
concepts decomposed into layers of increasing detail.

Process requirements may be expressed using data flow diagrams, text, or any technique that
provides the following information about the processes performed by the application:

• Context
• Detailed view of the processes
• Data (attributes) input to and output from processes
• Logic used inside the processes to manipulate data
• Accesses to stored data
• Processes decomposed into finer levels of detail
3 OPERATIONAL REQUIREMENTS
Operational requirements describe the non-business characteristics of an application.

State the requirements in this section. Do not state how these requirements will be satisfied.
For example, in the Reliability section, answer the question, “How reliable must the system
be?” Do not state what steps will be taken to provide reliability.
Distinguish preferences from requirements. Requirements are based on business needs.
Preferences are not. If, for example, the user expresses a desire for sub-second response
but does not have a business-related reason for needing it, that desire is a preference.
3.1 Security
The security Section describes the need to control access to the data. This includes
controlling who may view and alter application data.

State the consequences of the following breaches of security in the subject application:

• Erasure of contamination of application data

• Disclosure of Government secrets
• Disclosure of privileged information about individuals

State the type(s) of security required. Include the need for the following as appropriate:

State if there is a need to control access to the facility housing the application.

• State the need to control access by class of users. For example, “No user may access any
part of this application who does not have at least a (specified) clearance.”
• State the need to control access by data attribute. State, for example, if one group of users
may view an attribute but may not update it while another type of user may update or view it.
• State the need to control access based on system function. State for example, if there is a
need to grant one type of user access to certain system functions but not to others. For
example, “This function is available only to the system administrator.”
• State if there is a need for accreditation of the security measures adopted for this
application. For example, C2 protection must be certified by an independent authorized
organization.
3.2 Audit Trail
List the activities that will be recorded in the application’s audit trail. For each activity, list the
data to be recorded.
3.3 Data Currency
Data currency is a measure of how recent data are. This section answers the question,
“When the application responds to a request for data how current must those data be?”
Answer that question for each type of data request.
3.4 Reliability
Reliability is the probability that the system will be able to process work correctly and
completely without being aborted.

State the following in this section:

• What damage can result from this system’s failure?

o Loss of human life
o Complete or partial loss of the ability to perform a mission-critical function
o Loss of revenue
o Loss of employee productivity

• What is the minimum acceptable level of reliability?

State required reliability in any of the following ways:

• Mean Time Between Failure is the number of time units the system is operable before the
first failure occurs.
• Mean Time To Failure is computed as the number of time units before the system is
operable divided by the number of failures during the time period.
• Mean Time To Repair is computed as the number of time units required to perform
system repair divided by the number of repairs during the time period.
3.5 Recoverability
Recoverability is the ability to restore function and data in the event of a failure. Answer the
following questions in this section:

• In the event the application is unavailable to users (down) because of a system failure, how
soon after the failure is detected must function be restored?
• In the event the database is corrupted, to what level of currency must it be restored? For
example “The database must be capable of being restored to its condition on no more than
one hour before the corruption occurred.”
• If the process site (hardware, data, and onsite backup) is destroyed how soon must the
application be able to be restored?
3.6 System Availability
System availability is the time when the application must be available for use. Required
system availability is used in determining when maintenance may be performed. In this
section state the hours (including time zone) during which the application is to be available to
users. For example, “The application must be available to users Monday through Friday
between the hours of 6:30 a.m. and 5:30 p.m. EST.” If the application must be available to
users in more than one time zone state the earliest start time and the latest stop time.

Include the times when usage is expected to be at its peak. These are times when system
unavailability is least acceptable.
3.7 Fault Tolerance
Fault tolerance is the ability to remain partially operational during a failure. Describe the
following in this section:

• Which functions need not be available at all times?

• If a component fails what (if any) functions must the application continue to provide? What
level of performance degradation is acceptable?

For most applications, there are no fault tolerance requirements. When a portion of the
application is unavailable there is no need to be able to use the remainder for the application.
3.8 Performance
Describe the requirements for the following:

• Response time for queries and updates

• Throughput
• Expected volume of data
• Expected volume of user activity (for example, number of transactions per hour, day, or
month)
3.9 Capacity
List the required capacities and expected volumes of data in business terms. For example,
state the number of cases about which the application will have to store data. For example,
“The project volume is 600 applications for naturalization per month.” State capacities in
terms of the business. Do not state capacities in terms of system memory requirements or
disk space.
3.10 Data Retention
Describe the length of time the data must be retained. For example, “information about an
application for naturalization must be retained in immediately accessible from for three years
after receipt of the application.”
4 REQUIREMENTS TRACE ABILITY MATRIX
The requirements trace ability matrix (RTM) provides a method for tracking the functional
requirements and their implementation through the development process. Each requirement
is included in the matrix along with its associated section number. As the project progresses,
the RIM is updated to reflect each requirement’s status. When the product is ready for system
testing, the matrix lists each requirement, what product component addresses it, and what
test verify that it is correctly implemented.

Include columns for each of the following in the RTM:

• Requirement description
• Requirement reference in FRD
• Verification Method
• Requirement reference in Test Plan
5 GLOSSARY
Include business terms peculiar to the application. Do not include any technology-related
terms.

-What is Statement of Work (SOW)?

A statement of work (SOW) is a document that provides a description of a given project's
requirements. It defines the scope of work being provided, project deliverables, timelines,
work location, and payment terms and conditions.

Statement of work management is simply the process for ensuring the agreed-upon scope of
services within the SOW are being completed on time and on budget. Whomever is
responsible for SOW management is responsible for creating efficiencies, risk mitigation, any
special requirements, and supplier management and negotiations. Ultimately, finding savings
opportunities and reporting on a project's overall success. SOWs are commonly used along
with a:
Request for Proposal (RFP)
Organisations typically use this document to request pricing, provide requirements, and
define a period of performance. Enough information that a service provider can respond back
with an accurate bid for a project.

Master Services Agreement (MSA)

This is the governing document that outlines two parties’ terms and conditions for an entire
relationship. The statement of work document usually only covers details belonging to a
single project or scope of work.

How are SOWs created?

There are many SOW templates available to help get managers started. However, to write a
statement of work can be somewhat complex. Getting everything included to ensure the
scope of services is detailed enough is critical.
Elements of an SOW can include:
• Purpose of the project
• Scope of work being performed
• Location of the project, project length, and any work requirements
• Expected deadlines and deliverables
• Acceptance criteria
• Any hardware and software required
• Performance-based standards to be met
Creating a thorough SOW can eliminate the risk that can come if there are any
misunderstandings or disputes between parties on any of the elements above.

A concise and well written SOW, mitigates the risk of overspend by ensuring both supplier and
organisation have a clear understanding of, and accountability for, the work involved.
Bolstering the upfront agreement, lessens the opportunity for misunderstandings resulting in
contract extensions and associated costs.
What are the different types of SOWs?
There are three standard SOW categories that companies use for defining scope and
procuring services. Some are more popular than others within certain industries, but they all
have similar components that define its success.

1. Design or detail statement of work

2. This category of SOW defines the exact requirements needed to complete a project.
It tells the supplier exactly how to do the work and what processes to follow.
3. Additionally, it defines all requirements and any specific industry-related regulations
that must be followed by the contractors. Typically, the organisation using design SOWs
assumes most of the risk for the project.
4. Level of effort
5. This SOW is used for any kind of service. In a very general way, it details work hours
and any material needed to perform the service over a given time.
6. Performance-based statement of work
7. A performance-based SOW clearly lays out the project’s purpose, resources that will
be provided, and deliverables that will be accomplished. But it does not provide details about
how the work needs to be performed
8. This is the preferred SOW for most companies. This SOW offers the most flexibility,
focuses on project outcomes, and shares risk between parties.

What are the benefits of managing SOWs?

• Benefits can include:
• Increased cost savings opportunities
• Supplier performance and risk mitigation
• Greater process efficiencies
• Detailed reporting
• Project performance management
• Visibility into all outsourced projects within a single purview
• Improved workforce management
• Organisational compliance and risk mitigation
Providing successful SOW management gives hiring managers the tools necessary to make
informed buying decisions and maximises productivity throughout an organisation.

Additionally, unexpected circumstances, scope creep, and post-contract changes can require
amendments to the original SOW. Strong SOW management offers the tracking and reporting
necessary to enable business leaders to make such changes.

It also provides confidence that the project will be delivered on time and within budget.

Can SOWs be managed through an MSP/VMS?

The short answer is, yes - and they should be. It is important to have one central technology
platform that can house SOWs and a service to provide SOW management, like those offered
by an MSP. This ensures:
• Visibility, analysis, and reporting for strategic decision-making
• Competitive sourcing, where relevant, to capture cost savings and improve controls
around compliance and budget
• Management of deliverables and payments for spend transparency
• Supplier performance management, optimisation, and accountability
• Organisational efficiencies and project management
• Processing rigor and consistent application of an organisation’s policies and
procedures
• Total talent management

-The Scope of Work

is the area in an agreement where the work to be performed is described. The SOW should
contain any milestones, reports, deliverables, and end products that are expected to be
provided by the performing party. The SOW should also contain a time line for all deliverables.
The problem with most Scopes of Work is a lack of specificity, namely, when the two parties
disagree on what should have been delivered and a review of the SOW does not support one
interpretation over the other. This problem is common in research agreements and is often
where disputes arise. The best way to avoid this problem is to avoid any and all ambiguity.
A Scope of Work should include the following components:
1. Glossary
2. ProblemStatement
3. GoalsoftheAgreement
4. ObjectivesoftheAgreement/Deliverables 5. Administration
6. Timeline.
1. Glossary
In the Glossary, spell out each acronym used in the SOW. Also include definitions of odd or
unusual terms. Think about the document from the perspective of someone who does not
work in the particular industry or discipline.
2. Problem Statement
Succinctly describe the problem that this research will address (1 or 2 paragraphs is fine).
Describe the scientific and technological baseline, that is, the current state-of-the-art or
developmental status of the field to be advanced.
3. Goals of the Agreement
At the beginning of this section, complete the following sentence (please be succinct): The
goal of this project is to...

Complete the sentence with a brief description of the goal(s) and how the goal(s) will be met.
Goals can be technical, economic or social. Please be brief, two to three sentences maximum.
4. Objective of the Agreement/Deliverables
Complete this section with the objectives of the project, which are things that will be
measurable or knowable at the end of this agreement—this is where the deliverables should
be listed. Deliverables are comprised of a task and an end product.
Poor Example:
Task: Assess class needs for public health awareness. Deliverable: Write curriculum to
address needs.
The problem with the above example is that nothing is specified. The task should have
measurable in it and the deliverable must be quantifiable.
Good Example:
Task: Survey 4 classes of 20 students in asthma awareness. Each class will answer a 25
question survey that assesses their general knowledge of asthma issues as they relate to
public health. One reviewer should take about 1 hour with each class to take the survey and
another 2 hours per class to assess the data.
Deliverable: A 10-hour curriculum for graduate student classes of up to 20 students that
addresses issues of deficiencies in public health awareness in asthma prevention and care.
By reading the task and deliverables, the administrative personnel should be able to construct
the budget associated with the SOW. More importantly, in reviewing the deliverables, there
should be no question about what is expected of the performing party. A SOW may contain
many deliverables, but each should be broken down into tasks and end products to specify
what is expected.

5. Administration
If there are meetings, calls, conferences, or other “soft” deliverables, they should be outlined
in the administration portion of the SOW. Any requirement that is not an end product of a
specific task, but is required of the performing party, needs to be described in the
administration section of the SOW.
Poor Example:
PI will be required to give weekly reports of progress during the soy bean season with more
frequent reports during the height of the season.
The problem with the above example is that it does not specify what needs to be in the
reports, what “more frequent” means, and when the “height of the season” is.
Example:
PI will be required to give weekly reports consisting of: wind pattern analysis, fungi spore
distribution, and potential risk areas. During the height of the season, May 15-July 15, the PI
may be required to give twice-weekly reports.
6. Timeline
This section lays out all dates for the project. It states dates for the tasks and deliverables. It
also covers the dates for the administration portion of the SOW.
Between the Glossary, Problem Statement, Goals of the Agreement, Objectives /Deliverables,
and Administration components of the SOW, there should be no ambiguity as to what is
expected of the performing party. Together, these elements should paint a thorough picture
of
-Terms of reference are important to set expectations and constrain scope
A terms of reference (ToR) is a document which articulates the scope of work for a taskforce
and how the people identified in the ToR will work together in the pursuit of a shared goal.
A ToR should clarify the expectations of project sponsor(s) (the senior executive(s) with
overall accountability for the project), key stakeholders and taskforce members about what
will be delivered by when, and how work will proceed. It should also constrain the scope of the
taskforce so that the highest value work follows – it’s better to have a well-defined scope that
leads to a high impact policy outcome than a broad scope that yields little value in its
deliverables.
The origins of taskforces vary and in some cases, a ToR may have been settled before a
taskforce is established. If this is the case, problem definition is still an important step – the
ToR is often high level and further clarity is often needed.
If you do have the opportunity to develop the terms of reference directly, the examples and
guide on writing one in 60 minutes will help you with this process.
Best practice for terms of reference
Develop one early. A ToR should be developed, tested and agreed before a significant amount
of work is undertaken. Where possible a ToR should be tested and refined with key
stakeholders to build consensus about the key issues and end goals.
Specify clear deliverables. A ToR should outline the specific outputs the taskforce needs to
deliver and the timeframe to undertake the work.
Clarify how decisions will be made. It is often necessary to distinguish between decision
makers responsible for taking action versus those responsible for the day-to-day operations
of a taskforce. Other people may contribute in an advisory capacity only.
Focus on key issues and expectations. A ToR should outline any specific expectations about
the work of the taskforce. This may include key issues (or those out of scope), the nature of
any problem solving processes, the people to be involved or the solutions to be explored. The
scope of a ToR should reflect the quantum of resources available to deliver the work.

-Request for information

is a formal process for gathering information from potential suppliers of a good or service.
RFIs are intended to be written by customers and sent to potential suppliers. An RFI is
typically the first and most broad series of requests intended to narrow down a list of
potential vendor candidates.
RFIs can be useful in situations where an organization has little knowledge on possible
vendors and wants to reduce the time and cost of evaluating vendors.
RFIs are often used in a variety of instances, for example, in making major IT purchases. The
goal of using an RFI is to gather information on a market in a formal, structured way. The
document should identify the requirements an organization has while requesting specific
answers to how the vendor will meet them.
To help identify differences among vendors, a good RFI will also focus on requirements that
are unique to the inquiring business and on concerns that are less likely to be addressed by
every vendor.
Recipients are usually asked to submit their responses in a standard format to make
comparisons easier.
Areas of use
RFIs can be used in a number of scenarios such as in IT, ad agencies and in construction
industries. RFIs can also aid in choosing tools for enterprise resource planning (ERP) and
electronic health records (EHRs).
In the IT sector, RFIs are typically used to acquire software from vendors. The software will
typically be used for a long period of time, so it's important that an organization is sure to
select from the right vendor. The RFI should make clear business requirements such as
integrations with other software or hardware, use cases or management options.
In construction, RFIs may be sent by a contractor to a designer, from the contractor to a client,
from a subcontractor to a client, or from a subcontractor to the main contractor. Typically,
RFIs in construction will be used before quoting and onward. Here, an RFI should be
submitting queries regarding materials, specifications, design drawings, standards or
contract information.
Add agencies may use RFIs to evaluate advertising agencies. In this case, the RFI will ask for
a list of industry-specific clients, areas of conflict and relevant areas the vendor may excel in.
An organization that wants to make use of an ERP software may also make use of an RFI.
RFIs in this area should specify the criteria regarding what an organization needs in its ERP
system. For example, this could be areas surrounding accounting, manufacturing and
inventory management, sales management, and human resources technology. ERP RFIs tend
to be more thorough than others.
Health industries looking for software surrounding EHRs may also use RFIs. In this case, an
organization should ask for information regarding functional, technical and operational
requirements.

-Request for Proposal (RFP)

A request for proposal (RFP) is both the process and documentation used in soliciting bids
for potential business or IT solutions required by an enterprise or government agency. The
RFP document typically outlines a statement of requirements (SOR) to be met by prospective
respondents wishing to make a bid to deliver the required solutions. It might cover products
and/or services to meet the given requirements. The RFP documentation also typically covers
the related procurement process, evaluation criteria, commercial terms and conditions,
timeliness and activities involved, and what respondents should include in their RFP response.

-Request for tender

a call for bids or a request for tenders) is a formal, structured procedure for generating
competing offers from different potential suppliers or contractors looking to obtain an award
of business activity in works, supply, or service contracts, often from companies who .

-Request for quote (RFQ) is a process wherein an enterprise asks a set of potential suppliers
or service providers to submit their price quotations and stand a chance to supply or provide
goods or services. A request for quote (RFQ), also known as an invitation for bid (IFB), is a
process in which a company solicits select suppliers and contractors to submit price quotes
and bids for the chance to fulfill certain tasks or projects.

-A Register of Interests

is a record kept, usually by a government body, of financial interests of its members. The
register documents interests which may potentially unethically or unlawfully influence
members' official duties.
The term is in use in most Commonwealth countries At the start of a new Parliament MPs
have one month in which to make their first registration. After that, MPs must register within
28 days any interest which someone might reasonably consider to influence their actions or
words as an MP. The detailed rules are set out in the Guide to the Rules relating to the
conduct of Members.
Parliament publishes these interests in the Register of Members' Financial Interests, which is
maintained by The Parliamentary Commissioner for Standards. The Register is updated on
the parliamentary webpages every two weeks during sitting periods and approximately once a
month at other times. Entries remain for twelve months after they have expired.
Political parties have separate arrangements for reporting donations, and these are
published on the webpages of the Electoral Commission, although if a donation is linked to a
Member he or she may also need to include it in their Register entry. The Ministerial Code
requires Government Ministers to disclose their interests in detail. These interests are
published by the Government.

-A master service agreement

sometimes known as a framework agreement, is a contract reached between parties, in

which the parties agree to most of the terms that will govern future transactions or future
agreements.
A master agreement delineates a schedule of lower-level service agreements,[1] permitting
the parties to quickly enact future transactions or agreements, negotiating only the points
specific to the new transactions and relying on the provisions in the master agreement for
common terms. This master agreement can be used to mediate employer-employee conflict
in the workplace by having a reference point to work out solutions and set specific terms.
Contracts in the information technology, contract research, and similar "open ended" fields
are often negotiated as a "Master Service Agreement" and a "Statement of Work".

-Types of service level agreements

When you create a service level agreement, you must assign a type. The type enables you to
sort or search for service level agreements by type.
The following list describes the three predefined types for service level agreements:
• A customer service level agreement is an agreement between you and an
external customer. For example, a facilities manger provides maintenance services for
various customers.
• An internal service level agreement is an agreement between you and an
internal customer (such as another organization, site, or department). For example, you are
the facilities manager and provide maintenance services for the departments in your
company.
• A vendor service level agreement is an agreement between you and the
vendor. For example, you hired a vendor to support notebook services. If you have a contract
with another vendor that supports your commitments to a customer, you can associate the
contract to a vendor service level agreement.
The three types of service level agreements can support each other. For example, you have an
internal service level agreement to provide hardware services to support internal departments.
You also have a vendor service level agreement for notebook support.
• Commitments for service level agreements When you create a service level
agreement, you specify the commitments that you agreed to fulfill for external or internal
customers. A commitment is a level of service that is agreed upon between the service
provider and the customer that can be measured in a qualitative or quantitative way.
• Assets and locations associated with service level agreements In the
Service Level Agreements application, you associate specific assets, asset types, and
locations to a service level agreement. After you activate a service level agreement and the
associated escalation, the service level agreement is applied to any listed assets, asset types,
and locations.
• Service level agreements and other applications To ensure compliance
with service level agreements, you can apply valid service level agreements to records from
other applications.

-Business Case

A common way of thinking about a business case is using these five elements:
1. Strategic context: The compelling case for change.
2. Economic analysis: Return on investment based on investment appraisal of options.
3. Commercial approach: Derived from the sourcing strategy and procurement
strategy.
4. Financial case: Affordability to the organisation in the time frame.
5. Management approach: Roles, governance structure, life cycle choice, etc.
The business case is reviewed and revised at decision gates as more mature estimates and
information become available. The approved business case provides a record of the
decisions made by governance about how to achieve the required return on investment from
the work. It documents the options considered and it is normal practice to include the ‘do-
nothing’ option as a reference. Through this approach, the business case becomes a record
of the recommended option with rationale and evidence to support the decision.
The presentation of the business case, if approved, results in the formal startup of the project,
programme or portfolio. The sponsor owns the business case.
It brings together the investment appraisal with evidence of how the investment is intended to
lead to realisation of the intended benefits. All projects must have a business case that
demonstrates the value of the work and it is outlined during the concept phase of the life
cycle.

⁃ Product requirements
A product requirements defines of a particular product, including the product’s purpose,
features, functionality, and behavior. It serves as a guide for business and technical teams to
help build, launch, or market the product.
Building a great product requires tons of research and comprehensive planning. But where do
you start? Product managers often start with a product requirements document (PRD).
A product requirements document defines the product you are about to build: It outlines the
product's purpose, its features, functionalities, and behavior.

Next, you share the PRD with (and seek input from) stakeholders - business and technical
teams who will help build, launch or market your product.
Once all stakeholders are aligned, the PRD serves as a compass, providing clear direction
toward a product's purpose while creating a shared understanding among business and
technical teams.
Gathering requirements in an agile world
What does the requirements gathering process look like in an agile world? It sounds tricky -
and it is. But don't worry. At Atlassian, we know all about creating PRDs in an agile
environment. Here are a few things to keep in mind:
Agile requirements are a product owner's best friend. Product owners who don't use agile
requirements get caught up with spec'ing out every detail to deliver the right software (then
cross their fingers hoping they've spec'ed out the right things). Agile requirements, on the
other hand, depend on a shared understanding of the customer that is shared between the
product owner, designer, and the development team. That shared understanding and empathy
for the target customer unlocks hidden bandwidth for product owners. They can focus on
higher-level requirements and leave implementation details to the development team, who is
fully equipped to do so – again, because of that shared understanding. (Boom.)
Creating a shared understanding among teams
If you're excited by the idea of a shared understanding, but haven't a clue how to create it, try
some of these tips:
• When conducting customer interviews, include a member of the design and
development teams so they can hear from a customer directly instead of relying on the
product owner's notes. It will also give them the chance to probe deeper while the topic is
fresh in the customer's mind. Make developing and using customer personas a team effort.
Each team member has unique perspectives and insights, and needs to understand how the
personas influences product development.
• Make issue triage and backlog grooming a team sport as well. These are great
opportunities to make sure everyone is on the same page, and understand why the product
owner has prioritized work the way they have.

⁃ What are project requirements

Project requirements are the features, functions, and tasks that need to be completed for a
project to be deemed successful (or to at least be wrapped up). They give everyone involved a
clear set of parameters to work toward and determine the various goals for stakeholders to
complete.
 ⁃ Stakeholder requirements Stakeholder requirements define
decisions about business needs, goals, and objectives from the perspective of the
stakeholders and their role in the business. Stakeholder requirements are expected to
decompose the business requirements.

⁃ Enterprise Environment Factors (EEF)

You need different approaches to deal effectively with the cultural, political, and legal
environments the project is operating within the organization. Enterprise Environment Factors
(EEFs) include all policies, practices, procedures, and legislation that exist both inside and
outside of the organization that will impact the way you manage a project.
This ranges from environmental, anti-discrimination, and occupational health and safety
legislation to the choice of the project management system used by the organization, its
personnel management policies, and PMI’s Code of Ethics. Some elements of the EEF are
mandatory, while others represent good practice or cultural norms. But regardless of the
nature of the factor, you have to work within the physical and cultural environment to be
effective.

-Organizational Process Assets (OPA)

Most organizations have developed a range of templates, contracts, registers, and

assessment tools to assist the management of their projects. Organizations have also
acquired knowledge in the form of lessons learned—and the organization’s knowledge base
that can be very useful.
Therefore, Organizational Process Assets would include anything the organization has
acquired that you can use in the management of the project. They include formal and
informal plans, policies, procedures, and guidelines. These are very important for the planning
stage, irrespective of the nature of the project. Whether your project is long-term or short-
term, OPAs are a must.
Here’s a list of common OPAs:
• Standardized guidelines
• Proposal evaluation criteria
• Work breakdown structure templates
• Project schedule network diagram templates
• Risk templates
• Organizational standard processes
• Project closure guidelines
• Defect management processes
• Lessons learned and historical databases
• Change control procedures
• Financial control procedures
• Project files