Requirements Part1 Ch6

Chapter 6 - Software Requirements
Software Engineering - Phases
2006 Lucent Technologies. All Rights Reserved.
Lucent Technologies Proprietary Use pursuant to company instruction
Objectives
To introduce the concepts of user and system
requirements
To describe functional and non-functional

requirements
To explain how software requirements may be

organised in a requirements document
Requirements engineering
Requirements are:
the descriptions of the system services and constraints that are generated during the requirements engineering process. Requirements reflects the needs of the customer and they solve some problem
Requirement Engineering
1. The process of establishing the services that the customer requires from a system and 2. the constraints under which it operates and is developed. the process of finding out, analysing, documenting and checking these services is called requirement engineering.
2006 Lucent Technologies. All Rights Reserved. Lucent Technologies Proprietary Use pursuant to company instruction
What is a requirement?
It may range from a high-level abstract statement of a
service or of a system constraint to a detailed mathematical functional specification. This is inevitable as requirements may serve a dual function
May be the basis for a bid for a contract - therefore must be open to interpretation; May be the basis for the contract itself - therefore must be defined in detail; Both these statements may be called requirements.
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 of the systems functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.
Library System Example - User and System requirements

User requ ir emen t d efin itio n 1 . Th e so ftware m u st p rov id e a means o f representin g an d 1 . acces sing e x tern al files crea ted b y o th er too ls.
User requirement can be expended using multiple system requirements
User requirements are more abstract
Sys tem requ ir emen ts s pecificatio n 1 .1 1 .2 1 .2 1 .2 1 .3 1 .2 1 .4 1 .2 1 .5 1 .2 1 .2 Th e us er s ho u ld b e p rov id ed with facilities to d efin e th e ty p e of external files . Each ex tern al file ty p e ma y h ave an as so cia ted to o l wh ich ma y b e app lied to th e file. Each ex tern al file ty p e ma y b e repr esented as a sp ecific ico n on the u s ers d is play . Facilities s h ou ld b e p ro v id ed fo r th e ico n r epresentin g an ex tern al file ty p e to b e defined b y th e u ser. Wh en a us er s elects an icon r epr esentin g an e x tern al file, th e effect o f th at s electio n is to app ly th e to ol as s ociated with th e ty pe o f the ex tern al file to the file rep resen ted by the s elected ico n.
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 in particular 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 and
the type of system where the software is used.
Functional user requirements may be high-level statements of what the system should do but Functional system requirements should describe the system services in detail.
The LIBSYS system

A library system that provides a single interface to a
number of databases of articles in different libraries.
Users can search for, download and print these articles

for personal study.
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 accounts 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 consistent
requirements document.
Ambiguous requirements may be interpreted in different ways by

developers 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/O device capability, system representations, etc.
Process requirements may also be specified mandating a

particular CASE system, programming language or development method.
Non-functional requirements may be more critical than functional

requirements. If these are not met, the system is useless.
Non-functional classifications
Product requirements
Requirements which specify that the delivered product must behave in 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, implementation requirements, etc.
External requirements
Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.
Non-functional requirement types

Non-funct ional re quir e me nts
Product re quir e me nts
Organisa ti onal re quir e me nts
E xt erna l re quir e me nts
E ffi ci ency re quir e me nts
Re liabili ty re quir e me nts
Porta bili ty re quir e me nts
Inte r ope r a bili ty re quir e me nts
E thic al re quir e me nts
Usa bili ty re quir e me nts
Del ive ry re quir e me nts
Imple menta ti on re quir e me nts
Standar ds re quir e me nts
L egislative re quir e me nts
Pe rformanc e re quir e me nts
Spa ce re quir e me nts

Pri va cy re quir e me nts
Safe ty re quir e me nts
Non-functional requirements examples

Product requirement
8.1 The user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets.
Organisational requirement
9.3.2 The system development process and deliverable documents shall conform 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.
Requirements interaction
Conflicts between different non-functional requirements
are 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 the domain.
Domain requirements be new functional requirements,

