Articles & Posts

Articles and Posts 5 mins 127 Views 0 Comments 1 Likes

The objective of this article is to provide business analysts with guidelines for distinguishing between high-level requirements (HLRs) and detail requirements (in IIBA® BABOK® V3 terms – Stakeholder requirements and Solution requirements respectively).

The objective of this article is to provide business analysts with guidelines for distinguishing between high-level requirements (HLRs) and detail requirements (in IIBA® BABOK® V3 terms – Stakeholder requirements and Solution requirements respectively).

The following example, taken from a signed-off HLR document, illustrates the problem:

Each Customer record must be assigned a unique identifier.

This statement certainly represents a valid business need. It’s just not a high-level one. During HLR elicitation, if a detail need like the one above is expressed by a stakeholder, it should be noted - but not formally as a requirement statement. These notes can then be revisited when detail requirements are elicited.

The formal way to document a business need as a requirement is with a single-sentence ‘Shall’ statement. The Agile form of representing business needs is a user story. Like a ‘shall’ statement, a user story is also a single sentence. A user story is considered to be ‘… the start of a conversation’.

Example ‘Shall’ Statement:

A Customer shall be able to transfer funds between their accounts.

Example User Story:

As a Customer, I want to be able to transfer funds between my accounts, so that I’m not restricted to banking hours or need to wait for an available teller.

The real difference between requirement statements and user stories is how they are managed within a waterfall or Agile environment. With waterfall, requirements are managed within the context of a project. A complete set of high-level requirements are expected to be elicited from, and signed off by, designated stakeholders. Assuming the project continues, those HLRs act as the context for detail requirements. The details behind each HLR are elicited from subject matter experts (SMEs). The complete set of detail requirements is then signed off by stakeholders. They are used as the ‘bible’ throughout the life of the project, to support design, development, and testing...

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.

2019-12-08 Keeping High-Level Requirements High-Level Keeping High-Level Requirements High-Level

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.