Hardware/software design requirements planning: Part 1 – Laying the ground work

Editor’s Note: In this series of articles, Jeffrey O. Grady, author of “System Verification,” delineates the basics of requirements planning and analysis, an important tool for using Agile programming techniques to achieve better code quality and reliability in complex embedded systems software and hardware projects.

This series of articles is about the process of developing good specifications for any hardware or software development project. In the English-speaking world, requirements are phrased in English sentences that cannot be distinguished structurally from English sentences constructed for any other purpose.

Yes, specifications are full of sentences. It is relatively easy to write sentences once you know what to write them about. A requirement is simply a statement in the chosen language that clearly defines an expectation placed on the design process prior to implementing the creative design process.

Requirements are intended to constrain the solution space to solutions that will encourage small-problem solutions that synergistically work together to satisfy the large-problem (system) solution.

Requirements are formed from the words and symbols of the chosen language. They include all of the standard language components arranged in the way that a good course in that language, commonly studied in the lower grades in school, specifies.

Those who have difficulty writing requirements experience one of three problems:

(1) fundamental problems expressing themselves in the language of choice, which can be corrected by studying the language,

(2) technical knowledge deficiency that makes it difficult to understand the technical aspects of the subject about which the requirements are phrased that can be corrected through study of the related technologies, and

(3) difficulty in deciding what to write requirements about.

The solution to the latter problem is the possession, on a personal, program, and company basis, of a complete toolbox of effective requirements modeling tools and the knowledge and experience to use the tools effectively individually and collectively.

Providing the toolbox should be the function of the system engineering functional department, recognizing that some departments outside of the system engineering department will contribute people to programs and these people will apply a department-unique method that should be coordinated with the intended systems approach.

This toolbox must encourage the identification of product characteristics that must be controlled and selection of numerical values appropriate to those characteristics. So, this toolbox must help us to understand what to write requirements about. We must accomplish requirements identification and requirements definition where we determine the values appropriate for those requirements.

Requirements definition through modeling gives us a list of characteristics that we should control to encourage synergism within the evolving system definition. If the analyst had a list of characteristics and a way to value them for specific items, language knowledge, and command of the related technologies, he or she would be in a very good position to write a specification that hit the target that is to capture all of the essential characteristics and no additional content.

One approach to a solution to this problem on what to write requirements about is boilerplate, and this is essentially what specification standards such as MIL-STD-490A provided for many years. Its replacement, MIL-STD-961D Appendix A and later the E Revision that integrated the content of Appendix A into the body of the document, is likely to do so for many more years within the context of military systems. In the boilerplate approach, you have a list of paragraph numbers and titles, and you attempt to define how each title relates to the item of interest.

This results in a complete requirement statement that becomes the text for the paragraph stating that requirement. The problem with this approach is that there are many kinds of requirements that cannot be specifically identified in such a generic listing.

One could create a performance requirements boilerplate that covered every conceivable performance requirement category with some difficulty, only to find that it was more difficult to weed out those categories that did not apply to a specific item than it would have been to have determined the appropriate categories from scratch.

This is why one would find no lower level of detail in a specification standard than performance even though there may evolve 50 pages of performance requirements during the analysis for a particular specification. Interfaces are another area where boilerplate is not effective at a lower level of detail.