constraints on existing requirements or define specific computations.
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.50 standard.
Because of copyright restrictions, some documents

shall be deleted immediately on arrival. Depending on the users requirements, these documents will either be printed locally on the system server for manually forwarding 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 are understandable by system users who dont have detailed technical knowledge
User requirements are defined using natural language,

tables and diagrams as these can be understood by all users.
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 mixedup.
Requirements mixture
Several different requirements may be expressed together.
Example 1 of Problematic requirements LIBSYS 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 Editor 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 option will 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 this system - 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 for

mandatory requirements, should for desirable requirements.
Use text highlighting to identify key parts of the

requirement.
System requirements
More detailed specifications of system functions,
services and constraints than user requirements.
They are intended to be a basis for designing the

system.
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 it does this.
In practice, requirements and design are inseparable

A system architecture may be designed to structure the requirements; The system may inter-operate with other systems that generate 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 expressiveness
of 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

In li P m /C n l S tw e/ RS 3 su n u p o tro of ar S /3. .2 F nti o uc n C p t e su d se S fesu ar lev omu in lin o : a g el D scr tion e ip C p t e t h d e o ins l t o de er wh th c rre t m sur ds g le elis i omu s e os f uin be liv ed en e u n ea e u ar v n th sa zo eb w n3 a d7 u t s e fe n et ee n ni . Inp C re t su ar redi g(r2 th p v u t o ea in s (r an r) u ts ur n g a n ), e re io s w r d g 0 d 1 S u ce C re t su ar redi gfro s so Oh redi g fro mm ry or ur n g a n m en r. t er a n s m e o . O u C p o t h d einin lintob d iv d tputsomD se e os su e el ere D sti ntio e a n M nc n l lo p ai o tro o A io : omD seis zer if th su a le e is st le o fa g o if th leve is in as g b t th rat o ct n C p o o e gr vl ab r llin r e l cre in u e e f in rea is d rea g If th le e is inc si g a d t h rat e f in rea is in rea n , th n C p o is c se ec sin . e vl rea n n e o c se c si g e omD se c p t e b d id g th d er nc b een e c rre t su ar le el an th p v u le el b 4 an omu d y iv in e iff e e etw th u n g v d e re io s v y d ro n in there lt. Ifth re lt ,is ro n e to ze th C m o isse to th mi m umo th c ud g su e su udd ro en o pDse t e ni d se at an b d v red e eli e . R q ire eu s Preonitio -c d n S e ffect id -e s T opr v us ead gs oth th rat e c an eo s g le elcan co u . w e io r in s at e of h g f u ar v be mpted T e nslin e rv ir c ntin atleatth m x h i u rse o o a s s e a imumlo e sin led seofi u .. al w d g o nslin Nn oe
P t-c n tio r0is ep db r1th r1is re laced y 2 os o di n r lace y en p br
Graphical models
Graphical models are most useful when you need to
show how state changes or where you need to describe a 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 Card PIN request PIN Option m enu <<exception>> invalid card Withdraw request Amount request Amount Debit (amount) <<exception>> insuf ficient cash Card Card rem oved Cash Cash rem oved Receipt Complete transaction Debit response Balance request Balance Handle request Validate card Database
Card number Card OK
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 than HOW 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 specific system.
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_s pecification_document_template.htm See next slides
SOFTWARE REQUIREMENTS SPECIFICATION TEMPLATE
To develop the software requirements specification, you must

