CSCI 265 notes: software specifications


The product specifications are derived through extensive consultation with all people who are impacted by the software: the consultation might include interviews, fill-in forms, direct observation of existing system in action, trials on prototypes, etc.

The final specifications document for any mid-sized project should at least cover:

Note that the specifications must be as detailed and complete as possible - think of the specifications as a contract you are agreeing to fulfill, if they aren't precise then there can be major arguments later as to whether or not your software is acceptable and complete.

Performance and reliability specifications should also be expressed in a measurable form: e.g.


Requirements and specifications

Software requirements

A typical requirements engineering process

Complicating factors in formulating the requirements

Requirements analysis and modeling

Requirements validation

Requirements evolution:

Software Specifications

The specifications document
System Modelling
Formats for description:
Non-functional requirements and specifications

Formal Specifications

We consider three different techniques for formal specifications:
Pre- and Post-Conditions
Algebraic Specification
Here we specify the abstract data types to be modeled, and the associated operations
Model-based Specification
Yet another formal specification system is model-based - this requires using mathematical models (sets, functions, etc) to represent the system under study
Guidelines for formal methods
In Pressman quotes the "ten commandments of formal methods":