High-Level Requirement DOs and DON’Ts
Part 4 of Dan Tasker’s Requirements in Context series provides guidelines for what a business analyst should and shouldn’t include in a high-level requirement (HLR). It begins by comparing a formal HLR ‘shall’ statement to a user story. What is similar about them is that the format of both is a single sentence. The single user story sentence is intended to be the ‘start of a conversation’ during which details are discussed. A properly high-level HLR should be a ‘topic of conversation’, where an appropriate elicitation technique is applied to discover details as part of detailed requirements.
When the context for HLRs is a scoped project responsible for delivering an IT-based solution, and functional capabilities of that solution are being identified, there turn out to be five basic capability types. A given HLR should represent a capability of one of these types:
- User Interface (UI)
- Report
- Data Import
- Data Export
- Automated Function
An example of each of these capability types is presented, including a formal HLR example. E.g.
An accounts receivable clerk shall be able to apply a selected payment from a list of unallocated payments to a designated customer account.
For each capability type examples of details that should be deferred until detailed requirements elicitation are listed. E.g.
- Data fields displayed for one record, or in columns for a list of records
- Layout of fields on a screen, or the order of columns in a list
To help manage stakeholder expectations during high-level requirements elicitation, it is recommended that the HLR phase of a project should be considered more of a requirements planning phase rather than a requirements gathering phase.
Continue reading at ModernAnalyst.com