“I Need a Solution Yesterday”
When working with a systems integrator to provide a custom solution to fit your specific needs, the project process often begins with an in-depth investigation to examine the customer requirements. In order to thoroughly understand the application, this may involve several meetings between the client and integrator to hammer out details, ask more questions, and get additional clarification. Many times customers and/or service providers may want to speed through this process and get straight to the execution phase as soon as possible because of tight deadlines. It takes valuable time to sit through those planning and design discussions and produce multiple revisions of the specifications. Is all that really necessary?
Figure 1. Having a clear and precise specifications document is vital to creating a well-organized, smoothly running test stand.
Delving into the Details
At the beginning of every project, the customer has a vision of the final deliverable that needs to be conveyed to the integration team. However, the only way to ensure success is to go beyond the high level concepts and delve into the nitty-gritty details. That vision must have finely detailed specifications to clearly define the customer’s vision to the integrator. At this point in the project, those details should focus on what the system needs to do rather than how it will do it. Also, the two parties need to agree on a process of checks and balances to make sure both parties understand how decisions will be made and what constitutes acceptance at the end of the job. Ultimately, the requirements document is a way of ensuring that what the customer has in mind is what the integrator is agreeing to provide.
Figure 2. Take the time to create a detailed requirements document to avoid wasted time, wasted money, and wasted breath.
Measure Twice, Cut Once
Presumably you are working with an integrator because they have the domain expertise and necessary skills to design a tester. Therefore, you must work together with the integrator to lay out the exact requirements. This would include the following:
- Project goals and objectives
- Tests to execute
- Reports required
- Cycle time requirements
- A list of parts to run
- The amount of system flexibility
- Measurement and control tolerances required
- Designation of roles and responsibilities for the client and integrator
- Design approval process
- Time and cost budget (and plan of action for going over scope)
- Description of key functions
- List of channels, alarms, and other parameters
- Terms of support and maintenance
- Outline an acceptance test procedure and time required
- Sign off on the agreement
Ideally, these topics should be covered with enough detail that the integrator should be able to explain to you how each of these items will be accomplished with the system concept that they are proposing. By investing time into a well-laid-out, very detailed plan – versus just stating high level objectives and winging it as you go along – you can vet out potential problems or incompatibilities in the design. Without a clear and precise requirements document, the original intent and functionality of the system may get misinterpreted later down the road, especially if the project timeline stretches over a long period of time or the system architecture involves a lot of complex subsystems that must work perfectly together. Furthermore, a project may be worked on by multiple people or teams, so the specifications help keep everyone on the same page for smoother integration.
Best Practices for Implementing the Requirements
No one wants to waste time or money building something, only to find out you have to redo it over again. This is why part of a good requirement document is a defined process. Here are some best practices to follow during the design cycle:
- Once you have a technical specification, the development process needs to be agreed upon so that both parties can be assured that the technical objectives of the project are getting met.
- At subsequent design review meetings and approvals, this process serves to outline a reasonable set of expectations for both parties.
- The integrator should be prepared to provide design documentation in these review meetings that have enough detail so that the customer can determine if their needs are getting met.
- The customer should be prepared to carefully review documents and make sure the integrator is following the vision outlined in the specification.
- The process should include tracking of milestones and deliverables. It should also define who has the authority within your organization to make decisions. Ideally, use a single point of contact from each company.
Need help with requirements documents? Learn more in our free white paper, The Importance of Requirements Documents for Data Acquisition, Control and Test Systems.
Wineman Technology has years of experience creating specifications that become successful systems. For help building a comprehensive requirements document for your test system, speak to one of our engineering consultants today.