Top 10 Writing good requirements tips
WRITTEN BY Martin Gorm Pedersen - 15 January 2012
So how should I write and manage my requirements such that they communicate effectively to my team members and other stakeholders?
Here are my top 10 points for writing and managing requirements:
1) Central repository. Requirements must be stored in a central repository, ideally online, where all relevant stakeholders can access them and where changes to requirements are tracked
2) Must be verifiable. All requirements should start with "The system shall.." e.g. "The system shall provide a login with username and password". In other words you should be able to verify whether the requirement has been implemented or not by answering simply yes or no. Each requirement should also only include one purpose.
3) Unique IDs. All requirements must have a unique ID e.g. R100. The ID itself should have no associated meaning other than provide a common reference.
4) Table of contents. All requirements must be organized in a logical hierarchy i.e. a table of contents. Such that you group for example different areas of your product like modules, security requirements etc.
5) Priority. All requirements must have a priority attribute that indicated how important the requirement is. The simplest form could be "Must-have" and "Nice-to-have" or "High", "Medium" and "Low".
6) Owner. All requirements must have an owner attribute that indicated who requested the requirement. This is important so you know who to ask if any questions come up.
7) Lifecycle. All requirements must have a lifecycle attribute that indicates where in the process a given requirement is. The lifecycle indicates how finished the requirement is e.g. New, needs review, approved, assigned to developer, ready for test, test approved, test failed, write release notes, released to production. Compare the lifecycle to an assembly line where the requirement is moved through different phases.
8) Responsible. All requirements must have a responsible person attribute that indicates who is responsible for the requirement right now. This is closely linked to the lifecycle described above. So if the lifecycle is "assigned to developer" then the responsible person will be set to a developer by the project manager. When the developer is done then the lifecycle will be changed to "ready for test" and the responsible person will be set to the test person or redirected to the project manager for re-assignment.
9) Release. All requirements must have a release attribute that indicates what product version the requirement should be part of. You typically group requirements (and issues) by version such as Product 1.0 with release January 1st.
10) Dependencies. All requirements should have listed any dependencies on other requirements. So if a requirement states we need to "View a list of logins" then a dependency, should be added to a requirement that states "When a user logs in the details must be added to a log." Because you can’t get the former list unless the latter log entry has been created. The dependencies are critical especially when you start to have many requirements and you start to introduce change, then you must know how a change to a given requirement impacts other requirements through its defined dependencies.
So why are requirement so important to take seriously and get right from the start, simply because without them you have no way of effectively communicating what needs to be accomplished to your stakeholders. And equally important you will be unable to determine if everything was delivered as agreed when the project finishes.
Feel free to share your own experiences and questions.
Requirement Management (21) Stakeholder feedback (6) Business Analyst (16) Project Mangement (12) Webinar (3) Press release (4) Integration (1) Issue tracking (1)
Need help?Click here to contact us
"Thanks RequirementOne for a cool, easy to use SAAS tool that helped make our project a success." - Michelle Hoffman, CEO Hoffman Consulting