Articles & Posts

Articles and Posts 10 mins 491 Views 0 Comments 0 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

Login or Register to download

Dan Tasker

The author of two books and numerous articles, Dan recently retired after working and consulting in the IT industry for the past 48 years. He spent the first 10 years working as a developer (called ‘programmer’ back then) in the United States and Canada. This was followed by two years teaching computer programming, database design, and data modelling. The remainder of his career was spent as a business analyst, in Canada, Australia, and New Zealand. He continues to be passionate about quality requirements and helping business analysts produce them. He can be contacted at dantaskernz@gmail.com.

2020-06-12 High-Level Requirement DOs and DON’Ts High-Level Requirement DOs and DON’Ts

Comments / Discussions

Please login or register to post comments.

Contact author

x



Free Newsletter

Requirements.com is trusted by leaders and experienced professionals across the world. Start your subscription today, for free.