Requirements Part1 Ch6
-
Upload
ashish-jamuda -
Category
Documents
-
view
219 -
download
0
Transcript of 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
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 2/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 3/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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.
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 4/46
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 5/46 © 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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.
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 6/46 © 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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
8/3/2019 Requirements Part1 Ch6
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.
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 8/46 © 2006 Lucent Technologies. All Rights Reserved.
Lucent Technologies – ProprietaryUse pursuant to company instruction
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.
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 9/46 © 2006 Lucent Technologies. All Rights Reserved.
Lucent Technologies – ProprietaryUse pursuant to company instruction
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.
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 10/46
© 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 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.
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 11/46
© 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
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.
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 12/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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.
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 13/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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.
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 14/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 15/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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.
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 16/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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?
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 17/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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.
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 18/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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.
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 19/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
Requirement Types / Classification 2
User Requirements
System Requirements
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 20/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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.
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 21/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 22/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 23/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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.
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 24/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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).
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 25/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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.
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 26/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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.
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 27/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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.
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 28/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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.
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 29/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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.
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 30/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 31/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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.
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 32/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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.
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 33/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 34/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 35/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
Users of a requirements document
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 36/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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.
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 37/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
Requirements document structure
Preface
Introduction Glossary
User requirements definition
System architecture
System requirements specification
System models
System evolution
Appendices
Index
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 38/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 39/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 40/46
© 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 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
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 41/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 42/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 43/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 44/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 45/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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
8/3/2019 Requirements Part1 Ch6
http://slidepdf.com/reader/full/requirements-part1-ch6 46/46
© 2006 Lucent Technologies. All Rights Reserved.Lucent Technologies – Proprietary
Use pursuant to company instruction
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.