Self-Destruct TBDs

A software requirements specification (SRS) with a TODO or TBD (To Be Determined) note is obviously not complete. There may be good reasons for approving and starting work on a project with a TBDs in the specification. This is particularly true for requirements whose precision are not critical to fundamental design decisions.

When you create a TBD, be sure to footnote it with a "self-destruction note," that is, specify who will resolve the TBD and by when.


Reference:
IEEE, ANSI/IEEE Guide to Software Requirements Specifications, IEEE Computer Society Press, Washington, DC, 1994.

Specify When Environment Violates "Acceptable" Behavior

Requirements specifications often define characteristics of the system's environment. This information is used in making intelligent design decisions. It also often implies that the developer is contractually obligated to accommodate such characteristics. What happens after deployment when the environment exceeds the specified limits?

Suppose the requirements for an air traffic controller system specify that the system shall handle up to 100 aircraft in a sector simultaneously. They system is built and correctly satisfies this requirement. Three years later 101 aircraft accidentally enter a sector. What should the software do? The possibilities are:

1. Print an error message.
2. Crash.
3. Ignore the 101st aircraft.
4. Process all 101 aircraft but perhaps not satisfy some other timing constraint (such as how often the screen is updated).

Obviously, options 1, 2, and 3 are unacceptable. Yet they are valid system responses as (not) stated in the requirements. The right solution is to explicitly state in the software requirements specification (SRS) the expected system response when the environment exceeds any of the constraints defined for it.


Reference:
Davis, A., Software Requirements: Objects, Functions, and States, Prentice Hall, Englewood Cliffs, 1993.

Specify Reliability Specifically

Software reliability is difficult to specify. Don't make the problem even more difficult by being vague. For example, "The system shall be 99.999% reliable" means nothing.

Does it mean that the system cannot be "down" more often than 5 minutes every year but that it is okay to occasionally make a mistake (for example, a hotel reservation service may occasionally mix up hotel details). Or does it mean that it must make no more than one mistake every 100,000 transactions (for instance, a patient monitoring system cannot cause the death of more than one out of every 100,000 patients)?

When writing requirements, differentiate between:

1. Failure on demand.
•  What is the likelihood, measured as a percentage of requests, that the system will fail to respond correctly? For example, "The system shall correctly display 99.999% of hotel information."
  
2. Rate of failure.
•  This is the same as "failure on demand" but it is measured as a percentage of time. For example, "The system may fail to report hotel information correctly no more than twice a year."
3. Availability.
•  What percentage of time may the system be unavailable for use? For example, "The hotel reservation system shall be available 99.99% of the time in any given calendar year."

Reference:
Sommerville, I., "Software Engineering," Addison-Wesley, Reading, MA, 1992.

Write Natural Language Before a More Formal Model

Augment, Never Replace, Natural Language says to create requirements specifications that contain both natural language and formal models. Let's go a step further: Always create the natural language version of a requirements specification first. If you write the formal model first, the tendency will be to write the natural language that describes the model instead of the desired system. This also applies to writing test cases. Write the test cases first to avoid the tendency to only test the code that was written or the way it is applied.

The best approach is to (1) write the natural language, (2) write the formal model, and (3) adapt the natural language to reduce ambiguities that become apparent when writing the formal model.

Augment, Never Replace, Natural Language

"In an effort to reduce ambiguity in requirements, software developers often decide to use a notation that is more precise than natural language. This is, of course, commendable in that ambiguity is reduced (Reduce Ambiguity in Requirements) by using finite state machines, predicate logic, Petri nets, statecharts, and the like. However, in such an effort, the specification is rendered less understandable by others (Keep the Requirements Specification Readable*) who may have less computer science or mathematical background than the requirements writer.

To alleviate this problem when using a formal notation, retain the natural language specification. In fact, one good idea is to keep the natural language and more formal specification side-by-side on opposing pages. Do a manual check between the two to verify conformity. The results will be that all readers can understand something and that some nonmathematical readers may learn something useful."


Reference:
Meyer, B., "On Formalism in Specifications," IEEE Software, January 1985.

Reduce Ambiguity in Requirements

Software requirements specifications are often written in a natural language. To reduce the ambiguity of natural language apply the following techniques:

1. Performing Fagan-type inspections on the Software Requirements Specification (SRS).
2. Constructing formal models of the requirements and rewriting the natural language as problems are found (Know Formal Methods).

Reference:
Davis, A., "Software Requirements: Objects, Functions, and States," Prentice Hall, Englewood Cliffs, 1993.

Separately Number Every Requirement

"It is essential that every requirement in the requirements specification be easily referenceable. This is necessary to enable later tracing to the requirements from the design (Trace Design to Requirements) and from test (Trace Tests to Requirements)."

I recently completed a project where there was not requirements specification document. The requirements were captured in a JIRA project. For anyone using a similar system for requirements tracking, the equivalent principle would be to make a ticket for every requirement. Don't get lazy and lump several requirements into one ticket just because they are related. If they are separate requirements then they need to be tracked as separate tickets.


Reference:
Gilb, T., "Principles of Software Engineering Management," Addison-Wesley, Reading, Mass, 1988.

Write Concisely

I often see requirements specifications with sentences like:

The target tracking function shall provide the capability to display the current tracking coordinates of all active targets.

Contrast this with:

When tracking, the system shall display the current positions of all active targets.

Organize Requirements Sensibly

Organize requirements in a way most natural for the customers, users, or marketing personnel. This will help avoid later changes or additions by improving understanding of what is being requested.


Reference:
Davis, A., "Software Requirements: Objects, Functions, and States," Prentice Hall, 1993.

Use Multiple Views of Requirements

Multiple views of requirements are needed to sufficiently understand or describe the behavior of a complex system. For example, you might use object-oriented analysis (OOA) to assess the real-world entities relevant to an application. OOA will help identify them and understand their interrelationships and attributes. You might use finite-state machines to describe the desired behavior. You might use decision trees to describe the system's behavior in response to complex input, and so on.


Reference:
Yeh, R., "Software Requirements: New Directions and Perspectives," Handbook of Software Engineering, New York. 1984.