'Fundamentals of Business Analysis' Course (now includes optional extra ISEB Certificate in Requirements Engineering)
Next available course London 16-20 June 2008 Reserve a place
We currently have Business Analyst positions on our Business Analyst Vacancies page
Call
0845 166 2161
to speak to one of our team
<High-Level or Detailed> Requirements Definition
<Project Title>
Authors Name/s:
Issue Date:
Change History
List of signatories
Distribution List for info
Table of Contents
-
Introduction
A brief description of the project and the purpose of this
document. Should clearly state whether the requirements defined are those that
have been agreed to be delivered or an initial business wish-list. A brief
statement should also be included to state whether this is the final sign-off
version, draft version and the expected next steps following agreement of this
document e.g. Design phase commences, third party tendering initiated.
Background
Scope
Definition of the areas that are included or have been
specifically excluded from the analysis. This may include organisational
areas, processes, customer types/segments, systems, business locations. State
reasons for exclusion where out-of-scope items may be contentious.
Constraints
Include details of any imposed constraints on the
requirements. For example, where it is known that integration into an existing
system cannot be achieved or there are externally imposed time constraints.
State reasons for constraints such as legal or regulatory.
Objectives
State the business objectives for the project. Examples
might include cost saving, revenue generation, customer service improvement,
etc. These business objectives should clearly marry up with the requirements.
Requirements Overview
Requirements Definition
Details of the functional requirements to be delivered.
You may be using a process-driven approach or a tabular listing of requirements. Whichever approach, it should be clearly stated whether each requirement is mandatory, optional or nice-to-have. Or, use whatever classifications have been agreed within your project
If using a process driven approach then non-functional requirements (below) may need to be related to each process. Otherwise sections 8 to 11 will be required to state the non-functional requirements.
Sections 8 – 11 may not be required for a high-level
requirements document and some may not be required where there are no systems
components to the project.
Location/User Groups
Details of the user groups affected by the change or who
will be using new functionality. Include details of known locations for each
user group and the number of users in each location.
Security Requirements
Details of any security requirements such as supervisory
access, or how access should be prevented to non-authorised users. Do not
include requirements which are already defined generically for the
organisation in question.
Service Level Requirements:
Details of the required availability of a proposed system
(e.g. 24 hours, 365 days per year) and the level of resilience required (e.g.
maximum downtime = 1 hour per month). Include details of required response
times but only where there is a specific need not covered by the
organisation’s generic rules.
Volumetrics
Include details of average and peak volumes across all
processes/transactions and any anticipated growth in these volumes. State
clearly when any peaks occur.
Other
Depending on the nature of the project further sections may be required for
- Contingency requirements
- Backout
- Controls
-
Business Case
Include details of the business case which should include sections on benefits and costs to a level of detail that reflects the document purpose.
The business case and NPV calculations used should have been agreed by the project’s financial project representative.
Include any unquantifiable or intangible benefits in a separate section.
Ensure any assumptions made are clearly stated.
-
Issues
A list of those unresolved queries/questions or obstacles that prevents the project moving forward and which cannot be resolved internally. An issue may have an associated assumption that all parties have agreed to enable work to move forward in the short-term. Include details of who owns the risk and when it is expected/required to be resolved by.
-
Risks
A list of realisable events outside of the project’s control that may either impact a project's ability to deliver on time, or, to deliver a successful and workable solution.
-
Dependencies
Details of any external event, task or project which has a material influence on delivery of these requirements.
The following further sections may be required depending on the nature of the project and the level of requirements being defined. You may choose to include them as appendices or within the main body of the document.
-
Data Model
Likely to include an Entity Relationship Diagram and entity descriptions
-
Data Conversion Requirements
Required where data is to be converted/migrated from an existing set of processes whether manual or automated.
Useful Notes
Do not include requirements that would normally be expected as part of the implementation plan.
For example, ‘The users must be trained in the new system’ is not a requirement to be included in a Requirements Spec. It is an implementation issue, as would be ‘production of user manual’, ‘stationery redesign’, etc.
However, if users are insistent on logging such requests and having them signed off (or you simply don’t want to lose track of such items), then include such items in a section titled ‘Business Implementation Requirements’.