Without Requirements and Verification, You Are Wasting Time and Money

Steve Engle
4 min readJun 29, 2019

--

For businesses, there is nothing more important than customer relationships. Keeping the customer happy is the key to keeping a business running smoothly and growing. Providing the product or service to the customer is only part of the job, the other is making sure the product or service (the “solution”) operates to the customer’s expectations and meets the requirements set forth. To this end, communications centric to the customer’s needs is crucial; it is the responsibility of both to perform this communication and apply the gathered information to defining the project that in the end delivers the sought solution.

In Systems Engineering, project definition (and the communication centric to it) is the initial step in the development process. When developing a solution, I go to the Systems Engineering V to make it come to life.

Together with the client, we go over the details about what problems are to be solved, what the solution is to be capable of, who will be using this solution, what it will be used for, what type of information are to be processed, and much more. A mistake businesses commonly make is designing a solution (and sometimes even implementing one) without first going into this detail — defining how it is going to be operated to solve the problem, documenting requirements for its features and functions, and verifying how well the implementation of those requirements is performed. Having solid requirements is very important to delivering success; without them, one could build an entire solution that in the end doesn’t actually meet the needs of the problem. Time and money are lost, and potentially a client as well.

When you are buying a solution to a problem, have the requirements spelled out.

Photo by JESHOOTS.COM on Unsplash

Requirements are a key data set in ensuring a product or service functions per the client’s needs — i.e. solves the problem. In developing requirements, one is setting the foundation for what the solution is to do and how you will make sure it actually does it. To this end there are two types of requirements: specification requirements, which primarily document the functions the solution is to perform; and verification requirements, which record the methods to be used to verify the specification requirements are met by the implementation. Specification requirements have to be clear, obtainable, and verifiable. Clarity ensures that the requirement is understood and thus the developer will be able to provide the solution with the right capabilities. Attainability ensures that what the solution should do is actually possible with current technologies; it also speaks to the ability to do develop the needed functions within a set budget and schedule. Verifiability ensures that there is a clear indicator of success by setting the criteria for acceptance.

Verifiability is important.

When developing a product or service, there has to be a way to know if it is functioning properly, where “properly” is defined as “functioning per specification”. This is verification — the use of tests, analyses, and other mentions, as documented in verification requirements — to show that the corresponding specification requirements are met by the functions that collectively make up the product or service. A verification may be something as simple as demonstrating a light turns on when a switch is closed (did it actually turn on?) or as complex as flight testing the handling characteristics of a civil jetliner (does the aircraft fly the way it should?). Just as with specification requirements, clarity and regularity of language in writing verification requirements is needed. It is wise to write verification requirements at the same time as specification requirements; if the verification cannot be written that implies the corresponding specification is poorly written. Also, take caution not to write too many verifications (per specification requirement); verify only to the level needed to show proper function. Beyond that, time and money will be unnecessarily expended.

Ultimately, good project communication can keep all parties satisfied and on track to provide quality products and services that meet needs. A key component of that communication is establishing solid requirements; success there foretells well for the entire project.

What are your tips on having strong project communication with clients and customers? Have you had challenges in establishing good requirements? How did you overcome those challenges? Let me know your thoughts in the comments!

--

--