requirements part1 ch6

8/3/2019 Requirements Part1 Ch6

http://slidepdf.com/reader/full/requirements-part1-ch6 1/46

© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary

Use pursuant to company instruction

Chapter 6 - Software Requirements

Software Engineering - Phases





Objectives

To introduce the concepts of user and systemrequirements

To describe functional and non-functionalrequirements

To explain how software requirements may beorganised in a requirements document





Requirements engineering

Requirements are:

– the descriptions of the system services andconstraints that are generated during therequirements engineering process.

– Requirements reflects the needs of the customerand they solve some problem

Requirement Engineering

– 1. The process of establishing the services that thecustomer requires from a system and 2. theconstraints under which it operates and isdeveloped.

– the process of finding out, analysing, documentingand checking these services is called requirementengineering.


http://slidepdf.com/reader/full/requirements-part1-ch6 5/46 © 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary


Types of requirement

1. User requirements – Statements in natural language plus diagrams of the

services the system provides and its operational constraints.Written for customers.

2. System requirements – A structured document setting out detailed descriptions ofthe system’s functions, services and operationalconstraints.

– Defines what should be implemented so may be part of acontract between client and contractor.


http://slidepdf.com/reader/full/requirements-part1-ch6 6/46 © 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary


Library System Example - User and System requirements

1 . The so ftware m ust provide a means o f representing and

1 . accessing e x ternal files crea ted b y o ther too ls.

1 .1 The user shou ld be p rovided wi th facilities to d efine the type of

1 .2 external files.

1 .2 Each ex tern al file type ma y h ave an associa ted too l which ma y b e

1 .2 applied to the file.

1 .3 Each ex tern al fi le typ e ma y b e repr esented as a specific icon on

1 .2 the u ser’s d ispl ay.

1 .4 Facilities s hould be p rov ided fo r th e icon r epresenting an

1 .2 ex ternal file type to b e defined b y the u ser.1 .5 When a user selects an icon r epr esenting an e x ternal file, the

1 .2 effect o f that selection is to apply th e to ol associated with t he ty pe of

1 .2 the ex ternal fi le to t he file rep resen ted by the s elected icon.

User requir emen t defini tion

System requi r emen ts specificationUser

requirement

can beexpended

using multiple

system

requirements

User

requirements

are more

abstract


http://slidepdf.com/reader/full/requirements-part1-ch6 7/46 © 2006 Lucent Technologies. All Rights Reserved.

Lucent Technologies – ProprietaryUse pursuant to company instruction

Functional and non-functional requirements

1. Functional requirements – Statements of services the system should provide, how the system should

react to particular inputs and how the system should behave inparticular situations.

– Describe functionality or system services.

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

timing constraints, constraints on the development process, standards, etc.

3. Domain requirements – Requirements that come from the application domain of the system and

that reflect characteristics of that domain.




1. Functional requirements

Describe functionality or system services.

Depend on the type of software, expected users andthe type of system where the software is used.

– Functional user requirements may be high-level statementsof what the system should do but

– Functional system requirements should describe thesystem services in detail.




The LIBSYS system

A library system that provides a single interface to anumber of databases of articles in different libraries.

Users can search for, download and print these articlesfor personal study.





Examples of functional requirements

The user shall be able to search either all of the initialset of databases or select a subset from it.

The system shall provide appropriate viewers for theuser 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 tothe account’s permanent storage area.





Requirements completeness and consistency

In principle, requirements should be both complete and

consistent. 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 impossible to produce a complete and consistentrequirements document.

Ambiguous requirements may be interpreted in different ways bydevelopers and users – Problems arise when requirements are not precisely stated.





2. Non-functional requirements

These define system properties and constraints e.g. reliability,

response time and storage requirements. Constraints are I/Odevice capability, system representations, etc.

Process requirements may also be specified mandating aparticular CASE system, programming language or developmentmethod.

Non-functional requirements may be more critical than functionalrequirements. If these are not met, the system is useless.





