Page 232 - DCAP405_SOFTWARE_ENGINEERING

Unit 13: Building the Analysis Model

Graphical notation Notes
Formal specification

The System Definition Document

This document (occasionally known as the user requirements document or concept of operations)
records the system requirements. It describes the high-level system requirements from the
domain perspective. Its readership includes representatives of the system users/customers
(marketing may play these roles for market-driven software), so its content must be understood
in terms of the domain. The document lists the system requirements along with background
information about the overall objectives for the system, its target environment and a statement
of the constraints, assumptions, and non-functional requirements.

Notes It may include conceptual models designed to illustrate the system context, usage
scenarios and the principal domain entities, as well as data, information, and workflows.

System Requirements Specification

Developers of systems with substantial software and non-software components, a modern airliner,
for example, often separate the description of system requirements from the description of
software requirements. In this view, system requirements are specified, the software requirements
are derived from the system requirements, and then the requirements for the software
components are specified. Strictly speaking, system requirements specification is a systems
engineering activity and falls outside the scope of this Guide.

Software Requirements Specification

Software requirements specification establishes the basis for agreement between customers and
contractors or suppliers (in market-driven projects, these roles may be played by the marketing
and development divisions) on what the software product is to do, as well as what it is not
expected to do. For non-technical readers, the software requirements specification document is
often accompanied by a software requirements definition document.
Software requirements specification permits a rigorous assessment of requirements before design
can begin and reduces later redesign. It should also provide a realistic basis for estimating
product costs, risks, and schedules.

Organizations can also use a software requirements specification document to develop their
own validation and verification plans more productively.
Software requirements specification provides an informed basis for transferring a software
product to new users or new machines. Finally, it can provide a basis for software enhancement.
Software requirements are often written in natural language, but, in software requirements
specification, this may be supplemented by formal or semi-formal descriptions. Selection of
appropriate notations permits particular requirements and aspects of the software architecture
to be explained more precisely and concisely than natural language. The general rule is that
notations should be used which allow the requirements to be explained as precisely as possible.
This is particularly crucial for safety-critical and certain other types of dependable software.
However, the choice of notation is often constrained by the training, skills and preferences of
the document’s authors and readers.

LOVELY PROFESSIONAL UNIVERSITY 225