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