It can be used to document project information such as a summary of the project, the business objectives, problems/opportunities, scope (often project scope), high-level requirements (although in many cases detailed as opposed to high-level requirements are documented).
Arguably from the perspective of a BA who is responsible for Requirements Deliverables/the Business Requirements Document, the main purpose of the High-Level Requirements section is to establish the scope of the requirements deliverables for the project. That is not to say the other sections are not important from a context perspective – they are. However, the real key for the BA is to convey the boundaries for the requirements deliverables.
One way to set the requirements scope is by following the approach below to document Requirements Scope Statements (RSS) in the High-Level Requirements (HLRs) section of the BRD. I prefer to refer to them as Requirements Scope Statements (RSS) for the simple reason that they establish the scope of the requirements effort.
Guidelines for RSS:
- Document RSS using the following syntax (for those familiar with Agile development this is the same syntax that is used to document Epics/User Stories):
<Someone (could be a person or group) > must be able to/ will be able to do <something> in order to <accomplish some goal>.
- An optional best practice is to indicate whether the requirement is met electronically or through manual means (see example below)
- Assign a unique identifier RSS00X in front of the RSS for traceability purposes.
- Never make a system/ application a stakeholder for two key reasons:
a. These are Business Requirements, not system requirements/ design specs
b. Systems/ Applications should always “do” things for the benefit of someone/ some group i.e. why does a system need to generate a report – for whose benefit?
- Document RSS in a table and add a column for priority
- The number of RSS depends, naturally, on the size/complexity of the project and number of stakeholders. As a general guide:
a. Small projects a maximum of up to 6 RSS (remember these are just High-level requirements)
b. Medium size projects a maximum of up to 15 RSS
c. Large size projects a maximum of up to 25-30 RSS
* Note: If you exceed the above guidelines in all likelihood the Business Analyst has gone from documenting High-Level Requirements to documenting Detailed Level Requirements
- RSS in Programs – my recommended approach is to document the RSS in the Program level BRD and then assign specific RSS from the Program level BRD to the component projects that make up the program. In general, an RSS from the Program should only be assigned to one and only one project. If the same RSS from the Program is assigned to more than one project, then I suggest breaking down the RSS into smaller RSS that can be assigned to the individual project.
|Reference No.||Requirement Scope Statement||Priority|
|RSS001||Investment Advisors must be able to view portfolio performance reports electronically to serve their clients.|
As you can see, from a requirements scope perspective you have identified:
- Stakeholders – Investment Advisors
- Requirement boundary – mid and detailed requirements (user stories in Agile) will be related to portfolio performance statements
In addition to establishing the scope of the requirements deliverables, the RSS provide additional benefits:
- RSS help BAs to determine what types of mid, detailed requirements will be produced which in turn provide BAs with the basis to create a high-level estimate of the effort needed to elicit, analyze, and document requirements deliverables
For example in the above example you will probably have:
- Data dictionary for the data elements in the reports and on the UIs
- Mock-ups for the printed reports
- User Interface (UI) Mock-ups for viewing the reports
- Use cases (depending on whether or not the Business Analyst is playing a systems analyst role) related to generating, presenting and printing the reports
- RSS can trace to specific business objectives/problems/ opportunities to the RSS to ensure the needs are being covered
- RSS can also trace forward to Mid and Detailed Requirements (or vice versa depending on what traceability approach you are taking)
- RSS provide technology groups with a basis to provide high-level estimates of their efforts
- RSS enable BAs to make sure all the stakeholders are covered i.e. compare the stakeholder groups documented in the RSS against other documents/artifacts such as Stakeholder Impact Assessments or Context Diagrams to ensure all the stakeholders/ stakeholder groups are covered. If there is a gap, then RSS enable the discussion with other project team members to determine where and why there is a disconnect.
Sign off on RSS
Does RSS require a formal sign-off? The answer to this largely depends on the BAs organizational project methodology. In some organizations, the entire High-Level Requirements Section (including RSS) is signed off and baselined to help manage scope. In other organizations an email acceptance of the High-Level Requirements Section – specifically the RSS – from the project Business Owner, Project Manager is sufficient.
Ultimately there is no right way or wrong way – the organization just needs to define and follow whichever process they are going to follow.