Business Requirements Package

Business Requirements Template

v v v

Template courtesy of Watermark Learning Watermarklearning.com/Resources

1
Business Requirements Package

Related Documents
The requirements package is the principal set of documents delivered at the end of the
Business Requirements Definition phase. It is comprised of information provided by the
business clients and which needs to be approved by them.

There are other project documents that are different from but closely related to the
requirements package. One is the document created by and used by the project manager to
ensure that the project is managed by planning, executing and controlling the project. This set
of documents is the Project Plan and includes the project baselines of scope, schedule and
budget, as well as several management plans.

Another related document is the Test Plan, which is really a series of documents, ensuring that
the project is thoroughly tested before being implemented and that all the identified
requirements work as designed.
A third is the Training Plan, which includes training plans and strategies, detailing
who will be trained and by whom, what materials will be used and when the training
will occur.

© Watermark Learning Business Requirements

Requirements Package
2
Business Requirements Package
Business Requirements Package
Purpose
The Business Requirements Package is the end deliverable of the Business Requirements
Definition phase. It serves as a communications vehicle for everyone affected by the project.
It summarizes the analysis that has been completed to date, but is a living document that
changes as new information is added and as approved changes in functionality and scope
occur. Its audience is everyone who is affected by the development effort. Its purpose is to:

 Provide detailed view of the project.

 Build partnerships with other areas of the organization.
 Improve quality by catching and correcting errors, invalid assumptions, etc. early in
project development.
 Provide impacts to other areas.
 Provide building blocks for completing specifications and the development of the product.

Audience
The requirements package will no doubt have a variety of different audiences, ranging from
executives who want very little detail to technicians who want a great deal of it. As with
similar documents, it is important to gear the information to the audience. Since
communication objectives are different for the various readers, it is necessary to provide all
things, but to do so in a way that those who want detail get it and those who don’t can get a
summary. Using a series of attachments helps the audience focus on the sections most
important to them.

Developing a requirements package

The format of the requirements package can vary, but the key is to make it interesting and
easy-to-read, with white space and bullets, as opposed to dense text.

One or several project stakeholders should assist in developing the requirements package; it is
essential to get client input. Ideally, getting the client to actually develop parts of the
document is very helpful.

As the project progresses and more details become known, the requirements package gets
updated with that information. It is not necessary to re-send the entire document with the
added details to those who are not interested, but it is advisable to ensure that your technical
partners receive it.

Template courtesy of Watermark Learning Watermarklearning.com/Resources

3
Business Requirements Package
Reviewing and Approving
Every key stakeholder needs to review the requirements package, which should not contain
any surprises to any of them. A large group meeting should be scheduled when there is
general agreement in principle to the information in the document. However, a good tip in
developing the requirements package is to first meet in small groups to get stakeholders’ input
and buy-in. Have a non-stakeholder and non-project team member read the final proof to
check grammar, spelling and overall readability.

The requirements package needs formal approval, which includes obtaining signatures from at
least the executive project sponsor and other key stakeholders. This document becomes the
baseline for the scope of the requirements, against which the product scope will be measured,
making signoff on the document essential.

© Watermark Learning Business Requirements

Requirements Package
4
Business Requirements Package

Project Introduction
The project documentation links the requirements document to the project documentation,
specifically the Scope Statement. This section is, then, a summary of the project Scope
Statement.

BUSINESS PROBLEM(s)
Detail why this project is necessary and the limitations of the current situation--what about the
existing processes and systems causes the need for change. A clear statement of the problem,
as well as the kinds of headaches caused by the problem, becomes the foundation of the
business case for doing the project.

PURPOSE AND OBJECTIVES

Indicate the reason the project is needed, tying into the above current system limitations.
Objectives describe business strategies and are best stated in business terms.

LINK TO BUSINESS OBJECTIVES (can refer to traceability matrix)

SCOPE AND DELIVERABLES

Describe the features, functions and deliverables both included in and excluded from this
project