understand the objects the system will manipulate (information domain), the services (functions) the system will perform, the constraints on the project (time, money and technical) and the performance expected (timing). As you develop the software requirements specification, you may need to re-interview the client. Do not hesitate to do so. Please E-mail with questions or come to my office hours if you need to. The software requirements specification focuses on what the system will do, not how the system will be implemented. It is produced as the culmination of the software requirements engineering phase in the process model. You must analyze the information domain, the function, performance, behavior and interface requirements of the system. Your document should follow the template below. It is a modified version of the Pressman's Adaptable Process Model template for a software requirements document.
2006 Lucent Technologies. All Rights Reserved. Lucent Technologies Proprietary Use pursuant to company instruction
1.0 Introduction
This section provides an overview of the entire requirement document. This document describes
all 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 are described without regards to implementation detail. Rank the major processing functionality from the developer's point of view. Use a simple ranking system such as: essential, desirable and future requirements. This should represent what you think your team can accomplish in the time frame of a semester. The essential requirements, you are sure you can complete. The desirable requirements 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 it takes to develop a SW product. 1.3 Software context The software is placed in a business or product line context. Strategic issues relevant to context are 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 to be specified, designed, implemented or tested are noted here.
2.0 Usage scenario

This section provides a usage scenario for the software. It organizes
information 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 are presented. 2.4 Activity Diagrams or Sequence Diagram The graphical representation of the workflow of all use-cases may be presented. (This section is optional.)
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

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) are described. 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 the software is presented.
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 in
this 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 a consequence of events is presented. 5.2 Statechart Diagram Depict the overall behavior of the system.
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 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

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Requirements Part1 Ch6

Hochgeladen von

Copyright:

Verfügbare Formate

Chapter 6 - Software Requirements

Software Engineering - Phases

2006 Lucent Technologies. All Rights Reserved.

Lucent Technologies Proprietary Use pursuant to company instruction

To describe functional and non-functional

To explain how software requirements may be

2006 Lucent Technologies. All Rights Reserved.

Lucent Technologies Proprietary Use pursuant to company instruction

2006 Lucent Technologies. All Rights Reserved.

Lucent Technologies Proprietary Use pursuant to company instruction

2006 Lucent Technologies. All Rights Reserved.

Lucent Technologies Proprietary Use pursuant to company instruction

Library System Example - User and System requirements

User requirement can be expended using multiple system requirements

User requirements are more abstract

2006 Lucent Technologies. All Rights Reserved.

Lucent Technologies Proprietary Use pursuant to company instruction

Functional and non-functional requirements

2006 Lucent Technologies. All Rights Reserved.

Lucent Technologies Proprietary Use pursuant to company instruction

2006 Lucent Technologies. All Rights Reserved.

Lucent Technologies Proprietary Use pursuant to company instruction

The LIBSYS system

Users can search for, download and print these articles

2006 Lucent Technologies. All Rights Reserved.

Lucent Technologies Proprietary Use pursuant to company instruction

Examples of functional requirements

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

The system shall provide appropriate viewers for the

Every order shall be allocated a unique identifier

2006 Lucent Technologies. All Rights Reserved.

Lucent Technologies Proprietary Use pursuant to company instruction

Requirements completeness and consistency

In principle, requirements should be both complete and

They should include descriptions of all facilities required.

Ambiguous requirements may be interpreted in different ways by

2006 Lucent Technologies. All Rights Reserved.

Lucent Technologies Proprietary Use pursuant to company instruction

Process requirements may also be specified mandating a

Non-functional requirements may be more critical than functional

2006 Lucent Technologies. All Rights Reserved.

Lucent Technologies Proprietary Use pursuant to company instruction

2006 Lucent Technologies. All Rights Reserved.

Lucent Technologies Proprietary Use pursuant to company instruction

Non-functional requirement types

Product re quir e me nts

Organisa ti onal re quir e me nts

E xt erna l re quir e me nts

E ffi ci ency re quir e me nts

Re liabili ty re quir e me nts

Porta bili ty re quir e me nts

Inte r ope r a bili ty re quir e me nts

E thic al re quir e me nts

Usa bili ty re quir e me nts

Del ive ry re quir e me nts

Imple menta ti on re quir e me nts

Standar ds re quir e me nts

L egislative re quir e me nts

Pe rformanc e re quir e me nts

Spa ce re quir e me nts

Pri va cy re quir e me nts

Safe ty re quir e me nts

2006 Lucent Technologies. All Rights Reserved.