Articles and Posts Jun 12, 2020 10 mins 2666 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 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 [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.