APPROACH
Describe the project strategies, such as:

 Project methodology to be used (Traditional. RAD, Packaged Software, etc.)

 Testing strategies
 Implementation strategies
 Knowledge transfer
 Conversion strategy - if applicable
 Rollout method
 Verification, backout, recovery
 Business recovery (disaster recovery)
 Project management strategies, as appropriate

Template courtesy of Watermark Learning Watermarklearning.com/Resources

5
Business Requirements Package
Document support strategies, such as:
 A strategy to address problems, errors or response issues as a result of the new application,
including a process to determine if problems exist.
 Listing of escalation procedures on who to call and when to call them when problems
develop. This procedure should describe how the areas below will address issues:
 Help Desk and/or client champions for calls
 Network services for client/server applications
 Operations and database for performance
 Training for updates on issues

ASSUMPTIONS AND CONSTRAINTS

 Business, technical and project assumptions

 Business, technical and project constraints

ALTERNATIVES
Describe approaches and strategies that were not selected.

ROLES AND RESPONSIBILITIES

Detail who will be involved in the development process and their required deliverables.
Include internal and external clients.

COSTS AND BENEFITS

Include benefits, which are directly linked to the limitations of the current system. As with
objectives, these are best stated in business terms by business clients and should be
quantifiable where possible. Include as many costs as possible that can be determined at this
point in the project.

© Watermark Learning Business Requirements

Requirements Package
6
Business Requirements Package

Body of the requirements package

Business Requirements Overview

Business Requirements are the features and functions of the system expanded to describe such
things as:

 Purpose of each feature and function. Think in terms of describing each requirement
related to data, process, user interface and interaction.
 Description of each feature and function
 How the clients will use each function
 Policies and strategies related to the function
 Explanation of terms, as needed

Requirements List

Business Rules
Business Rules are processing rules stated in the clients’ terms. Business Rules include
but are not limited to:

 Edit rules that are supported across business processes and systems. For example,
there might be intelligence in a key that needs to be edited throughout many programs
and systems.
 Referential integrity conditions. Referential integrity is the ability to maintain the
same information on multiple tables. It addresses the update of one of these data
values that is stored in more than one place. The analyst can choose whether or not a
change in one table will cascade to other stored occurrences of the same data or
whether to restrict such changes. This is accomplished through the use of primary
and foreign keys, the foreign key indicating a dependency on a parent table containing
a unique row or primary key. The analyst must consider such things as:
o If a primary key is deleted, what happens to the related foreign keys?

o What restrictions must be placed on changing a foreign key?

o What validations must be performed when a new row is added that contains a
foreign key?

 Data modeling rules of optionality and cardinality.

Template courtesy of Watermark Learning Watermarklearning.com/Resources

7
Business Requirements Package
 Domain rules for what business information and ranges are embedded in attributes
and fields.
 Data integrity conditions. Defining tight input edits which do not allow any
erroneous data to enter a system is the best way to ensure data integrity. If modifying
an existing program, it is necessary to decide whether or not to tackle new input edits.
 Rules which ensure cross-platform integrity. Business rules need to apply across
platforms. For example, if a region must exist to have a store, then that rule needs to
apply whether being processed on a mainframe or PC.

Supplemental (Non-Functional) Requirements

Include all appropriate, but not limited to:

Service Level Agreements

Service level agreements describe a commitment to have no impact on clients and other IT
areas once a new system or change is installed into production. On-line systems should
maintain or improve response time; reports should be delivered or available on-line no later
than currently. Describe how service level agreements will be met for:
 On-line
 Response time requirements
 System availability
 Background
 Screen/window availability (including notification to clients that background process is
complete)
 Batch
 Processing windows/deadlines
 Special requirements
 Reports
 Report availability (including on-line reports)
 Other Systems
 Impact on other system/application Service level agreements (batch and on-line)
 Impact on critical path
 System Availability
 7 days by 24 hours availability

