5.1-Req Specs p1.pptx

Requirements specification

• _{The process of writing down the user and system}

requirements in a requirements document.

• _{User requirements have to be understandable by}

end-users and customers who do not have a technical background.

• _{System requirements are more detailed requirements and}

may include more technical information.

• _{The requirements may be part of a contract for the system}

development

– _{It is therefore important that these are as complete as}

The software requirements document

•

_{The software requirements document is the}

official statement of what is required of the

system developers.

•

_{Should include both a definition of user}

requirements and a specification of the system

requirements.

•

_{It is NOT a design document. As far as possible, it}

should set of WHAT the system should do rather

than HOW it should do it.

Agile methods and requirements

• _{Many agile methods argue that producing a requirements}

document is a waste of time as requirements change so quickly.

• _{The document is therefore always out of date.}

• _{Methods such as XP use incremental requirements}

engineering and express requirements as ‘user stories’.

• _{This is practical for business systems but problematic for}

systems that require a lot of pre-delivery analysis (e.g. critical systems) or systems developed by several teams.

Requirements document variability

• _{Information in requirements document depends on type of}

system and the approach to development used.

• _{Systems developed incrementally will, typically, have less}

detail in the requirements document.

• _{Requirements documents standards have been designed e.g.}

IEEE standard. These are mostly applicable to the requirements for large systems engineering projects.

Ways of writing a system requirements

specification

Notation Description

Natural language The requirements are written using numbered sentences in natural language. Each sentence should express one requirement.

Structured natural language

The requirements are written in natural language on a standard form or template. Each field provides information about an aspect of the requirement.

Graphical notations Graphical models, supplemented by text annotations, are used to define the functional requirements for the system; UML use case and sequence diagrams are commonly used.

Mathematical

specifications These notations are based on mathematical concepts such as finite-state machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don’t understand a formal specification. They cannot check that it represents what they want and are reluctant to accept it as a system contract

Natural language specification

•

_{Requirements are written as natural language}

sentences supplemented by diagrams and

tables.

•

_{Used for writing requirements because it is}

expressive and universal. This means that the

requirements can be understood by users and

customers.

Example requirements for the insulin pump

software system

3.2 The system shall measure the blood sugar and deliver insulin, if required, every 10 minutes. (Changes in blood sugar are relatively slow so more frequent measurement is

unnecessary; less frequent measurement could lead to unnecessarily high sugar levels.)

3.6 The system shall run a self-test routine every minute with the conditions to be tested and the associated actions defined in Table 1. (A self-test routine can discover hardware and

software problems and alert the user to the fact the normal operation may be impossible.)

Functional requirements for the

MHC-PMS



A user shall be able to search the

appointments lists for all clinics.



The system shall generate each day, for

each clinic, a list of patients who are

expected to attend appointments that day.



Each staff member using the system shall

be uniquely identified by his or her 8-digit

employee number.

Requirements imprecision

_{Problems arise when requirements are not precisely}

stated.

_{Ambiguous requirements may be interpreted in different}

ways by developers and users.

_{Consider the term ‘search’ in requirement 1}

_{User intention – search for a patient name across all}

appointments in all clinics;

_{Developer interpretation – search for a patient name}

The Language of Requirements

• _{The use of consistent language makes it easier to identify}

different kinds of requirements.

• _{A simple example of this is the use of “shall” as a key word to}

indicate the presence of a requirement in the text.

• _{Some approaches go so far as to use “shall”, “should” and}

“may” to indicate different priorities of requirement.

• _{stakeholder requirements are primarily concerned with}

capability and constraints on capability.

• _{A capability statement should express a (single) capability}

required by one or more identified stakeholder types (or user groups).

The Language of Requirements

• _{A typical capability requirement takes the following form:}

The < stakeholder type > shall be able to < capability>.

• _{Where there are some aspects of performance or constraint}

associated solely with the requirement, they may also be stated in the text, for instance giving the form:

The < stakeholder type > shall be able to < capability > within < performance > of < event >

while < operational condition>.

• _{The weapons operator shall be able to fire a missile within 3}

seconds of radar sighting while in severe sea conditions.

• _{The < system > shall < function > <object > every < performance >}

<units>.

Problems with natural language

•

_{Lack of clarity}

– _{it is sometimes difficult to use language in a precise and}

unambiguous way, without making the document wordy and difficult to read

•

_{Requirements confusion}

– _{Functional, non-functional requirements and design}

information tend to be mixed-up.

•

_{Requirements amalgamation}

