How do you define good requirements? It may sound trivial, but here are some best practices that help in the definition and subsequent testing and tracking of requirements. Here are a few tips that have proven to be effective:

1) Start with a predefined requirements specification. A few good examples are available for download on the Internet and they typically cover 70% – 90% of the PLM needs of most companies. Using such a predefined requirements specification saves a lot of time and money and helps to get off to a good start quickly. A very good PLM requirements specification is available here.

2) Solicit additional requirements that are specific to your business needs from the various functional areas in your organization that will be using the PLM system in the future. It is beneficial if the requirements specification template allows adding custom requirements.

3) Define clear and concise requirements. Don’t state “The user interface should be easy to use”. This is too subjective. What some people might perceive as easy to use can be completely confusing for others. Instead define “SMART” requirements. i.e. Specific, Measurable, Attainable, Realistic and Time-Bound. For example: “Search results should be displayed without delay” is specific and measurable, but it is neither attainable nor realistic. A better way to define this requirement would be: “The response time for any search should not exceed 1 second”. This can be measured, is realistic and can be tested.

4) Don’t combine several requirements into one. For example, do not state “The system should be able to manage Word and Excel files”. There is no problem as long as the system is capable of doing both. But what if the system is only capable of managing Word files, but not Excel? Should the requirement now be marked as met, not met, or maybe only partially met? In either case it is difficult to track. Instead each requirement should be listed separately. In this case, there would be two different requirements: “The system should be able to manage Word documents”, and “the system should be able to manage Excel documents”.

5) Organize requirements into functional areas. This will make it easier to evaluate how well a system performs in entire functional areas, i.e. change management, configuration management, document management, etc as opposed to only against individual requirements, and it will allow building use and test cases that flow better.

6) Number each requirement. This sounds trivial but is very important during the implementation. One of the key reasons why requirements are defined is to ensure during testing and validation that the implemented system can and does actually meet all these requirements, and numbering requirements allows tying them to test cases and tracking adherence. The General Principles of Software Validation; Final Guidance for Industry and FDA staff; Section 4.1 states that “A documented software requirements specification provides a baseline for both validation and verification. The software validation process cannot be completed without an established software requirements specification (Ref: 21 CFR 820.3(z) and (aa) and 820.30(f) and (g))”.