Specifications

The implementation of a software system requires much more details than a very abstract list of features or textually expressed requirements. Many of the missing details are constraints, prescriptions, or insights given by the stakeholders.

Example: Microwave Oven.

Requirement

Cook a plate for a certain time given in input by the user.

Specifications

Specify exactly how the microwave oven reacts to user input from the keyboard or other sensors.

This will lead to an exact definition, or system model describing how the system reacts to inputs from its environment. This model can be described from many viewpoints, and one of them is the aforementioned requirement.

Definition of Software Specifications

Specifications represent a model of how system inputs (or events) are related to system reactions and outputs.

Thus, building software specifications is a model-building process. That is mainly why the border between specifications and design is not well defined. Like requirements, specifications are still a representation of the problem to be solved, whereas the design activity leads to a representation of a software solution to this problem.

Requirements are represented in a manner that ultimately leads to a smooth implementation, i.e. one that requires as less changes along the way as possible. Specifications will increase the level of details given in the requirements, and provide a model of the problem. It will answer much more questions, thus furthering the analysis before solution writing. It is thus likely that building software specifications will eventually lead to less changes in the requirements in the following phases of the system developed.

The Need for Specifications

Building software specifications can be extremely costly because of the level of details involved. Global understanding, as well as fine-grained understanding of the problem is required to enable full specifications to be developed. Not all software development projects can afford the time investment required to build full specifications. Some projects don’t even need software specifications, as, for example, very simple or well understood problems.

Specifications are needed in cases where the problem to be solved is either very complex and poorly understood, or in the case of critical systems, e.g. systems involving people’s security.

Note also that in some systems, only a part of the system is either complex or critical. In these cases, the specifications for the system can be build only for this part, which is levering the cost of the specifications effort, and still achieving the goal of problem understanding.

Specification Principles

The border between specification models and design models is very hard to locate. This border tends to move towards requirements when te problem is easy to grasp, i.e. minimal, very abstract, or no specifications at all are needed. For complex and critical systems, the border moves towards design, i.e. the analysis model contains many very low-level details. In this case, it is very easy to mix analysis details with implementation details.

The idea behind the specification phase is to develop a model of the desired behavior of the system that encompasses the problem’s data and the functional responses of the system to various stimuli from the environment. One has to establish the context in which the system has to operate by specifying the manner in which other system components will interact with the developed system. In other words, one should create a cognitive model representing the abstract concepts of the problem description scope, rather than a design or implementation model representing the implementation details of the solution to the problem. A cognitive model should describe a system as perceived by its user community, e.g. a business model in the context of information systems.

A specification is always an abstraction of a complex situation. Simple problem statements normally don’t require extensive specifications. For complex and/or huge problem description, the specification model might require several levels of abstraction for clarity of presentation. One should organize the content and structure of a specification in a way that will enable easy reference and changes

Specification Techniques

Informal Techniques

Natural Language

In many development projects, the specification document consists of page after page of English, or some other natural language like German, French, etc. The obvious problem with that technique is pertaining to the ambiguous nature of all natural languages. Natural languages are not precise enough, and don’t provide any clear abstraction mechanism, which is of crucial importance in any modeling activity. Natural languages can also be very confusing and cannot be checked for completeness or consistency because of their ambiguous nature.

Pseudo-Code

Pseudo-code is a quasi programming language consisting of imperative sentences with a single verb and a single object. It uses a limited set of action-oriented verbs from which the sentences must be constructed. Decisions or options are represented with a formal IF-ELSE-ENDIF structure. Iterative activities are represented with DO-WHILE or FOR-NEXT structures. Pseudo-code represents an attempt to combine the informality of natural languages with the strict syntax and control structures of a programming language by simplifying the english language to its simplest expression. Pseudo-code is thus understandable by a non-programming person, and reduce the ambiguity of the textual requirements. However, pseudo-code is still a textual technique. It is still not good for expressing various levels abstraction in the requirements description. Also, although pseudo-code is a textual technique, its writer does need a certain level of programming skills because of the ”algorithmic” nature of the technique. Last but not least, it is very easy for the requirements engineer to fall into programming details when using this technique.

Semi-Formal Techniques

Entity-Relationship Diagrams

In many cases, especially in business applications, the basis of the system is about storing, managing, transforming, and outputting information. In these cases, modeling the structure of the information is a first step towards the understanding of the problem. Entity-Relationship diagrams are used to represent the structure and relationships among data within the system modeled. It provides a high-level architectural view of the system data, and focuses on the external and very high level behaviors of the system.

