Systems Engineering Process – Requirements Part 2

 Figure 1. Interpretations of Requirements

In Part 1 of the Systems Engineering Process – Requirements Part 1 blog, I discussed how the requirements process fits into the overall project and how the requirements ultimately impact the success or failure of the project. If we look at the standard IEEE definition for Requirement, we can determine the specific meaning of the word in the context of Systems Engineering.

Requirements Definition (IEEE-STD-1220-1998)

The first thing that we see is that it is a statement. This is significant in the fact that because it is a statement, there is a particular language that is used in defining requirements. This language makes the requirement statement clear and specific. The language itself satisfies some of the rules of requirements such as eliminating the possibility for judgment or objectivity.

Written requirements have a specific defined style or language that is used for the project. This language becomes a part of the contract and is usually called out in the Requirements Management Plan. There are some industry standard guidelines that can be followed, however tailoring to a particular contract is up to the project manager with concurrence from the project sponsor.

The word “SHALL” should always be used for all mandatory requirements. Each requirement must have a “SHALL” statement associated with it. The word “WILL” may be considered legally binding and expresses a provision or services supplied by the purchaser and on which the supplier can implicitly rely, so caution must be used when including this word. The word “SHOULD” in the text expresses a recommendation or advice on implementing such a requirement of the specification.  The word “MUST” is typically used for legislative or regulatory requirements (e.g. Health and Safety).  The word “MAY” in requirements documentation expresses a permissible practice or action. Typically, “THRESHOLDS” are requirements and “GOALS” are desires.

Requirements statements are sometimes referred to as “SHALL” statements. When reading through a contract, specification, Request For Proposal (RFP), etc. the reader should be able to extract the requirements by the SHALL statements. As an example, the United States Environmental Protection Agency (EPA) Section 508 standards call out the specifications for accessibility. The EPA is responsible for ensuring that all electronic and information technology is accessible to disabled users (EPA, 2012). Therefore, the requirements for IT systems used within the EPA include:

Software Applications & Operating Systems

• When software is designed to run on a system that has a keyboard, product functions SHALL be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.

Telecommunications Products

• Telecommunications products or systems which provide a function allowing voice communication and which do not themselves provide a TTY functionality SHALL provide a standard non-acoustic connection point for TTYs. Microphones SHALL be capable of being turned on and off to allow the user to intermix speech with TTY use.

If you were working on an IT project for the EPA, all of the systems would be required to meet the SHALL statements included in Section 508. Each specific component would have an associated SHALL statement that would be testable. This test of the requirement is how the deliverable is validated, or in other words how the requirement was met.

When writing requirements statements, differentiating between requirements and associated explanatory text can be accomplished by changing the boldness, italicized or underlining the requirement text. Always ensure that you spell check and use the correct grammar for the statement(s). The requirements statements should also contain very simple sentences with one subject, one verb, one object, etc. The requirements statements should not contain unnecessary adjectives and adverbs such as “almost always”, “very nearly”, “somewhat”, “about”, “close to” or “approximately”. It is also recommended that the requirements statements be written in positive form rather than negative for as in the “The system SHALL NOT…” The requirements must never contain any subjective language such as “preferred”, “easy to use”, “high-speed”, “medium-sized” or “best practices”. The exception is where a threshold such as high-speed is specifically defined in a particular standard that is called out somewhere in the contract. The statements must be free of loopholes and language such as “if possible”, “when requested by” or “as necessary”

Another thing to keep in mind when writing technical requirements is to maintain consistent terminology. If you refer to the “computer system” on one requirement, that same system cannot be referred to as the “CPU” on another requirement. The use of CPU brings up another consideration, which is the use of acronyms. Many publications will advise against using acronyms in contracts or requirement documentation. This is not practical in most IT and/or technical projects, therefore it is suggested that the acronym be spelled out the first time with the acronym in parenthesis such as “The Service Design Package (SDP) SHALL contain everything necessary to take the service through all stages of the project lifecycle.” Remember that the IEEE definition also specified that the statement that the requirement must be unambiguous, testable or measurable, and necessary for product process acceptability. Always keep in mind that the requirement must be traceable to some sort of measurement or test that will validate the requirement.

References

 Institute of Electrical and Electronics Engineers (IEEE) 1220: Standard for Application and Management of the Systems Engineering Process

International Organization for Standardization (ISO) 15288: Systems and software engineering — System life cycle processes

Project Management Institute (PMI) Project Management Body of Knowledge (PMBOK Guide) Fourth Edition.

Systems Engineering Fundamentals (1999) Published by Defense Management College Press.