Reconciliation strategy

Rules for balancing need to be detailed. Also needing consideration are business rules for
reasonability checks. For example, if a bank expects to process $10 million in deposits each day
and there are only $5 million, should there be a warning? Who should get notified? What action
should they take?

Data retention criteria

© Watermark Learning Business Requirements

Requirements Package
8
Business Requirements Package
How long data will be kept and on what media needs to be defined, with input from business clients,
as well as from IT partners.

Purge criteria

Define when data will be deleted from all storage media and when.

Attachments
Traceability Matrix

Process Flows

Include as appropriate:
 Process Maps
 Data Flow Diagrams (optional)
 Hierarchy Charts
 Dependency Diagrams
Data Requirements

The following should be included in this section:

 A diagram of all entities (classes), attributes and their relationship to each other (ERD or
class diagram).
 A description or definition of the above

Definitions
Defining business data (entities) ensures that everyone is using the terms correctly and
consistently, regardless of whether they are from the business line, technical team, vendors,
etc. As an example, it may seem painfully obvious what a bank customer is. However, is a
customer someone who has had an account in the last six months, even if there are no active
accounts?

Use Cases

Include as appropriate:
 Use Case diagrams
 Flows of events

User Interfaces
All organizational standards and guidelines for GUI and web pages should be followed when
designing user interfaces. The following should be included in this section:

Template courtesy of Watermark Learning Watermarklearning.com/Resources

9
Business Requirements Package
 Copy of interface
 Clients using the interface
 Function of interface
 Business processing performed
 Edits performed (see below)
 Inputs to the interface
 Outputs
 Called routines
 Field definitions
 Definition of push buttons and/or function keys used (see below)
 Application program tables that could affect design decisions due to volume, content,
access, etc.
 Documentation on all mouse clicks, fast keys, function keys and mnemonics
 Where the interfaces flow with each possible action. This documentation, although
complex, is necessary.
Decisions on whether or not to use keyboard, mouse or both. These decisions rest on such
issues as:
 Performance (keyboard is faster for expert users)
 Ease-of-use (mouse is generally easier to learn)
 Whether or not the system is operational or decision support, repetitive or requiring more
unique operations
 Whether the clients tend to be expert users (little turnover) or new (higher turnover)

Edits And Their Corresponding Messages

Categorize into three types:
 Informational: These edits provide feedback to the person entering the data.
Example: Order successfully updated
 Warning: These edits usually appear when attempting to delete a business object, such as a
customer or an order.
Example: Are you sure you want to delete this customer?
 Restrictive: These edits prevent incorrect data from entering a system or enforces a
business rule.
Example: Orders must contain at least one order item

Reports
For each standard on-line or hard-copy report, document the following:
 Copy of report
 Receiving Client
 Purpose of report
 Processing performed

© Watermark Learning Business Requirements

Requirements Package
10
Business Requirements Package
 Edits/calculations performed
 On-line reporting, paper or both
 Frequency of report
 Report Service Level Agreement
 Print or on-line location/paper size/special forms
 Inputs
 Outputs
 Application program tables that could affect design decisions due to volume, content,
access, etc.
 Called routines
 Field definitions (optional)
 Client reprint features/procedures

For Decision Support systems and reports include:

 Data warehouse implications
 Whether this report is part of a larger decision support system
 Where new information resides in the operational system
 Extract information required
 Drill-down paths
 Summarized information required
 Standard reports
 Ad hoc capabilities

Glossary
The following should be included in this section:
 Definition of Terms - Clients/IT/Vendor acronyms
 Calculations
 Terms that are unique to this project

System Support Information

Hardware/Software Requirements
The following should be included in this section:
 A Hardware Impact Statement, which includes new hardware requirements. This statement
should be tied to an approved funding request.
 Any packaged software requirements and needed changes.
 Capacity Planning
 Projected peak volumes of transactions

Template courtesy of Watermark Learning Watermarklearning.com/Resources