Non-functional classifications

Product requirements

– Requirements which specify that the delivered product must behavein a particular way e.g. execution speed, reliability, etc.

Organisational requirements

– Requirements which are a consequence of organisational policies

and procedures e.g. process standards used, implementationrequirements, etc.

External requirements

– Requirements which arise from factors which are external to thesystem and its development process e.g. interoperabilityrequirements, legislative requirements, etc.





Non-functional requirement types

Performance

requir e me nts

Spa ce

re quir ements

Usa b ility

re quir e men ts

Effici ency

requir e me nts

Re liability

re quir ements

Porta bility

requir e me nts

Intero per ability

requir e me nts

Ethical

requir ements

Legislative

requir e men ts

Implem enta tion

requir e me nts

Standar ds

requir e me nts

Delivery

requir e me nts

Safety

requir e men ts

Privacy

requir ements

Product

re quir ements

Organisa ti onal

requir e me nts

External

requir ements

Non-f unct ionalrequir e me nts





Non-functional requirements examples

Product requirement

8.1 The user interface for LIBSYS shall be implemented assimple HTML without frames or Java applets.

Organisational requirement

9.3.2 The system development process and deliverabledocuments shall conform to the process and deliverablesdefined in XYZCo-SP-STAN-95.

External requirement7.6.5 The system shall not disclose any personal information

about customers apart from their name and reference numberto the operators of the system.





Requirements interaction

Conflicts between different non-functional requirementsare common in complex systems.

Spacecraft system – To minimise weight, the number of separate chips in the

system should be minimised. – To minimise power consumption, lower power chips should be

used.

– However, using low power chips may mean that more chips

have to be used. Which is the most critical requirement?





3. Domain requirements

Derived from the application domain and describe

system characteristics and features that reflect thedomain.

Domain requirements be new functional requirements,

constraints on existing requirements or define specificcomputations.

If domain requirements are not satisfied, the system

may be unworkable.





Library system domain requirements

There shall be a standard user interface to all

databases which shall be based on the Z39.50standard.

Because of copyright restrictions, some documents

shall be deleted immediately on arrival. Depending onthe user’s requirements, these documents will either beprinted locally on the system server for manuallyforwarding to the user or routed to a network printer.





Requirement Types / Classification 2

User Requirements

System Requirements





User requirements

Should describe functional and non-functional

requirements in such a way that they areunderstandable by system users who don’t havedetailed technical knowledge

User requirements are defined using natural language,tables and diagrams as these can be understood by allusers.





Problems with natural language

Lack of clarity – Precision is difficult without making the document difficult to

read.

Requirements confusion – Functional and non-functional requirements tend to be mixed-

up.

Requirements mixture – Several different requirements may be expressed together.

Example 1 of Problematic requirements





Example 1 of Problematic requirementsLIBSYS requirement

4..5 LIBSYS shall provide a financial accounting system

that maintains records of all payments made by users of

the system. System managers may configure this system

so that regular users may receive discounted rates.

Example 2 of Problematic requirements





Example 2 of Problematic requirementsEditor grid requirement

2.6 Grid facilities To assist in the positioning of entities on a diagram,

the user may turn on a grid in either centimetres or inches, via an

option on the control panel. Initially, the grid is off. The grid may be

turned on and off at any time during an editing session and can be

toggled between inches and centimetres at any time. A grid optionwill be provided on the reduce-to-fit view but the number of grid

lines shown will be reduced to avoid filling the smaller diagram

with grid lines.





Requirement problems

Database requirements includes both conceptual and detailed

information – Describes the concept of a financial accounting system that is to be

included in LIBSYS;

– However, it also includes the detail that managers can configure thissystem - this is unnecessary at this level.

Grid requirement mixes three different kinds of requirement

– Conceptual functional requirement (the need for a grid);

– Non-functional requirement (grid units);

– Non-functional UI requirement (grid switching).





Guidelines for writing requirements

