Authoring good stories for a developer is an art and science. The business analyst needs to be able to articulate the pain the customer is facing and translate that into a meaningful requirement for the developer to implement.
Equally important is the need to ensure that the requirement meets the objectives of the business. Below are some attributes of good requirements or stories to ensure the delivered implementation is what was expected by the customer.
- Requirement ID: Unique Number with a dot followed by digits for sub requirements
- Requirements Title: Free Text
- Description: Includes a function, actor/role, input and output
- Requirement Origin: Could be the User, sponsor, BA, developer
- Requirement Specification: Originated (base requirement due to a business need), derived (from another requirement), implied (assumed by default), emergent (new due to a change)
- Requirement Acceptance Criteria: Free text explaining how to verify a requirement has been developed
- Priority: 1, 2, 3 (1 = high, 3= low)
- BA Comments: Free text explanation or notes from BA to clarify points, provide examples
- Requirement Validated: Yes, No (has it been validated by the business)
- Business Value: The purpose of this requirement, the pain its solving or gain its providing to the business
- Verification Method: Demo, Testing, Inspection