Requirements are the basic units of specification in software engineering. These describe functional, core capabilities and behaviors of the system and key constraints. Requirements should specify **what** a specific feature should do, not **how** it would be done. Each requirement should be a brief statement (not a paragraph). Avoid subjective words like “simple” and “user-friendly” because these mean different things to different people. It should be easy to determine if a requirement has been satisfied. “Shall” should be used to signify what the system must do. “Will” should be used to represent facts. “Should” will define a goal to achieve. Requirements are the [[single source of truth]] for software teams. Each requirement is often communicated in one [[user story]]. Critically, ensure that only those requirements that match the project [[scope]] are included. ## gathering requirements Before gathering requirements, its important to create a plan to make sure requirements will be gathered consistently and comprehensively, then validated with users before work begins. Many options exist for requirements gathering, including - brainstorming with different stakeholder groups - [[nominal group technique]] - interview stakeholders (see [[persona interview guide]]) - questionnaires - [[delphi technique]] - prototypes (a quick prototype is often the best way to elicit further requirements) - review existing systems and documentation (which features should be kept? what are the integration and interoperability requirements?) - review alternative products and services (what do users like/dislike about this similar product?) - workshops to map 'as-is' state (visualize current systems with stakeholders) Prioritize requirements based on importance. Finally, validate requirements with stakeholders. In [[Waterfall]] methodologies, requirements are typically gathered exhaustively up front. Requirements are then documented in a formal requirements document. In [[Agile]] methodologies, requirement gathering is an ongoing process. Requirements are documented in a product [[backlog]]. A **requirements traceability matrix** maps requirements to deliverables so stakeholders can ensure the requirements are met. ## writing good requirements Writing good requirements has many challenges. - Elicitation of requirements from users: They can be incomplete, misleading or wrong. Users often don't understand the range of options and have trouble thinking outside-the-box in the solution space. - Changing requirements: When users begin to see the product, they often realize requirements are wrong or envision better solutions. Over the time of the project, systems that require integration can change and so can the nature of the problem itself. [How to Write Good Requirements](https://blog.testlodge.com/writing-good-requirements/) lists these features of good requirements - No ambiguity - Be brief - Are they doable? - Rank by priority - Are the testable? - Use consistent terminology - Avoid conjunctions The example provided distinguishes good from poor requirements. - **Poor:** The email notification must include the relevant information. - **Good:** The email notification shall include the dollar amount, date, payee name, and identification number.