7/24/2019 SRS-text

1/4

-. General principles of requirements engineering is a distinction between requirements definitions

and requirements specifications.

-. Many of the problems of software engineering are difficulties with the requirements specification.

7.1 Requirements definition

-. A software requirements definition is an abstract description of the services which the system

should provide and the constraints under which the system must operate.

-. System requirements may be either functional or non-functional requirements.

-. There are three types of major problem with requirements definitions written in natural language :

(1) Lack of clarity

(2) Requirements confusion

(3) Requirements amalgamation

-. Some organizations try to produce a single specification to act as both a requirements definition

and a requirements specification. When a requirements definition is combined with a specification there

is often confusion between concepts and details.

-. The first sentence in this requirement mixes up three different kindsof requirements :

(1) A conceptual, functional requirement states that the editing systemshould procide a grid.

(2) A non-functional requirement giving detailed information about the grid units.

(3) A non-functional user interface requirement which defines how that grid is switched on and

off by the user.

-. The most useful approach to writing a readable requirements definitionis to invent a standard format

and to ensure that all requirements definitions adhere to that format.

7/24/2019 SRS-text

2/4

7.2 Requirements specification

-. Requirements specifications add further information to the requirements definition.

-. Natural language is often used to write requirements specifications. However, a natural language specification

is not a particularly good basis for either a design or a contract between customer and system developer.

-. There are various alternatives to the use of natural language which add structure to the specification and which

should reduce ambiguity. These are :

(1) Structured natural language

(2) Design description language

(3) Requirements specification language

(4) Graphical notations

(5) Mathematical specifications

-. When requirements specifications are written, it is important that related requirements should be cross-referenced.

-. There are some simple methods of traceability that may be applied to any requirements definition of specification:

(1) All requirements should be assigned a unique number.

(2) Requirements should explicitly identify related requirements by refe

rring to their number.

(3) Each requirement document should contain a cross-reference matrix showing related requirements.

7.2.1 Structured language specifications

-. Structured natural language is a restricted form of natural languagefor requirements specification.

-. Special-purpose forms were designed to describe the input, output and

functions of an aircraft software

system.

-. A forms-based approach to requirements specification relies on defining one or more standard forms or

templates to express the requirements.

-. If a standard form is used for specificationn, the following informat

7/24/2019 SRS-text

3/4

ion should be included :

(1) The description of the function or entity being specified.

(2) A description of its inputs and where these come from.

(3) A description of its outputs and where these go to.

(4) An indication of what other entities are used.

(5) If a functional approach is used, a pre-condition setting out what must be true before the

function is called and a post-condition specifying that is true after the function is called.

(6) A description of the side-effects(if any) of the operation.

-. The form-based approach to specification may be used with formal mathematical specifications.

7.2.2 Requirements specification using a PDL

-. To counter the ingerent ambiguities in natural langyage specification, it is possible to describe requirements

operationally using a program description language or PDL.

-. Using a PDL may be the best way to provide this information in two situations :

(1) When an operation is specified as a sequence of simpler actions and the order of execution

is important.

(2) When hardware and software interfaces have to be specified.

-. There are disadvantages to this approach to requirements specification:

(1) The language used to write the specification may not be sufficiently expressive to describe

application domain concepts in an understandable way.

(2) The specification will be seen as an abstract design ratherthan a model to help the user

understand the system.

-. In principle, PDLs may be based on amy programming language.

-. An effective way to use this approach to specification is to combineit with the use of structured natural language.

-. Three types of interface which may have to be defined:

7/24/2019 SRS-text

4/4

(1) Procedural interfaces

(2) Data structures

(3) Representations of data

-. At a more detailed level, it may be necessary to specify the preciserepresentation of elements in the interface.

7.3 Non-functional requirements

-. Non-functional requirements define system properties and constraints.

-. Non-functional requirements are sometimes more critical than functional requirements.

-. Customers impose these process requirements for two reasons:

(1) System quality

(2) System maintainability

-. Classified Non-functional requirements depending on how they have beendericed :

+. Product requirements

+. Organizational requirements

+. External requiremetns

-. A very common error in requirements specifications is to confuse non-functional requirements with general goals of

the system customer.