11
Business Requirements Package
 Projected database requirements
 Projected system growth rate
Impact Statements/Considerations
Include impact statements for all areas affected by this new or changed system. Be sure to
include any expected deliverables.
 Clients - Identify any changes that must be made such as new equipment needed, changes in
procedures, staffing adjustments, etc.
 Telecommunications - Identify the following:
 Location and types of terminals
 New or modified desktop configurations
 Transmission rates
 Estimated line loadings
 Recovery and fallback requirements
 Data Base Administration - Identify requirements to set up or modify tables/databases.
 End User Computing - Identify action required for hardware/software changes in the client
environments
 Help Desk - Identify the types of calls and training needed by the help desk to support this
system
 Production Control - Identify the number of jobs that will be impacted and any scheduling
revisions needed
 Technical Services - Identify any system software changes needed to support the new application
 Application Support - Identify any requirements or impacts that this system will have on
application support:
 System supportability from remote location
 Identify any vendor software and related support issues

Data Security Plan

The following should be included in this section:
 Organization's policy on confidentiality
 System security design should adhere to the organization's security guidelines
 How security will be implemented on the system. This will include things such as the number of
clients and the levels of security needed on the system (i.e. application, screen/window or field)
 Any unique security requirements of the system
Disaster Recovery Plan
The following should be included in this section:
 Organization's business and system strategies used for recovering of application in the event of a
disaster
 Corporate data that is being used by the application, but is the responsibility of another area to
back up and recover
Also include system recovery considerations, such as:
 Time or date dependencies
 Can processing be delayed? How long? Client impact? System impact?
© Watermark Learning Business Requirements
Requirements Package
12
Business Requirements Package
 Can the processing cycle be bypassed? Client impact? System impact?
 Critical system interdependencies

Related Documentation
The following may be included in the requirements package or may be documented in related
project documentation:

Test Strategy and Plans

It is a good idea to define test objectives and a testing approach for all testing phases as early
in the process as possible. By the end of design, these should be complete:

 Test objectives for unit, system and acceptance tests

 Testing steps that can be completed to reduce project risk

 Test cases and scenarios with expected results for functional tests

 Problem reporting (Anomaly Log)

 Testing roles and responsibilities

Test plans, including tasks, dates, roles and responsibilities should be completed. In addition,
as tests are completed, actual results should be documented and compared to expected results.

Acceptance tests should encompass client acceptance and IT acceptance. An example of IT

acceptance is having performance analysis completed.

Acceptance Criteria
Client Acceptance Criteria. All requirements which must be met for the clients to accept this
system into production.

IT Acceptance Criteria. All requirements for the vendor which must be met for IT to accept
this system into production (e.g., system test results, parallel test results, scheduling, data
integrity requirements).

System Constraints
The following should be included in this section:
 A narrative outlining your high level strategy for addressing system constraints, such as
removing intelligence from primary keys or for removing date limitations
 A list of programs, jobs, and files/databases which will be modified to eliminate system
constraints

Template courtesy of Watermark Learning Watermarklearning.com/Resources

13
Business Requirements Package
 A list of bridge programs and utilities which will be implemented to accommodate
interfaces between converted and non-converted systems. Describe when, how, and why
to remove bridges
 A description of any rework which will be needed when the interfacing systems are
upgraded. Describe the nature of the rework

Client Training Plan and Documentation

The following should be included in this section:
Training
 The number of clients using the application initially and long-term
 The strategy that will be followed to train the new clients
 Who will train clients on new business processes
 Who will train the Support team

Documentation
 Who will document the system
 Who will document updates
 Who will document new business processes
 What format will be used (ex. on-line Help)

Project Plan

After the requirements package has been developed and approved, it may be necessary to
review and update the project plan and the baselines therein, including the scope, the schedule
and the budget. Other Management Plans (e.g. Risk and Quality) may need updating as well.

© Watermark Learning Business Requirements

Requirements Package
14