Click here to get this post in PDF
The main signs of good software requirements are:
- Accuracy;
- Unambiguousness;
- Completeness;
- Integrity;
- Prioritization;
- Verifiability;
- Easy changeability;
- Traceability.
Accuracy. It’s the main point of prd which must be in the center of consideration. Of course you want the spec to be accurate. Nobody writes inaccurate specifications on purpose. We prefer the saying “Accurate but definable”. Order is the timely update of a specification when you find inaccuracies in it.
Unambiguousness. TK is unambiguous if and only if each requirement allows only one interpretation. Well, yeah, easier said than done. Wasting time on this to the detriment of the delivery of TK can be a waste of time. But as soon as you find ambiguity, correct it. A TK can be called complete if only it is enough for developers to create software.
Integrity. TK should be holistic both in itself and in relation to related documents. If you name an input field “Start and Stop” in one place, do not name it “Start / Stop” in another.
Prioritization. Often, a new system has requirements that are more similar to marketing wishes. Some may not be feasible. It is useful to reflect this information in the TOR.
Verifiability. Don’t write requirements like “It should provide a quick response to the user.” Or, for example, another one, my favorite – “The system should never crash.” Instead, provide quantitative requirements such as, “Each keystroke must respond within 100 milliseconds.”
Variability. The same requirements in different places is not necessarily wrong – but it causes the document to become unsupported.
Traceability. This is often not so important in a non-politicized environment. However, in most organizations it is sometimes useful to link the requirements in the TOR to a higher-level document. Why do we need this requirement?
One of the tasks that can be done with prd is to describe all the functions of the system. In many systems we work on, some functionality is implemented in hardware and some in software. The System Requirements should provide a complete description of the functionality and, as is the case with performance requirements, a preliminary draft of the distribution of these functions among the various subsystems (mechanical, electrical, software).
Additional specifications
However, in most projects that are carried out for small and medium-sized companies, it is more practical to describe the system and software requirements in one document. This is mainly done because the most difficult moments are implemented in software. If the hardware has to meet some functional requirement, then most often this means that it is important for the software that this aspect is well documented. Very often the software must meet the system requirements of the available hardware. Very often the systems department does not participate in the project, and programmers simultaneously act as systems engineers. For small projects, this solution is fine, although not ideal. In this case, from the description of the requirements it should be clear what belongs to the software part, what to hardware, and what to mechanics.
In general, software requirements should not describe design requirements. However, in practice, this can be difficult to implement. As for the professionals of Fireart, they know for sure how to figure out the question.
Thus, the requirements should clearly and unambiguously define everything necessary and (preferably) with an indication of the software that is needed to develop a new product. References should include the version numbers of the documents used. Also, consider using one document toolkit that will allow you to include other documents and provide easy access to the full version of the requirements.
You may also like: Essentials to Keep in Mind While Choosing a Business Software
