January28.Doc

7/26/2019 January28.Doc

1/26

Ian Sommerville 2000 Software Engineering, 6th edition. Slide 1

Overview of Software Requirements

Descriptions and specifications of a system andthe process whereby they are derived

Objectives To introduce the concepts of user and system requirements

To describe functional and non-functional requirements

To describe the principal requirements engineeringactivities

To introduce techniques for requirements elicitation and

analysis


2/26


Requirements engineering

The process of establishing the services that the

customer requires from a system and the constraints

under which it operates and is developed

The requirements themselves are the descriptions ofthe system services and constraints that are generated

during the requirements engineering process

Requirements specify whatthe system is supposed to

do, but not how the system is to accomplish its task


3/26


What is a requirement?

It may span a wide range of statements from a high-level abstract statement of a service or of a system constraint

to a detailed mathematical functional specification

Types of requirements User requirements

System requirements

Software specificationsprovide more (design) detail


4/26


User requirements

Should describe functional and non-functionalrequirements so that they are understandable bysystem users who dont have detailed technicalknowledge

User requirements are defined using natural language,tables, and diagrams

Problems with natural language Precision vs. understandability

Functional vs. non-functional requirements confusion Requirements amalgamation


5/26Ian Sommerville 2000 Software Engineering, 6th edition. Slide 5

System requirements

More detailed specifications of user requirements

Serve as a basis for designing the system

May be used as part of the system contract

System requirements may be expressed using systemmodels discussed on January 30



Definitions and specifications

1 . Th e s of t w a re m u st pr o v id e a m e a ns o f r e pr e se n ti ng a n d

1.a c c e ss in g e x te r na l f i le s c r e a t ed by othe r t oo ls .

1 .1 The us e r sh ou ld b e pr o v id ed w it h f a c ili ti e s to de f i ne th e ty pe of1.2e x te r na l f i le s.1 .2 Ea c h e x te r na l f i le t yp e m a y hav e a n a ss oc i at ed t oo l w h ic h m a y be1.2a p pl ie d to th e f i le.1 .3 Ea c h e x te r na l f i le t yp e m a y be r e pr e sen te d a s a s pe c i f ic i c on o n1.2t he u se rs di sp la y.1 .4 Fa c il it ie s s ho ul d b e p r ov id ed f o r th e ico n re pr e se n ti ng a n

1.2e x te r na l f i le t yp e t o b e d e f in e d by th e us e r .1 .5 W h en a u se r se l e c ts a n ic o n r e pr e se n ting a n e x te r na l f i le, th e1.2e f f e c t of th a t s e le c t io n is to a p pl y t he to ol a ss oc i a te d w it h t he ty pe o f

1.2t he e x te r n a l f il e to t he f i le r e pr e s e nt e d b y th e se l e c te d i c on .

Requirementsdefinition

Requirementsspecification



Functional and non-functional requirements

Functional requirements Statements of services the system should provide, how the system

should react to particular inputs and how the system should behave in

particular situations.

Non-functional requirements constraints on the services or functions offered by the system such as

timing constraints, constraints on the development process, standards,

etc.

Domain requirements Requirements that come from the application domain of the system

and that reflect characteristics of that domain



Examples of functional requirements

The user shall be able to search either all of the initial

set of databases or select a subset from it.

The system shall provide appropriate viewers for the

user to read documents in the document store. Every order shall be allocated a unique identifier

(ORDER_ID) which the user shall be able to copy to

the accountspermanent storage area.


9/26


Requirements precision, completeness, and

consistency

In principle requirements should be precise, complete,and consistent

Precise They should state exactlywhat is desired of the system

Complete They should include descriptions of all facilities required

Consistent There should be no conflicts or contradictions in the descriptions of

the system facilities In practice, it is very difficult to produce a complete

and consistent requirements document


10/26


Ambiguous/imprecise requirement

4.A.5 The database shall only support the generation and

control of configuration objects; that is, objects which are

themselves groupings of other objects in the database. The

configuration control facilities shall allow access to the objects

in a version group by the use of an incomplete name.

What about non-configuration objects?

What about other database functionality?

What about level of service other than support?

Something else?


11/26


Non-functional requirement types

Performancerequirements

Spacerequirements

Usabilityrequirements

Efficiencyrequirements

Reliabilityrequirements

Portabilityrequirements

Interoperabilityrequirements

Ethicalrequirements

Legislativerequirements

Implementationrequirements

Standardsrequirements

Deliveryrequirements

Safetyrequirements

Privacyrequirements

Productrequirements

Organizationalrequirements

Externalrequirements

Non-functionalrequirements


12/26


Non-functional requirements examples

Product requirement 4.C.8 It shall be possible for all necessary communication between the APSE

and the user to be expressed in the standard Ada character set

Organisational requirement