However, entity-relationship diagrams might be difficult for non-technical readers to understand, as it conveys information in a formalism that requires a certain level of understanding of databases theory. Also, entity-relationship diagrams is one of the oldest modeling techniques and thus comes in many flavors, which are somewhat different from one another, and often specialized to certain tools or techniques, e.g. object-oriented databases. As with pseudo-code, it is also very easy to fall in the trap of defining the final and complete database structure, which is a design activity, not a specification activity. Again, the goal of specifications is understanding the problem, and not to find a solution to the problem.

Dataflow Diagrams

Visual presentation of the structure and the organization of the low-level requirements and the input/output relationship among them. High level description of the requirements representing the flow of data in the system in terms of data stores, data filters, and relationships among them. The data stores represent databases in the system. Each of them can actually be represented as an entity-relationship diagram. The data filters represent operations undertaken by the system to transform the data that flows in the system. Each system feature can be mapped to a data filter, which makes dataflow diagrams very popular for the specification (and even design) of interactive systems (i.e. systems mostly governed by user interaction such as data input).

Note that each data filter in a dataflow diagram can be further elaborated with a lowerlevel diagram to show the details. This provides this technique with a very powerful and easily understandable abstraction mechanism. Dataflow diagrams, because of their direct relationship with system features, and their abstraction mechanism, could be the basis for communication between (almost-)non-technical users and technical developers.

Object-Oriented Analysis

Object-oriented analysis techniques are relatively new and immature, but flourishing rapidly along with the popularity of object-orientation (in design and programming) and the adoption of the UML in a large scale in academia, as well as in the industry. Generally speaking, an object-oriented analysis model describes the structure and relationships among entities within the problem description scope. Note that because of the widespread use of object-oriented programming and design, many people fail to grasp the difference between an object-oriented analysis model, and its design counterpart. This comes mainly from the extremely abstract nature of the concept of object. In specification models, objects actually represent entities in the problem description scope, which are, in many cases, different from the design objects, as the latter represent objects in the solution scope.

The use-case driven approach to requirements engineering, as seen previously, is a very good example of an object-oriented analysis approach. It uses use case diagrams to present the system’s functional features (use cases), and their relationships with the system’s environment (actors). Activity diagrams, sequence diagrams and collaboration diagrams are used to represent the fine-grained inter-relations between the objects in the problem description scope, whose static relationships are represented in class diagrams.

Interestingly, note that almost all other kinds of diagrams and techniques can be be objectified, exactly as C has been ”objectified” as C++.

Formal Techniques

Decision Trees and Decision Tables

Decision trees are tree-like diagrams used to describe complex logic relationships or conditions within a requirement. They are suitable for a requirement that deals with a combination of inputs or conditions, where different combinations of inputs lead to different outputs. Any decision tree can be formally translated in its decision table counterpart. Note that it is possible to formally and automatically analyze a decision table to verify its completeness and consistency. That possibility makes the technique one of the few really formal techniques.

State Transition Diagrams and Tables

State transition diagrams regard the system as a hypothetical machine, whose output and next state can be determined by the current state and the event that triggers a transition to this next state. As for decision trees, state transition diagrams can be formally translated in their state transition table counterpart. It is also possible to formally and automatically analyze a state transition table to verify its completeness and consistency.

State transition diagrams and tables are probably the most potent and popular specification techniques used in the industry. They are widely used for the description of reactive systems, communication protocols, and various other low-level systems more related to computer engineering than software engineering.

Formal Specification Languages: the Z Language

Z is a formal specification notation based on set theory. It has been developed at the Programming Research Group at the Oxford University Computing Laboratory since the late 1970s. It is probably now the most widely-used formal specification language, and an international standard for the Z notation is being developed under the guidance of ISO.

Z specifications are built from components called schemas, which are specifications building blocks. Graphical presentation of schemas make Z specifications easier to understand, compared to straight mathematical languages. The mathematical notation of schemas allows the building of formal completeness and consistency proofs to validate the specifications.

Z schemas

Z schemas introduce specification entities and defines invariant predicates over these entities. The predicates are Boolean expression, and some predicates can have side-effects that change the state of the entities involved. Schemas can be included in other schemas and may act as type definitions. The names defined in a schema are local to schemas, which solves the problem of duplicate names when developing large and complex specifications. In many respects, Z schemas are akin to objects. A schema includes:

• A name identifying the schema
• A signature introducing entities and their types
• A predicates part defining relationships between the entities in the signature by stating a logical expression which must always be true (an invariant) for the schema to apply.

Z conventions

• A schema name prefixed by the Greek letter Delta (∆) means that the operation changes some or all of the state variables introduced in that schema.
• A schema name prefixed by the Greek letter Xi (Ξ) means that the defined operation does not change the values of state variables.
• A schema name decorated with a ”?” represents an input
• A schema name decorated with a ”!” represents an output
• A schema name decorated with a quote mark (N') represents the value of the state variable N after an operation.

See the lecture slides for a simple example of formal specifications using the Z language.