When beginning a project to create a data acquisition, control, or test system, the main two concerns are often “How can we keep costs low?” and “How quickly will it be up and running?” Unfortunately, that can lead to rushing through the most important first step: the creation of a detailed project requirements document. After years of experience building custom turnkey test machines for a wide range of industries – from automotive to aerospace to energy – Wineman Technology has become well-versed in all the details and questions that must be asked in the early phases of a project. In this white paper, we will discuss the importance of creating the specifications document and critical considerations that should be addressed in the planning process.
Figure 1. Having a clear and precise specifications document is vital to creating a well-organized, smoothly running system.
When executed correctly, the design process begins with an in-depth investigation to examine the application requirements and to agree upon the project goals. This may involve several meetings between the client and integrator or management and the engineering team to hammer out details, ask more questions, and get additional clarification. It takes valuable time to sit through all those planning and design discussions and produce multiple revisions of the specifications. Therefore, end users may find it tempting to speed through this process and get straight to the execution phase as soon as possible because of tight deadlines. However, a requirements document certainly makes sense if you are hiring an outside vendor to design and build the system because there needs to be an agreement of the specific project goals, process to be followed, and functionality that will be delivered. However, if all the work is being completed in-house, this time-consuming step may seem like unnecessary red tape. After decades of delivering hundreds of custom turnkey systems and assisting engineers with their applications, we have seen how vital a detailed record of specifications is. Rather than being a waste of time, it is in fact a time-saving (and cost-saving) tool in terms of:
Figure 2. Take the time to create a detailed requirements document to avoid wasted time, wasted money, and wasted breath.
At the beginning of every project, management and the end users (collectively designated as the client) have a vision of the final deliverable that needs to be conveyed to the integration team. At this point in the process, it is important to focus on project goals, features to be included in the system, general design standards, end goals, expected outcomes, and details about the items to be tested. If similar products are currently being tested, it would also be a good time to document any lessons learned about existing testers, the parts, and test procedures.
The key is to strike a balance between being too specific versus too generic. For example, rather than insisting on a specific solution that has been used in the past, the client should spend time explaining the pros and cons of any existing solutions or concepts they have, while the integration team should be given the opportunity to apply their experience and recommend new ideas that may satisfy the requirements even more efficiently. The client can then provide feedback and discuss changes to the integrator’s concepts during a round of revisions. The bottom line is that the specifications document must be detailed enough to clearly define the client’s vision to the integrator, while giving the integrator room to innovate.
Another important item that is often over looked in specifications is, setting up a process of checks and balances to make sure both parties understand how decisions will be made and what constitutes acceptance both at the end of the project and during critical project milestones. It is considered a best practice to have one or more design review meetings during the course of a project, each requiring a formal sign off prior to proceeding to the next phase of the project. Ultimately, the requirements document is a way of ensuring that the client and the integrator are both agreeing to a particular process with tracking is in place for measuring progress against the project goals. We have seen many projects that failed because the integrator agreed to “just get the project done quickly” and failed to follow a good process that included reviews and sign-offs. In the end the customer did not get what they expected and the cost to fix the system is almost always higher than the cost to do it right the first time.
Not only do the specifications serve as an agreement of deliverables, but it has many other uses and benefits:
We discussed the importance of creating an in-depth specifications plan with as many details as possible. What does that mean in actually? In the past, clients have produced specifications that range from a blank sheet of paper to a document full of inaccurately defined and incomplete information to reams of boilerplate information that still don’t supply all the necessary data. A well-defined specification may include sections such as:
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.
In the rest of the white paper, we will discuss the main types of requirements that are usually included in a systems specifications document. Use these questions and topics to guide your discussions during the design phase.
While we emphasized the importance of delving into the details of the system, several high level questions will set the tone of the specifications document in terms of the types of questions that will need to be answered. The first things to determine are:
1) What is the goal of the test stand?
There are several major types of test systems, such as:
2) Is the system being upgraded or built from scratch?
If the system is being upgraded, how much documentation is there on the current system and does it accurately reflect what really exists today? Can the client provide enough detailed information about the existing system for someone to quote the upgrade? Beware if the integrator is willing to quote the job without reviewing the available documentation.
3) How flexible will the system need to be?
Technology is changing at a phenomenal rate and may need to be accounted for in the system definition. Will the unit under test (UUT) stay static or change over time? Does the system need to adapt to a range of different products with minimal effort and additional capital? The lifetime of the tester will also need to be considered.
Remember greater the flexibility and functionality of the test stand, the greater the potential cost or the less likely it is to do everything the client wants extremely well. For example, a life cycle durability tester is usually a low technology system and does not require a lot of data acquisition or expensive sensors. Whereas an R&D or end-of-line test system might require very tight measurement tolerances and lots of technology. Combining those two types of functions together in the same machine, even if they seem similar, may result in less than optimal performance or a higher project budget.
The immediate challenge engineers usually want to address is hardware because it determines so many factors. There is a wide range of criteria when determining hardware for any system, many of which are dependent on the goals of the organization, accepted practices, requirements of the UUT, and how the data is to be handled.
One of the foundational points is the system architecture and its controller. For example, will the system need to be:
At Wineman Technology, we highly recommend utilizing commercial off-the-shelf (COTS) equipment whenever possible. By using COTS hardware, you save development time by working with ready-made technology, you build upon the expertise and investment of engineering product manufacturers, and you can receive support if a component doesn’t work or needs replacement. You can also benefit from future releases of the products to update or upgrade your system.
However, vendor selection is critical when choosing your systems’ hardware. There are a wide range of considerations that can influence the decision, including:
Remember the industry best practice of specifying sensors that are typically ten times more accurate than the measurement accuracies required for the pass/fail limits of the part (four times is sufficient in certain cases). The integrator should specify the accuracy of all sensors quoted. The higher the data rates and the higher the measurement accuracy, the higher the cost usually is. Make sure not to over specify these numbers. At Wineman Technology, we have seen many cases when these specifications have caused prices to skyrocket or vendors are unable to quote the project because hardware cannot be found to meet the requirements.
A properly prepared mechanical requirements specification is integral to your end user’s success. It helps define the performance requirements of the test system’s mechanical elements, materials of construction, fabrication methods and procedures, test and inspection requirements, and so on. In developing a mechanical requirements specification, set bounds on a wide range of relevant parameters for the product or process concerned, such as:
Each of the functions listed above becomes a focus point during the development of a mechanical requirements specification. Important questions to ask during the development of mechanical systems include:
Mechanical design assembly tools are vital during the design phase to ensure that the mechanical design will stand up to the requirements of the final deployed system. Depending on the data required in this phase, different design and validation tools are available, such as:
Figure 3. Mechanical design assembly tools are vital in the design phase to ensure that the mechanical design stands up to the system requirements.
Electrical considerations also play a significant role into hardware selection and the successful operation of the overall application. A well-detailed set of prints for any equipment built by the integrator should be provided. Be sure to address the following questions when dealing with your system’s electrical requirements:
The system itself usually resides within an indoor facility. Therefore, the facility layout, available utilities, and the limitations of the existing space must be taken into consideration. The following considerations are examples of requirements that may be affected by the facility’s parameters:
Figure 4. The facility’s layout, utilities, and other features may impact the equipment definition.
Lastly but most importantly in the hardware considerations is safety – both from the standpoint of personnel safety as well as safety of the equipment and UUT. This would include following the standards set by various governing bodies for Health and Safety (OSHA), Electric Code (NEC) and Fire Protection (NFPA). Below is a sample list of common safety measures:
Ultimately, the software is the heart and soul of the system. It provides a host of capabilities, such as the user interface, monitoring, test profile generation, and control set-up. A best practice is to standardize software platform that natively integrates with or has available drivers for all the hardware components, their calibration utilities, and communication protocols. Depending on the system’s needs, find out if the software can give you access to low level API to allow integration of non-supported devices, custom communication protocols, FPGAs, control models, and other custom features. However, in the interest of ease of use, the final deployment software should not force the end user to make changes by accessing source code but rather through a menu-based environment.
In terms of long-term accuracy, are calibration utilities available or will they need to be developed from ground up? In order to extend the lifetime of the system, make sure there is the appropriate functionality and advanced programming features to ensure scalability, support, and long-term compatibility.
In the end – whether you are coding in C, LabVIEW, or a COTS-based software tool – if the day-to-day users of the application are happy with the software interface, flexibility, stability, intuitiveness, and functionality of the system, most other issues can be overcome. In other words, if the operators don’t like the system, the project won’t be a success.
Figure x. Functionality, stability, usability, and compatibility with the hardware and other integrated subsystems are all important factors for the software development.
As part of the software requirements, you must decide what to do with the system’s data, in terms of data management, reporting, storage, and accessibility. Below are a list of questions to consider when developing the software:
Once the requirements document has been created, now you must make sure the specifications are carried out effectively and intelligently. How the design cycle of the system is managed can significantly impact the success rate of the final deliverable. Here are some best practices in project management to follow during the design cycle:
Figure x. Wineman Technology provides review requirements and check-off lists for different stages in the design cycle.
In conclusion, the specifications document is all about “measuring twice and cutting once.” By spending the time upfront to plan out all the details of a system before execution, fewer mistakes will be made. With a detailed list of requirements, ultimately the final system will be closer to the original vision, ensuring a successful usage of time and resources.
Need Help with Requirements Documents?
Wineman Technology has years of experience creating specifications that become successful systems. For help building a comprehensive requirements document for your test and control applications, contact us today.