9.3.2 The system development process and deliverable documents shallconform to the process and deliverables defined in XYZCo-SP-STAN-95

External requirement 7.6.5 The system shall not disclose any personal information about

customers apart from their name and reference number to the operators of the

system


13/26


Non-functional requirements measures

Pro perty Meas ureSpeed P rocessed t ransactions /second

User/Event response timeScreen refresh t ime

Size K BytesNumber of RAM chips

Ease of use Training timeNumber of help frames

Rel iabi li ty Mean time to failureP robabil ity of unavailabilityRate of failu re occu rrenceAvailability

Robustness Time to restart aft er failureP ercentage of events caus ing fail ureP robabil ity of data corrupt ion on failure

P ortabi li ty P ercent age of target dependent st at ement sNumber of t arget syst ems


14/26


Requirements interaction

Conflicts between different non-functional

requirements are common in complex systems

Spacecraft system

To minimise weight, the number of separate chips in thesystem should be minimised

To minimise power consumption, lower power chips should

be used

But, using low power chips may mean that more chips haveto be used

Which is the most critical requirement?


15/26


Domain Requirement:Train protection system

The deceleration of the train shall be computed as:

Dtrain= Dcontrol+ Dgradient

whereDgradient is 9.81ms2 * compensated gradient/alphaand where the

values of 9.81ms2/alphaare known for different types of train.

Problems

Understandability

Requirements are expressed in the language of the application domain

This is often not understood by software engineers

Implicitness

Domain specialists understand the area so well that they do not think of

making the domain requirements explicit


16/26


Requirements document requirements

Specify external system behaviour

Specify implementation constraints

Easy to change

Serve as reference tool for maintenance Record forethought about the life cycle of the system

i.e. predict changes

Characterise responses to unexpected events

U f


17/26

Users of a

requirements

document

Use the requirements todevelop validation tests forthe system

Use the requirementsdocument to plan a bid forthe system and to plan the

system development process

Use the requirements to

understand what system is tobe developed

System testengineers

Managers

System engineers

Specify the requirements andread them to check that they

meet their needs. Theyspecify changes to therequirements

System customers

Use the requirements to help

understand the system andthe relationships between its

parts

Systemmaintenance

engineers


18/26


Requirements engineering process

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirements

validation

Feasibility

reportSystemmodels

User and systemrequirements

Requirementsdocument


19/26


Feasibility studies

A feasibility study decides whether or not the

proposed system is worthwhile

A short focused study that checks

If the system contributes to organisational objectives If the system can be engineered using current technology and

within budget

If the system can be integrated with other systems that are

used


20/26


Elicitation and analysis

Sometimes called requirements elicitation orrequirements discovery

Involves technical staff working with customers tofind out about

the application domain the services that the system should provide

the systems operational constraints

May involve end-users, managers, engineers involvedin maintenance, domain experts, trade unions, etc. These are calledstakeholders


21/26


Problems of requirements analysis

Stakeholders dont know what they really want

Stakeholders express requirements in their own terms

Different stakeholders may have conflicting

requirements Organisational and political factors may influence the

system requirements

The requirements change during the analysis process

New stakeholders may emerge and the business environmentchange


22/26


System models

Different models may be produced during the

requirements analysis activity

Requirements analysis may involve three structuring

activities which result in these different models PartitioningIdentifies the structural (part-of) relationships between entities

AbstractionIdentifies generalities among entities

ProjectionIdentifies different ways of looking at a problem

System models will be covered on January 30


23/26


Scenarios

Scenarios are descriptions of how a system is used in

practice

They are helpful in requirements elicitation as people

can relate to these more readily than abstract

statement of what they require from a system

Scenarios are particularly useful for adding detail to

an outline requirements description


24/26


Requirements validation

Concerned with demonstrating that the requirementsdefine the system that the customer really wants

Requirements error costs are high so validation is veryimportant

Fixing a requirements error after delivery may cost up to 100 times thecost of fixing an implementation error

Requirements checking Validity

Consistency

Completeness Realism

Verifiability


25/26


Requirements validation techniques

Reviews Systematic manual analysis of the requirements

Prototyping Using an executable model of the system to check requirements.

Test-case generation Developing tests for requirements to check testability

Automated consistency analysis Checking the consistency of a structured requirements description


26/26


Key points

Requirements set out what the system should do anddefine constraints on its operation and implementation Functional requirements set out services the system should provide

Non-functional requirements constrain the system being developed orthe development process

The requirements engineering process includes afeasibility study, requirements elicitation and analysis,requirements specification and requirementsmanagement

Requirements validation is concerned with checks forvalidity, consistency, completeness, realism andverifiability

Date post:	03-Mar-2018
Category:	Documents
Upload:	nivitha
View:	219 times
Download:	0 times

January28.Doc

Documents