– _{Several different requirements may be expressed together}

Using Attributes for requirements

• _{A simple textual statement is not sufficient fully to define a requirement;}

there is other classification and status information that each requirement carries.

• _{Rather than clutter the text of a requirement, additional information should}

be placed in “attributes” attached to the requirement.

• _{Attributes allow the information associated with a single requirement to be}

structured for ease of processing, filtering, sorting, etc.

• _{[SH234] The ambulance control system shall be able to handle up to 100}

simultaneous emergency calls.

– _{Source: R. Thomas} – _{Priority: Mandatory} – _{Release: 1}

– _{Review status: Accepted} – _{Verifiable: Yes}

C

at

eg

o

rie

s o

f a

tt

rib

u

te

Structured specifications

•

_{An approach to writing requirements where}

the freedom of the requirements writer is

limited and requirements are written in a

standard way.

•

_{This works well for some types of requirements}

–

_{e.g. requirements for embedded control system but}

is sometimes too rigid for writing business system

requirements.

Form-based specifications

•

_{Definition of the function.}

•

_{Description of inputs and where they come}

from.

•

_{Description of outputs and where they go to.}

•

_{Description of the action to be taken.}

•

_{Pre and post conditions (if appropriate).}

•

_{The side effects (if any) of the function.}

A structured specification of a requirement

for an insulin pump

A structured specification of a requirement

for an insulin pump

Criteria for Writing Requirements Statements

--Individual

•

_{There are certain criteria that every statement of}

requirement should meet.

•

_Atomic

_:

_{each statement carries a single traceable}

element.

•

_Feasible

_:

_{technically possible within cost and schedule.}

•

_Legal

_:

_{legally possible.}

Criteria for Writing Requirements Statements

--Individual

• _{Unambiguous: An requirement is unambiguous if, and only if,}

requirement stated therein has only one interpretation.

– _{“A user shall be able to search the appointments lists for}

all clinics.”

– _{“Aircraft that are nonfriendly and have an unknown}

mission or the potential to enter restricted airspace within 5 minutes shall raise an alert”

• _{Combination of “and” and “or” make this an ambiguous}

requirement

• _{In cases where a term used in a particular context could have}

multiple meanings, the term should be included in a glossary where its meaning is made more specific.

•

_Verifiable

_:

_{A requirement is verifiable if and only if}

there exists some

finite cost effective process

with

which a

person or machine

can check that the actual

as-built software product meets the requirement

•

_{Each statement must be verifiable, and it is known}

how.

–

_{Non-verifiable requirements include statements}

such as “works well”, “good human interface”, and

shall “usually happen”.

Criteria for Writing Requirements Statements

--Individual

Criteria for Writing Requirements Statements—Set of

requirements

• _{In addition, there are other criteria that apply to the set of}

requirements as a whole:

• _{Complete: An SRS is complete if, and only if, it includes the}

following elements:

• _{All significant requirements, whether relating to functionality}

or constraints.

• _{Definition of the responses of the software to all realizable}

classes of input data in all realizable classes of situations.

– _{Note that it is important to specify the responses to both valid and}

invalid input values.

• _{Full labels and references to all figures, tables, and diagrams}

Criteria for Writing Requirements Statements—Set of

requirements

•

_Consistent

• _{The specified characteristics of real-world objects may conflict.} – _{the format of an output report may be described in one}

requirement as tabular but in another as textual.

• _{There may be logical or temporal conflict between two specified}

actions. For example,

– _{One requirement may specify that the program will add two inputs}

and another may specify that the program will multiply them. (logical)

– _{One requirement may state that A must always follow B, while}

another may require that A and B occur simultaneously. (temporal)

• _{Two or more requirements may describe the same real-world object}

but use different terms for that object.

– _{For example, a program request for a user input may be called a}

prompt in one requirement and a cue in another. The use of standard terminology and definitions promotes consistency.

Criteria for Writing Requirements Statements—Set of requirements

•

_{Non-redundant}

_:

_{each requirement is}

expressed once.

•

_Modular

_:

_{requirements statements that}

belong together are close to one another.

•

_Structured

_:

_{there is a clear structure to the}

Summary:

Guidelines for writing requirements

• _{Invent a standard format and use it for all requirements.}

(single sentence!!)

• _{Use language in a consistent way. Use shall for}

mandatory requirements, should for desirable requirements.

• _{Use text highlighting to identify key parts of the}

requirement.

• _{Avoid the use of computer jargon (specialised words).} • _{Include an explanation (rationale) of why a requirement}