Invent a standard format and use it for all requirements. – Be consistent

Use language in a consistent way. Use shall formandatory requirements, should for desirable

requirements.

Use text highlighting to identify key parts of therequirement.





System requirements

More detailed specifications of system functions,

services and constraints than user requirements.

They are intended to be a basis for designing thesystem.

They may be incorporated into the system contract.

System requirements may be defined or illustrated

using system models discussed in Chapter 8.





Requirements and design

In principle, requirements should state what the system

should do and the design should describe how itdoes this.

In practice, requirements and design are inseparable

– A system architecture may be designed to structure therequirements;

– The system may inter-operate with other systems thatgenerate design requirements;

– The use of a specific design may be a domain requirement.





Structured language specifications

The freedom of the requirements writer is limited by a

predefined template for requirements.

All requirements are written in a standard way.

The terminology used in the description may be limited.

The advantage is that the most of the expressivenessof natural language is maintained but a degree of

uniformity is imposed on the specification.





Form-based specifications

Definition of the function or entity.

Description of inputs and where they come from.

Description of outputs and where they go to.

Indication of other entities required.

Pre and post conditions (if appropriate).

The side effects (if any) of the function.





Form-based node specification

InsulinPump/Control Sof tware/SRS/3.3.2

Function Computeinsulindose: Safe sugar level

Description Computes the dose of insulin tobedelivered whenthe current measuredsugar levelis in

the safe zone between 3 and 7 units.

Inputs Currentsugar reading (r2),the previous two readings (r0and r1)

Source Currentsugar reading fromsensor. Other readings frommemory.

OutputsCompDoseŠthe dose ininsulintobe delivered

Destination Maincontrol loop

Action:CompDoseis zero if the sugar level is stable or falling or if the level is increasing but the rate of

increase is decreasing. If the level is increasing and the rateof increase is increasing, then CompDose is

computed by dividing the difference betweenthe current sugar leveland the previous levelby 4 and

rounding theresult. Ifthe result ,is rounded to zerothenCompDose is set to the minimumdose that can

be delivered.

Requires Twoprevious readings so thatthe rateof change of sugarlevelcanbecomputed.

Pre-condition The insulin reservoir contains atleastthe maximumallowed single dose ofinsulin..

Post-condition r0is replaced byr1 thenr1is replaced by r2

Side-effects None





Graphical models

Graphical models are most useful when you need to

show how state changes or where you need to describea sequence of actions.

Different graphical models are explained in Chapter 8.





Sequence diagrams

These show the sequence of events that take place

during some user interaction with a system. You read them from top to bottom to see the order of

the actions that take place.

Cash withdrawal from an ATM

– Validate card; – Handle request;

– Complete transaction.





Sequence diagram of ATM withdrawal

ATM Database

CardCard number

Card OK PIN request

PIN

Option menu

<<exception>>invalid card

Withdraw request

Amount request

Amount

Balance requestBalance

<<exception>>insuf ficient ca sh

Debit (amount)

Debit response

Card

Card removed

Cash

Cash removed

Receipt

Validate card

Handle request

Completetransaction





The requirements document

The 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 thanHOW it should do it





Users of a requirements document





IEEE requirements standard

Defines a generic structure for a requirements

document that must be instantiated for each specificsystem. – Introduction.

– General description.

– Specific requirements.

– Appendices.

– Index.





Requirements document structure

Preface

Introduction Glossary

User requirements definition

System architecture

System requirements specification

System models

System evolution

Appendices

Index





For the project please use the template specified in

– http://www.cs.iit.edu/~oaldawud/CS487/project/requirement_specification_document_template.htm

– See next slides

http://www.cs.iit.edu/~oaldawud/CS487/project/requirement_specification_document_template.htm









SOFTWARE REQUIREMENTS SPECIFICATION TEMPLATE

To develop the software requirements specification, you must

