In my experience of many projects (over many years!) I would say that one of the most common causes of delays and development cost overruns is unclear, ambiguous, or often completely missing requirements
None of this is Rocket Science (unless you’re building a rocket) and simply involves writing down, and maintaining, a clear description of the system that is to be developed. Different projects will need different levels of definition. Spending three weeks detailing requirements for a small system update that only takes two weeks to implement would be foolish. However, developing a complex new product from scratch would easily justify that kind of investment in the requirements process.
It’s sometimes difficult to convince “management” who are looking for “progress” that the development of requirements is real progress. The time spent generating a good set of requirements will pay pay back two or three fold later in the development cycle, but sometimes requires more justification than it should. That is not to say that other activities can not be going on in parallel with the initial requirements generation process. Very often there will need to be research, feasibility studies and some experimental Proof of Concept work going on at the same time. These are often needed to underpin the requirements generation task and will often lead to valuable cross fertilisation between the threads. This is especially true where the requirements generation process has identified Risks which require mitigation or investigation.
Here is an example of a System Requirements Specification which was being generated for a product. It’s a work in progress, and the development did not happen for various reasons. It’s a good example of the parallel working for the the requirements and feasibility studies. In this case the feasibility investigations were mainly related to the mechanical possibilities and the sizes, mounting of the PCBs so all the connectors could be easily accessed.
Of course the requirements for a system are a “living” thing and will inevitably change through the development life cycle – that’s just the way it is! This is not a bad thing as long as the changes are conscious and the impact of them is clearly communicated and managed.
Requirements generation is analogous to the old adage about the structure of a presentation – “Tell them what you’re going to tell them, tell them, tell them what you told them”. With requirements this paraphrases into – “Decide what you’re going to make, make it, check that you made it”. This matches exactly with the V-Model process described in the Technical Project Management section.
Decide what you’re going to make.
The key here is clear Product Requirements so that the detailed technical system and sub-system requirements can be derived from them in a simple and sensible hierarchical structure. This is the left side of the V-Model
Make it
For software development, use the detailed technical requirements to spin out the Tasks and Stories as part of an agile sprint planning process. For hardware make sure that there are clear paths through to an implementation that meets the requirements using check points and peer review. This is the bottom “v” part of the V-Model.
Check that you made it
Ensure that there are cross referenced test cases and trials that ensure that the original product and technical requirement have been met. This is the right hand side of the V-Model.
Writing a good requirement
Writing a good requirement is actually a bit of a skill and people often benefit from a bit of training. A good checklist for a the creation of a good requirement is ….
⇒ Define one requirement at a time – each requirement should be atomic. 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.
⇒ Avoid using let-out clauses like but, except and if necessary.
⇒ Each requirement must form a complete sentence with no buzzwords or acronyms.
⇒ Each requirement must contain a subject (user/system) and a predicate (intended result, action or condition).
⇒ Avoid describing how the system will do something. Only discuss what the system will do. Refrain from system design. Normally, if you catch yourself mentioning field names, programming language and software objects in the Requirements Specification Document, you’re in the wrong zone.
⇒ Avoid ambiguity caused by the use of acronyms like etc, approx. and the like.
⇒ Avoid the use of indefinable terms like user-friendly, versatile, robust, approximately, minimal impact, etc. Such terms often mean different things to different people, making it difficult to define their test cases.
⇒ Avoid rambling, using unnecessarily long sentences or making references to unreachable documents.
⇒ Do not speculate; avoid drawing up wish lists of features that are impossible to achieve. Saying you want a system to handle all unexpected failures is wishful thinking since no system will ever be a 100% what you want it to be.
⇒ Avoid duplication and contradictory statements.
⇒ Do not express suggestions or possibilities. You can identify these wherever you see statements with might, may, could, ought, etc.
⇒ Avoid creating a jigsaw puzzle where requirements are distributed across documents, causing you to cross-reference documents. This can make your RSD extremely difficult to read.
⇒ Do not refer to a requirement that is yet to be defined. Again, your objective is to make the document as much of an easy read as you can.
⇒ Use positive statements such as “The system shall…”, instead of “The system shall not…”
⇒ “Shall“ should be used where requirements are being stated, “Will” should be used to represent statements of facts; & “Should” to represent a goal to be achieved.