Keeping High-Level Requirements High-Level

Articles and Posts Jul 13, 2019 5 mins 8007 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 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

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].