Articles and Posts Jun 12, 2020 10 mins 3772 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 Related Content Requirements Glossary from A to Z Context is Everything... When It Comes to Requirements What are Product Requirements? 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]. Did you like this article? 0 Upvote Requirements product requirements Requirement Types requirements context high level requirements 2020-06-12 Requirements.com All about Requirements 2020-06-12 Dan Tasker High-Level Requirement DOs and DON’Ts Contributor Dan Tasker Comments / Discussions Please login or register to post comments.