One of the most common problems you need to avoid in requirements writing is making bad assumptions.
Bad assumptions occur either because requirement authors do not have access to sufficient information or the information does not exist. You can eliminate the first problem by documenting the information critical to the program or project, including needs, goals, objectives, constraints, missions, operations concept, budget, schedule and management/organization.
This information then must be made available to all authors. You can create and maintain a list of other relevant documents and make these easily accessible to each author. If you have automated the process, you can offer documents online and you can filter the information within the documents so that individual authors can get copies of only the data that they need.
Where information does not exist, the requirement author should document all assumptions with the requirement. When the requirement is reviewed, the assumptions can also be reviewed and problems quickly identified.
The goal of each step in the requirements writing process is to help ensure that the product development or project goals are successfully met.
According to INCOSE, it’s important to determine how to verify a requirement as it is being written. In other words, determine the criteria for acceptance. This step will help insure that the requirement is verifiable.
Ideally, every requirement statement (written from the user’s perspective) should contain:
- A user role that benefits from the requirement
- A desirable state that the user role wants to achieve
- A metric that allows the requirement to be tested, where applicable
Additionally, it’s important to define one requirement at a time. Don’t be tempted to use conjunctions like and, or, also, with and the like. This is particularly important because words like these can cause developers and testers to miss out on requirements. One way to achieve this is by splitting complex requirements till each one can be considered a discrete test case.
It’s especially important to avoid ambiguity. Poor or unclear communication is highly frustrating for all parties working on your product. Developers may have to call the client back several times asking for more explanations or spend much time designing features and functionalities that do not meet the client’s expectations.
Also, the client may end up with a product that doesn’t fit his requirements and will not serve his business as it should. All that may quickly lead to business disruption – and lost revenue.
Want to learn more? Tonex offers Requirements Writing Training Course — Specification Writing Training, a 2-day course that shows you how to write well-formed, validated requirements and specifications.
This is an excellent course for project stakeholders, SMEs, directors, project sponsors, users and just about anyone involved in the planning and writing of specifications requirements.
For more information, questions, comments, Contact us.