understand the objects the system will manipulate (informationdomain), the services (functions) the system will perform, theconstraints on the project (time, money and technical) and theperformance expected (timing). As you develop the softwarerequirements specification, you may need to re-interview theclient. Do not hesitate to do so. Please E-mail with questions orcome to my office hours if you need to.

The software requirements specification focuses on what thesystem will do, not how the system will be implemented. It isproduced as the culmination of the software requirementsengineering phase in the process model. You must analyze theinformation domain, the function, performance, behavior andinterface requirements of the system.

Your document should follow the template below. It is a modifiedversion of the Pressman's Adaptable Process Model template fora software requirements document.

1 0 I t d ti





1.0 Introduction

This section provides an overview of the entire requirement document. This document describesall data, functional and behavioral requirements for software.

1.1 Goals and objectives

Overall goals and software objectives are described.

1.2 Statement of scope

A description of the software is presented. Major inputs, processing functionality and outputs aredescribed without regards to implementation detail. Rank the major processing functionality fromthe developer's point of view. Use a simple ranking system such as: essential, desirable andfuture requirements. This should represent what you think your team can accomplish in the timeframe of a semester. The essential requirements, you are sure you can complete. The desirablerequirements you hope to complete, but are not sure about. The future requirements, you have

strong doubts about. Strive to balance the desires of your client with the reality of the time ittakes to develop a SW product.

1.3 Software context

The software is placed in a business or product line context. Strategic issues relevant to contextare discussed. The intent is for the reader to understand the 'big picture'.

1.4 Major constraints

Any business or product line constraints that will impact the manner in which the software is tobe specified, designed, implemented or tested are noted here.

2 0 U i





2.0 Usage scenario

This section provides a usage scenario for the software. It organizesinformation collected during requirements elicitation into use-cases.

2.1 User profiles

The profiles of all user categories are described here.

2.2 Use-cases

All use-cases for the software are presented. 2.2.1 Use-Case Diagram

A UML Use-Case diagram is presented. 2.2.2 Use-Case Descriptions

Each specific usage scenario is described.

2.3 Special usage considerations

Special requirements associated with the use of the software arepresented.

2.4 Activity Diagrams or Sequence Diagram

The graphical representation of the workflow of all use-cases may bepresented. (This section is optional.)

3 0 D t M d l d D i ti





3.0 Data Model and Description

This section describes the information domain for the

software. 3.1 Data objects

Data objects and their major attributes are described.

3.2 Relationships

Relationships among data objects are described. 3.3 Complete data model

ERD-like model of the data objects and relationships.

4 0 Functional Model and Description





4.0 Functional Model and Description

This section describes the static structure of the software.

4.1 Class diagrams

The class hierarchy (OO) is presented.

4.2 Software Interface Description

The software interface(s)to the outside world is(are) described.

4.2.1 External machine interfaces

Interfaces to other machines (computers or devices) aredescribed.

4.2.2 External system interfaces

Interfaces to other systems, products or networks are described.

4.2.3 Human interface

An overview of any human interfaces to be designed for thesoftware is presented.

5 0 Behavioral Model and Description





5.0 Behavioral Model and Description

A description of the behavior of the software is presented.

5.1 Description for software behavior

A detailed description of major events and states is presented inthis section.

5.1.1 Events

A listing of events (control, items) that will cause behavioral

change within the system is presented. 5.1.2 States

A listing of states (modes of behavior) that will result as aconsequence of events is presented.

5.2 Statechart Diagram

Depict the overall behavior of the system.

6 0 Restrictions Limitations and Constraints





6.0 Restrictions, Limitations, and Constraints

Special issues which impact the specification, design,

or implementation of the software are noted here.

7 0 Validation Criteria





7.0 Validation Criteria

7.0 Validation Criteria

The approach to software validation is described. 7.1 Classes of tests

The types of tests to be conducted are specified,including as much detail as is possible at this stage.

Emphasis here is on black- box testing. 7.2 Expected software response

The expected results from testing are specified.

7.3 Performance bounds

Special performance requirements are specified.

requirements part1 ch6

Documents