How to Develop a Functional Specification

Oct. 3, 2016
A functional specification can better define a control system’s requirements

About the author: Chris Schleich is engineering manager for Enterprise Automation. Schleich can be reached at [email protected] or 949.769.6000.

Picture this: Your brand new desalinization plant takes up to four hours to start, and that is if the one operator who has a piecemeal understanding of the controls is available.

The following is a true story: Over the course of two weeks, a newly hired principal engineer at this agency spent two weeks with operators through trial and error to determine how the controls worked. They conceived a custom startup sequence, using 20 screen changes and manual interventions, to bring the plant online in 20 minutes. Even with the plant running, they did not trust the data.

Stories like this are not unique, but they do not have to be yours. One of the best ways to work well with a systems integrator (SI) after vetting qualifications is to ensure the SI’s scope includes developing a clear, consistent and complete functional specification in partnership with the owner (end-user). This means defining what the control system is required to do, in terms unmistakable to the owner, before anything is built.

An Explanation for Specification

Why develop a functional specification?  Control systems have a disproportionate impact on the systems they serve. No matter how well the infrastructure and process designs are implemented, a poorly functioning control system can overwhelm an organization with problems, including poor reliability; increased staffing; manual interventions; training difficulties; prolonged troubleshooting; and reduced ability to optimize operations.

Unlike other industrial engineering disciplines, developing control systems is not regulated, and disciplined project methodology is not common practice. Solutions are crafted in virtual spaces where core decisions can be implemented on a whim; visibility to stakeholders is low; and technology and terminologies pose barriers to stakeholder understanding. Imagine a contractor constructing a tank and changing the bottom shell plate thickness by half in the middle of the build without notifying anyone. Preposterous—but in the SI industry, the equivalent is normal.

Developing a functional specification forces the SI to actually design the software (e.g., PLC program, HMI). Through the written word, the operational structure of your process, big or small, can be rapidly outlined, followed by filling in detailed requirements for the behavior and operator controls of every sequence, control loop, pump, valve, safety switch, trend, alarm, user security, etc.

Let’s say an owner reviews a functional specification from his or her SI and discovers fatal flaws or omissions. Excellent—it is only paper, it is early in the project, and the redlined functional specification provides a medium to communicate the gaps to the SI so the required changes are mutually understood.

By reworking sentences on paper, the control system architecture can be optimized in minutes or hours. A customary alternative is “design as you code” which, regardless of a programmer’s perceived skill, yields disjointed program structures that are subsequently difficult to correct and expand upon.

What does a functional specification look like? A functional specification should be written in plain English, describing the required behavior of the system in the equipment and process terminology of the owner. References to programming syntax are rarely necessary. The accessibility of the document dictates how effectively stakeholders can provide feedback during design, and how well it will support operations as reference material. If an operator, technician or manager cannot understand it, it is not written well enough.

A well organized document structure builds the reader’s understanding of the physical process, introducing key concepts and intent prior to control strategy details. 

A table of contents could read as follows: 

  1. Project background
  2. Main equipment and instrumentation
  3. System modes
  4. Manual controls and user set points
  5. Process control
  6. Security
  7. Alarms
  8. Trends
  9. Screens

While better than nothing, control strategies written as standalone flow charts or diagrams leave countless gaps in requirements (e.g., How are critical alarms conveyed? Is the PID loop tunable from the HMI? When the user presses the “Auto” button, what sequence unfolds? How long is data stored? What permissions are required?). Proper functional specifications provide the basis for programming, testing, startup, acceptance and operations. Both the SI and the owner can use them to measure progress and compliance.

Who writes a functional specification, and how does he or she write it? Ideally, SIs should write the functional specification, because they are best suited for ensuring requirements are thoroughly defined. However, the highest value is attained when stakeholders from the owner are engaged in the process.

“Control strategy workshops” are an effective format to engage stakeholders in helping to define control system requirements. During a workshop, the SI can discuss and diagram (whiteboard) what the equipment and process will do to frame the requirements gathering in terms relevant to operations. The SI can subsequently develop and submit a draft functional specification and, upon approval, start programming. This may seem more expensive and drawn out; however, short- and long-term savings from the benefits are substantial. The fastest and lowest cost project methodology? Do it right the first time.

Specification Strengths

A functional specification developed in this manner allows the owner to confirm the process control system he or she will receive and provides value throughout the life of the system. A functional specification is a principal as-built document, offering clarity that informs training, troubleshooting, optimization, new feature requests, system expansion and system replacement/retrofitting. Without one, a SI will inevitably be hired to reverse-engineer the legacy system at some point to support the owner. This cost is never represented in the original project budget.

Programming without a functional specification typically is born from an optimism and lack of awareness common to software development. Projects executed without finishing functional specifications tend to encounter budget and schedule duress. Processes can provide fundamental necessities to communities—engineers want to build them better, and they can.

The desalinization plant from the introduction is being doubled in capacity, including a new control system. The functional specification has been approved and the owner confidently predicts a 10-minute, fully automated startup without changing screens.

Enterprise Automation is a member of the Control System Integrators Assn. (CSIA) specializing in the water and wastewater industry. Headquartered in Irvine, Calif., Enterprise Automation’s expertise includes design consultation, specification development, panel design, virtualization, communications optimization, PLC programming, and SCADA configuration. For more on Enterprise Automation, visit the company profile on the Industrial Automation Exchange.

About the Author

Chris Schleich

Sponsored Recommendations

Blower Package Integration

March 20, 2024
See how an integrated blower package can save you time, money, and energy, in a wastewater treatment system. With package integration, you have a completely integrated blower ...

Strut Comparison Chart

March 12, 2024
Conduit support systems are an integral part of construction infrastructure. Compare steel, aluminum and fiberglass strut support systems.

Energy Efficient System Design for WWTPs

Feb. 7, 2024
System splitting with adaptive control reduces electrical, maintenance, and initial investment costs.

Blower Isentropic Efficiency Explained

Feb. 7, 2024
Learn more about isentropic efficiency and specific performance as they relate to blowers.