9.2 Software Operational Requirements Specification

9.2 Software Operational Requirements Specification

The first step in the software specification process will be the definition of our system at the operational level. This is the user's view of the system. With our software skills, we can create virtually any reality we wish. However, we must first specify the reality that we want. The most difficult aspect of software development is that we can operate virtually without constraint in the reality that we can fabricate for a user. Before we can begin the operational specification process, we must first define this reality. This virtual system we will call the operational metaphor.

9.2.1 Operational System Overview

We will begin our operational specification with the operational system overview. This is a simple précis of the system. It is a concise statement of the basic operation of the system from the user's perspective. It gives the customer, the designer, and the developer an overview of the operation of the system. This is the kind of thing that would be printed on the cover of a CD-ROM containing the software. We will be able to read this description and know what the system will do for us.

The term "user" or "client" does not always imply the existence of a human being in this process. For embedded systems, the client is the hardware that is being driven by the software. In other circumstances, the user or client could be one or more independent software systems.

The operational system overview will also embody nonoperational requirements that need to be formalized to ensure that the software meets the user's needs. These can be broken down into a taxonomy as follows:

• Quality requirements

  • Reliability

  • Maintainability

  • Availability

• Performance requirements

• Compatibility requirements

  • Hardware

  • Software

  • Network protocol

9.2.2 Operational System Metaphor

The next step in the specification process is to construct the operational system metaphor. Again, we can create virtually any reality that we wish with our modern software technology. We are going to build an imaginary castle in the sky for our user. The precise description of this castle is the operational system metaphor. It will define very precisely the user's overview of the system operation. It answers the question of what the system does. It should provide the system user with a complete description of the abstract model that will interact with the user.

If, for example, our task is to construct a calculator for a user to deploy on his or her desktop, we must work to define the precise metaphor for the calculator. One calculator that we could build would work in the command mode and would behave in a similar fashion to the traditional UNIX dc calculator. We would then define for the user how many decimal places the calculator would maintain for calculations, what operations were permissible, how the data would be entered, and how the data would be displayed. In essence, we would write a simple user's manual that would describe our calculator metaphor so that the user could operate it correctly within the framework of the command line calculator.

The complete and accurate specification of the operational metaphor is vital to the next step, which is to identify the set of operations that the user can perform on the hypothetical calculator that our metaphor describes. A sample metaphor of our hypothetical calc command line calculator might look something like this:

calc is an integer arithmetic calculator. It will be initiated from a UNIX command line by typing the name calc with no arguments. It operates on decimal integers. Accuracy is limited to ten digits. The overall structure of calc is a stacking (reverse Polish) calculator.

calc will prompt the user with a ">" symbol. At the prompt, the user can type any one of the operations listed in Exhibit 1, followed by a carriage return keystroke. The description of each of the permitted operations is shown in the second column of Exhibit 1.

Exhibit 1: Operations for Hypothetical Software

Operation	Description
<enter number>	The value of the number is pushed on the stack. A number is an unbroken string of the digits 0 through 9. It can be preceded by an underscore (_) to input a negative number.
+	The top two values on the stack are popped, added, and their sum pushed back on the stack.
-	The top two values on the stack are popped, the first number is subtracted from the second, and the difference is pushed back on the stack.
*	The top two values on the stack are popped, multiplied, and the least significant ten digits of the product is pushed back on the stack.
%	The top two values on the stack are popped, the first number is divisor, and the second number is the dividend. The remainder is pushed onto the stack followed by the quotient.
d	The top value on the stack is duplicated.
p	The top value on the stack is printed. The top value remains unchanged. p interprets the top of the stack as an ASCII string, removes it, and prints it.
f	All values on the stack are printed.
q	Exits the program. If executing a string, the recursion level is popped by two. If q is capitalized, the top value on the stack is popped and the string execution level is popped by that value.
c	All values on the stack are popped.

9.2.3 Operations

At this level we will specify very precisely the operations that can be performed on our operational metaphor. These are a set a mutually exclusive activities or operations that the user can execute. A list of operations for our hypothetical calc software is shown in Exhibit 1. Each operation can also have nonoperational attributes in its description. We might wish, for example, that all operations be executed in less than one second on a real-time clock.

Each operation is distinct. We cannot combine them. The user will be constrained to doing one at a time in serial order. Essentially, we are going to insist that each operation be entered, followed by a carriage return. It should be obvious that there are no implementation details considered in the set of operations. These operations are strictly what the user will do to interact with our calc software.