High-Level Requirement DOs and DON’Ts

Articles and Posts Jun 12, 2020 10 mins 4924 Views 0 Comments 1 Likes

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

Related Content

Dan Tasker

Dan is the author of over 30 requirements-related articles and other resources. His 45+ year career in Information Technology has involved organizations in a variety of industry sectors in the United States, Canada, Australia, and New Zealand. His business analysis experience includes projects involving in-house software development, software vendor solution development, and COTS software acquisition and implementation. He continues to be passionate about quality requirements and helping business analysts produce them. He can be contacted at [email protected].