UnambiguousThis means they are clear and they leave no room for anyone to misinterpret them. They are stated in a way that is clearly understood. They should be understood by the writer (which is you), as well as the reader. If they're not clear and unambiguous, then they don't serve much purpose.
Valuable
Great requirements are valuable. They are written to solve a business need, to make things easier for a user, and to align with business objectives. They are important and meet the criteria of the users. If a requirement is not valuable, then it isn't really a requirement. If it's not going to provide any value to a user, then we need to reconsider why it's actually a requirement in the first place.
Great requirements are valuable. They are written to solve a business need, to make things easier for a user, and to align with business objectives. They are important and meet the criteria of the users. If a requirement is not valuable, then it isn't really a requirement. If it's not going to provide any value to a user, then we need to reconsider why it's actually a requirement in the first place.
Verifiable
The purpose of a requirement is to specify what actually needs to be done by the project team (developers, system engineers, etc). To make sure that the requirement is implemented correctly, it needs to be verified. The requirement should be able to be verified - it should be described in a way that allows for someone to check if it has been completed or not. Some requirements are vague or don't allow easy verification of them, which leads to problems in the testing phase.
The purpose of a requirement is to specify what actually needs to be done by the project team (developers, system engineers, etc). To make sure that the requirement is implemented correctly, it needs to be verified. The requirement should be able to be verified - it should be described in a way that allows for someone to check if it has been completed or not. Some requirements are vague or don't allow easy verification of them, which leads to problems in the testing phase.
Concise
A good requirement needs to be concise. It needs to be easy to read and understood, by both the author and the audience. It should not be overly descriptive - only as descriptive as it needs to be. By that, I mean you should only add in words or terms that are needed to help the reader understand the requirement.
A good requirement needs to be concise. It needs to be easy to read and understood, by both the author and the audience. It should not be overly descriptive - only as descriptive as it needs to be. By that, I mean you should only add in words or terms that are needed to help the reader understand the requirement.
Requirement should be prioritised. They should be assigned a value to determine how important they are to the users and to the system. This could be a simple High/Medium/Low scale, a rating of 1 to 5, or something more complex. The aim of a priority is to get agreement on the importance of a requirement, and to help decide if and when it should be implemented.
Separate From Design
A good requirement should not mention any design features or suggestions. At the requirements gathering stage, the method of implementation should not be considered. The requirement's job is the specify what is being implemented - the design is used to specify how. Try to focus on the "what" of the system at this stage and don't mention any specific technologies or layouts or design rules.
Attainable
The requirements you write should be attainable. They can be ambitious, or tricky, but they should be able to be achieved. There's no point writing requirements that are impossible to achieve. Having requirements that are attainable keeps the project team and stakeholders updated and confident that items can be delivered. If something is not attainable, it should not be a requirement.
The requirements you write should be attainable. They can be ambitious, or tricky, but they should be able to be achieved. There's no point writing requirements that are impossible to achieve. Having requirements that are attainable keeps the project team and stakeholders updated and confident that items can be delivered. If something is not attainable, it should not be a requirement.
Consistent
Requirements should be consistent, both in your document and with any other areas of the system. You should use the same grammar and terms when writing requirements, so that the same meaning is determined from them. They also should be consistent when reading through the document to look for any gaps in the requirements written.
Requirements should be consistent, both in your document and with any other areas of the system. You should use the same grammar and terms when writing requirements, so that the same meaning is determined from them. They also should be consistent when reading through the document to look for any gaps in the requirements written.
Owned
Good requirements have an owner specified. This is so that the author and reader knows who to speak to if they have any questions. This might seem obvious at the start of the project, but two months in you may need to clarify something, and having an owner against these requirements is helpful.
Great requirements completely describe the objective of the system or the project. Nothing is left out. If there are any requirements that are not going to be built, then they are specified in a separate section. The list of requirements should cover everything that is expected by the system. There should be no gaps or confusion about certain areas.
Unique IDs
I thought I'd include a bonus tip, even though I said there were ten, I thought I'd throw in another tip for writing good requirements.
A good way to improve your requirements is to assign each of them a unique ID (such as REQ001, REQ002). This is helpful for identifying the requirements later in the project, as well as discussing them with other people. The ID is unique across the project and can be used to create other documents.
