Requirement documenting plays an important role in systems engineering. Writing high quality requirements can not only save millions of dollars, but lives. No matter how experienced you are it’s important to remind yourself of requirement writing rules and techniques.
Know Your Stakeholders
The first and most important commandment of writing requirements is to know your stakeholders. Understand what common knowledge they have. Make sure you are all on the same page. Understand what each group of stakeholder’s priorities is and their objectives. You do not want each group to develop their own priorities and objectives separately. Separate priorities and objective result in a time consuming and expensive review process with lots of conflicts. Collaborative software that allows for continuous reviewing will help you keep up with all the stakeholders needs. You never want to give them a completely finished product and then ask for review (although that is common practice).
Remember the CONOPs
Most of you will probably not forgo the Concept of Operations (CONOPS), since it is such a valuable artifact. The CONOPS will be something that all the stakeholders understand and collaborate on together. In this step you basically create stories that will consider different scenarios and needs. From there you will have a better understanding of where to start with your requirements. The CONOPS will help you write quality requirements by finding all the assumptions. It will help evaluate the ‘what if’ scenarios, make testing easier, and formulate your needs into the requirements.
Understand What is Really Needed
First of all, there is a huge difference between want and need. Will the system work without a particular requirement? If you answered yes, then you can probably omit that requirement. A common mistake systems engineers make is listing possible solutions to needs rather than the actual needs. If your need is an efficient way to communicate, don’t specify cell phones, since there are many other forms of communications that may be more feasible, less expensive, or effective. List what is actually needed; don’t list possible solutions to the needs.
Be Specific (Give actual numbers. Don’t leave room for assumptions.)
Leaving room for assumptions is leaving room for error. If you are not careful with the language you choose you could end up making costly assumptions. Using words such as minimize, maximize, etc., and/or, more efficient, forces the stakeholders to assume. Don’t let the stakeholders assume how much you want to minimize.
- etc. can mean so many things
- and/or causes the reader to guess whether its ‘and’ or ‘or’
- min. max. don’t just say minimize expansion, say minimize expansion to 300
- don’t just say quick, say how quick
- give actual numbers
Do Not Be Too Specific
The only mistake worse than not being specific enough is over specifying. You want to be specific, but not too specific. Carefully review your requirements before baselining. During this review delete any unnecessary specifics.
Allow scope with your numbers. If a requirement is good enough at expanding 300% +/- 10%, then give that option. Have any numbers be based on the results of analyses, not just someone’s “engineering judgment.”
Give Requirements Not Instructions
Understand what is needed and create requirements from those needs. This is why Commandment #1 is so important. If you understand your stakeholders needs writing requirements and not instructions becomes an easier task. It might be tempting to just writing instructions, but that is not what requirements are for. Requirements should provide enough information to allow the builder to provide the most cost-effective solution to the problem.
Use the Words ‘Shall’, ‘Should’, and ‘Will’
The industry’s standard word usage for a requirement is “shall”, a goal is “should”, and a statement is “will”. If you do not use these standard word choices you will confuse other stakeholders.
Include a Rationale
A rationale justifies the inclusion of a specific requirement. Attach a rationale to each requirement by explaining the need for the requirement. The rationale provides reviewers and implementers with additional information on the intent of the requirements, thus avoiding confusion down the line.
Use Proper Grammar
You will prevent a lot of costly mistakes due to confusion if you use proper grammar. For example, run on sentences will result in two requirements appearing to be one. One technique to improve grammar is to use bullet points first and then construct sentences out of them.
Use a Standard
Use a standard to ensure consistency. Three common standards are MIL-STD-490, IEEE, and ISO. You should choose one that is right for your industry.
MIL-STD-490: The United States Military Standard establishes the format and content for the United States Department of Defense’s objectives. It can be useful in other areas as well.
IEEE: The Institute of Electrical and Electronics Engineers Standards Association develops the IEEE standards. Unlike the MIL-STDs, the IEEE reaches a broad range of industries, including transportation, healthcare, information technology, power, energy, and much more.
ISO: The International Organization for Standardization develops standards for business to optimize productivity and minimize costs.