You have an idea or a need for a test solution. You know exactly what it is supposed to be accomplished and how it will help meet your business goals. You plan meetings with qualified contractors during which you explain your need and ask for quotes.
In the meeting, you clearly explain that the solution should:
- Capture the name of the operator who runs the test.
- Allow the operator to enter information about the test article.
- Perform automated testing of the article per a list of parameters and pass/fail criteria supplied in a spreadsheet.
- Log the operator, test article information, and pass/fail criteria.
You obtain quotes, cut the purchase order, and work commences. The solution is created and the contractor wants to meet with you for demonstration and delivery.
That’s when the trouble begins.
This Isn’t What I Wanted!
Have you been in this situation? Your contractor took the specifications you presented during the initial meeting and implemented them. But, the solution doesn’t do what you want it to do.
- System software has an on-screen prompt for a User Name, but the login is not password protected.
- Data entry for the test article is through typed values, not the bar coding you envisioned.
- Pass/fail criteria is hard-coded into the software application per the spreadsheet, not editable for the different product models you need to test.
- Data is logged in a tab-delimited format for individual test articles, not in a searchable database.
You explain these issues to the contractor, who states that your solution is implemented per details discussed in the meeting. He indicates that these new goals can easily be met, and he will gladly submit a new quote detailing the changes including additional effort and cost estimates.
The Devil Is In The Details
What happened? Is the contractor viewing you or your company as an unlimited source of unlimited funding for their business? Maybe. But the more likely scenario is that the contractor did not fully understand the intricacies of what you required. The requirements and specifications for the test solution were simply not well defined, thus leaving room for interpretation of your explanation.
Responsibility lies with both parties – you and your contractor – to define the exact solution needed. You are the expert on your product, experiment, or process. The contractor is not, but is the expert who can create your test solution. Good contractors will ask questions and offer suggestions that dig deeper into the operation, look, and feel of the solution. This helps, but the better the requirements are specified up-front, the easier (and less error-prone) this process will be.
Take the above example which simply touches on the needs of the solution. At best, the explanation only provided a set of guidelines. Any detail of how the solution must meet these needs, however, is missing. If time were taken to record all details properly, the result of the project would have met the design intent.
What Are The Proper Details?
Consider the requirements specification a prequel to your project. Both you and your contractor want a successful outcome. Creating a requirements specification saves time, money, and headaches and gets your project started down the right path.
Good requirements specifications tend to have common characteristics. It takes time to determine and clarify appropriate requirements. This task is not always easy. A written form is crucial to achieving expected results.
At a minimum, written requirements specification should be:
- Complete – define each individual attribute (need) and response. For example:
- Operator Login:
- The operator must log into application software using a unique name and password.
- Access to continue is denied until a valid username and password are entered.
- Login information must validated through LDAP.
- Voltage Regulator Check:
- The system shall apply +24.0V ± 0.5V to pins J1-3 (+) and J1-4 (-).
- Measure and record the resultant voltage of +5.0V ± 0.1V across pins J5-5 (+) and J5-6 (-).
- Operator Login:
- Consistent – requirements must not conflict and stated requirements do not negate the use of the solution.
- Correct – requirements must be accurate and precise and take into account real-world use.
- Unambiguous – requirements must leave no room for interpretation – clarify as necessary.
- Testable – each requirement must be verifiable as meeting a quantifiable result. For example:
- Does the login operation allow access when a valid LDAP username and password are provided and deny access when the LDAP verification fails? (Yes / No)
- With a known-good test article, and within the ranges listed, does the solution measure the desired +5V output when +24V is supplied?
Specific words, phrases, and other declarative sentences convey the above characteristics. You should uses these words/phrases whenever possible:
- Shall (shall not), must (must not), will (will not), or “is required to” – provide requirements or constraints that are not optional
- Could, should, can, or may – offer options or degrees of freedom in the way the requirement is implemented, or perhaps whether it is implemented at all
And, you should avoid some words or phrases because they cause uncertainty or lend themselves to interpretation, such as:
- As Appropriate/Applicable
- Adequate
- Effective
- Timely
- Provide For
- Not Limited To
- Capable Of
- TBD (To Be Determined)
Following this guidance, the requirements specification forms a firm foundation for your project. It allows contractors to properly quote the system as you envision it. It enables you to compare quotes in an “apples to apples” fashion and choose the best solution. And, your contractor of choice will know exactly how to design the final deliverable for the project to be successful. In short … you get what you want.
You Don’t Need To Go It Alone
If you are not sure how to get started or are struggling with the details, you can download our free Requirements Specification Template below.
Or, you can click here to get consulting assistance through Tecnova. Our expert Test Solutions engineers have created hundreds of solutions to some of our clients’ most challenging problems. We routinely work with and create client requirements specifications. At the end of the consultation, you have a working document that can be used to obtain quotes for an “apples to apples” comparison of solutions.
