© G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...
-
Upload
marvin-flynn -
Category
Documents
-
view
217 -
download
2
Transcript of © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...
![Page 1: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/1.jpg)
© G. Antoniol 1998 Requirement Analysis 1
Requirement Analysis
... what the customer requires from a software system ...
![Page 2: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/2.jpg)
© G. Antoniol 1998 Requirement Analysis 2
Contents
Provide a justification. Specify requirements desired properties. Discuss:
problems
solutions
![Page 3: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/3.jpg)
© G. Antoniol 1998 Requirement Analysis 3
Requirements
It is very difficult to formulate a complete and consistent requirements specification
A requirements definition, a requirements specification and a software specification are ways of specifying software for different types of reader
The requirements document is a description for customers and developers
![Page 4: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/4.jpg)
© G. Antoniol 1998 Requirement Analysis 4
Requirements Errors
Requirements errors are usually very expensive to correct after system delivery
Reviews involving client and contractor staff are used to validate the system requirements
Stable requirements are related to core activities of the customer for the software
Volatile requirements are dependent on the context of use of the system
![Page 5: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/5.jpg)
© G. Antoniol 1998 Requirement Analysis 5
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
![Page 6: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/6.jpg)
© G. Antoniol 1998 Requirement Analysis 6
IEEE a Requirement Definition
A condition of capability needed by the user to solve a problem or achieve an objective
A condition or capability that must be meet or possessed by a system ... to satisfy a contract, standard, specification, or other formally imposed document
![Page 7: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/7.jpg)
© G. Antoniol 1998 Requirement Analysis 7
Requirement Analysis
For large system is the most difficult and intractable activity
It is an error prone activity It is probably the software engineering weakest
and critical area Requirements analysis produce among others the
Software Requirements Specification (SRS)
![Page 8: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/8.jpg)
© G. Antoniol 1998 Requirement Analysis 8
Requirement Engineering
The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed
Requirements may be functional or non-functional • Functional requirements describe system services or functions
• Non-functional requirements is a constraint on the system or on the development process
![Page 9: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/9.jpg)
© G. Antoniol 1998 Requirement Analysis 9
Requirements analysis
Sometimes called requirements elicitation or requirements discovery
Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints
May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders
![Page 10: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/10.jpg)
© G. Antoniol 1998 Requirement Analysis 10
Why so Difficult?
A project is initiated by clients needs ! There is no formal document describing the
clients needs ! The document describing clients need is the result
of the analysis !
requirement analyst has to identify the
requirements by talking to people !
![Page 11: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/11.jpg)
© G. Antoniol 1998 Requirement Analysis 11
Large Systems
Most large software systems address difficult problems
Problems which are so complex that they can never be fully understood and where understanding develops during the system development
Therefore, requirements are normally both incomplete and inconsistent
![Page 12: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/12.jpg)
© G. Antoniol 1998 Requirement Analysis 12
Why Inconsistency ?
Large software systems must improve the current situation. It is hard to anticipate the effects that the new system will have on the organization
Different users have different requirements and priorities. There is a constantly shifting compromise in the requirements
System end-users and organizations who pay for the system have different requirements
Prototyping is often required to clarify requirements
![Page 13: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/13.jpg)
© G. Antoniol 1998 Requirement Analysis 13
Requirement Analysis Problems
Stakeholders don’t know what they really want Stakeholders express requirements in their own
terms Different stakeholders may have conflicting
requirements Organizational and political factors may influence
the system requirements The requirements change during the analysis
process. New stakeholders may emerge
![Page 14: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/14.jpg)
© G. Antoniol 1998 Requirement Analysis 14
Requirement Analysis Problems
Clients usually do not understand software or software development processes
Developers do not understand clients’ problem or application area
SRS is a medium through which users and clients needs are specified
A good SRS should satisfy ALL the PARTIES ... which is very hard to achieve ...
![Page 15: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/15.jpg)
© G. Antoniol 1998 Requirement Analysis 15
Activity
Requirements analysis aims to specify what some people have in their minds
The input to this activity is
incomplete
informal
imprecise
and may also inconsistent
![Page 16: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/16.jpg)
© G. Antoniol 1998 Requirement Analysis 16
Product
The output of the requirement analysis is a set of requirements, hopefully: complete unambiguous consistent
Requirements analysis produce the Software Requirements Specification (SRS)
![Page 17: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/17.jpg)
© G. Antoniol 1998 Requirement Analysis 17
SRS
The objective of SRS is to specify what is needed from the system not howthe system will provide it!
... unfortunately, how at one level my be what at lower level ...
SRS must give enough detail to allow developers to actually build andtest the system
![Page 18: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/18.jpg)
© G. Antoniol 1998 Requirement Analysis 18
SRS Properties
An SRS establishes the basis for agreement between the client and the supplier on what the software product will do.
An SRS provide reference for validation of final product.
A high-quality SRS is a prerequisite to high quality software.
A high-quality SRS reduce development costs.
![Page 19: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/19.jpg)
© G. Antoniol 1998 Requirement Analysis 19
Errors Cost
It had been discovered that in some project 54 % of the errors were detected afterunit testing and that 45 % of this errors were actually originated during earlystages i.e., 25 % of the error occurs during requirement and early design stages
Phase Cost(person-hours)
Requirements 2
Design 5
Coding 15
Acceptance Test 50
Operation/Maint. 150
![Page 20: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/20.jpg)
© G. Antoniol 1998 Requirement Analysis 20
Definition/Specification
Requirements definition• A statement in natural language plus diagrams of the services the
system provides and its operational constraints. Written for customers
Requirements specification• A structured document setting out detailed descriptions of the
system services. Written as a contract between client and contractor
Software specification• A detailed software description which can serve as a basis for a
design or implementation. Written for developers
![Page 21: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/21.jpg)
© G. Antoniol 1998 Requirement Analysis 21
Definition/Specification
Requirements definition• Customer-Oriented descriptions of the system’s functions and
constraints on its operation
Requirements specification• Precise and detailed descriptions of the system’s functionality and
constraints. Intended to communicate what is required to system developers and serve as the basis of a contract for the system development
![Page 22: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/22.jpg)
© G. Antoniol 1998 Requirement Analysis 22
Requirement Reader
RequirementsDefinition
Client managersSystem end-usersClient engineerContractor managersSystem architect
RequirementsSpecification
System end-usersClient engineersSystem architectSoftware developers
![Page 23: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/23.jpg)
© G. Antoniol 1998 Requirement Analysis 23
Definition
Definition
The software must provide a means of representing and accessing external files created by other tools.
![Page 24: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/24.jpg)
© G. Antoniol 1998 Requirement Analysis 24
Specification
Specification
1.1 The user should be provided with facility to define the type of external files.1.2 Each external files type may have an associated tool which may be applied to the file1.3 Each external files type may be represented as a specific icon on the user’s display.1.4 Facilities should be provided for the icon representing an external file type to be defined by the user1.5 When a user selects an icon representing an external file, the effect of that selection is to apply the tool associated with the external file type to the file represented by the selected icon.
![Page 25: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/25.jpg)
© G. Antoniol 1998 Requirement Analysis 25
Requirement Engineering Process
Feasibility study• Find out if the current user needs be satisfied given the available
technology and budget?
Requirements analysis• Find out what system stakeholders require from the system
Requirements definition• Define the requirements in a form understandable to the customer
Requirements specification• Define the requirements in detail
![Page 26: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/26.jpg)
© G. Antoniol 1998 Requirement Analysis 26
Requirement Process
Classification
RequirementCollection
DomainUnderstanding
RequirementValidation
ProcessEntry
Prioritization
ConflictResolution
Requirementsdefinition andspecification
![Page 27: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/27.jpg)
© G. Antoniol 1998 Requirement Analysis 27
Process Activities
Domain understanding Requirements collection Classification Conflict resolution Prioritization Requirements validation
![Page 28: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/28.jpg)
© G. Antoniol 1998 Requirement Analysis 28
Analysis Issues
Obtain the needed information ...
may be you are not really welcome ... after
all knowledge is power ...
Organize the obtained information ...
a huge amount of unstructured information
barely ever let you to check consistency ...
![Page 29: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/29.jpg)
© G. Antoniol 1998 Requirement Analysis 29
Analysis Issues
Resolving contradictions ...
you probably must mediate between
conflicting requirements or user needs or ... Focus on what and avoid to mix requirement and
design
![Page 30: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/30.jpg)
© G. Antoniol 1998 Requirement Analysis 30
Analysis Partition
Divide et impera: divide the problem into sub problems
Partition with respect to:
objects
functions
![Page 31: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/31.jpg)
© G. Antoniol 1998 Requirement Analysis 31
Objects/Functions
Objects: entities in the real world with clear, defined
boundaries and independent existence (sensors, bill, managers).
Functions: a task, service, process or activity that is
now performed in the real world and it has to be performed by the system.
![Page 32: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/32.jpg)
© G. Antoniol 1998 Requirement Analysis 32
Analysis Approaches
Informal:
a series of meetings between users/clients
and analysts serve to prepare SRS.
Structured:
function or object based decompositions are
used while modeling the problem.
![Page 33: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/33.jpg)
© G. Antoniol 1998 Requirement Analysis 33
Requirement Specification
DFD, OO models, use cases focus on problem structure
User interface are not modeled Error situation, log messages are not modeled Performance, design and recovery constraints are
not specified
![Page 34: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/34.jpg)
© G. Antoniol 1998 Requirement Analysis 34
Methodology
Data Flow Diagram (DFD)
Object Oriented Modeling (OO)
Use cases
There are many other methodology e.g., Entity-Relationship (ER)or Structured Analysis and Design Technique (SADT)
![Page 35: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/35.jpg)
© G. Antoniol 1998 Requirement Analysis 35
DFD
DFD is a graph showing how data flow through the system.
A data from an input undergoes, possibly, many transformations before reaching an output.
DFDs capture, represent data transformations. DFD constituents:
data, processes, input sources, output sinks
and arrows to represent the flow
![Page 36: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/36.jpg)
© G. Antoniol 1998 Requirement Analysis 36
DFD Notation
Process
Sink or source
External files
And operator
Or operator
Notice each edge must have a label !!!!
MyFile
*
+
Worker
PayInvoice
A transformer, an activity
An external entity
A repository
A A data item or a collectionof data item, arrow representsflow direction
![Page 37: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/37.jpg)
© G. Antoniol 1998 Requirement Analysis 37
Teller Machine
Customer
GetAccount
Customers Accounts
PIN
Balance
Positive Balance
Withdrawalamount
*
Check
Amount
Amountdue
Update
Account
New balance
Receipt
Amount
IssueMoney
Money
![Page 38: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/38.jpg)
© G. Antoniol 1998 Requirement Analysis 38
DFD Drawing Strategy
Identify major inputs and outputs (ignore errors first!)
Start from input and work towards output identifying major transformations
Or viceversa start from output and ... Start from high level DFD with few
transformation and go into more detailed DFD Try more than one DFD before settling one
![Page 39: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/39.jpg)
© G. Antoniol 1998 Requirement Analysis 39
Data Dictionary
It is the repository of various data flows Notation is similar to regular expressions:
+ sequence or composition
| selection, or
* one or more occurrences
![Page 40: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/40.jpg)
© G. Antoniol 1998 Requirement Analysis 40
Data Dictionary Example
Balance = user name + user account + user id + current balance
Withdrawal amount = [50000|100000|150000|200000|250000]+user id
New balance = user name + user account + user id + [current balance]*
PIN = digit + digit + digit + digit + digit
![Page 41: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/41.jpg)
© G. Antoniol 1998 Requirement Analysis 41
DFD Common Errors
Unlabeled data flow Missing data flow: information required by a
process is not available Extraneous data flow: some information is not
being used in the process Consistency not maintained during refinement Missing processes Contain some control information
![Page 42: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/42.jpg)
© G. Antoniol 1998 Requirement Analysis 42
DFD Structured Methodology
Each system is characterized as a transformation function operating with the environment transforming environment inputs into environment output.
Track the flow of data through the system
![Page 43: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/43.jpg)
© G. Antoniol 1998 Requirement Analysis 43
Methodology Steps
Study the “physical environment”, draw a DFD of the current (may be partially automated) system
Draw the logical equivalents of the DFD for the physical system i.e., change John_office_pay into issue_check
Draw a logical model and DFD for the new system with no separation between processes automated and not
Establish a man machine boundary i.e., specify what will be automated
![Page 44: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/44.jpg)
© G. Antoniol 1998 Requirement Analysis 44
Requirements Document
The requirements document is the official statement of what is required of the system developers
Should include both a definition and a specification of 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
![Page 45: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/45.jpg)
© G. Antoniol 1998 Requirement Analysis 45
Requirements Rationale
It is important to provide rationale with requirements
This helps the developer understand the application domain and why the requirement is stated in its current form
Particularly important when requirements have to be changed. The availability of rationale reduces the chances that change will have unexpected effects
![Page 46: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/46.jpg)
© G. Antoniol 1998 Requirement Analysis 46
Requirement Traceability
Requirements traceability means that related requirements are linked in some way and that requirements are (perhaps) linked to their source
Traceability is a property of a requirements specification which reflects the ease of finding related requirements
Notice that we must be able to trace requirements into design elements, into code, into test cases ...
![Page 47: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/47.jpg)
© G. Antoniol 1998 Requirement Analysis 47
Traceability Type
Requirements-sources traceability: links the requirement and the people, documents which specified the requirement (e.g., customer, incident report, quality standard, international regulations)
Requirements-rationale traceability: why the requirement has been specified
Requirements-requirements traceability: links a requirement with other requirements, which are in some way dependent on them.
![Page 48: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/48.jpg)
© G. Antoniol 1998 Requirement Analysis 48
Traceability Type Continue
Requirements-architecture traceability: links requirements with sub-systems where these requirements are implemented i.e., who is going to develop what.
Requirements-design traceability: links requirements with specific components in the system which are used to implement them
Requirements-interface traceability: links requirements with interfaces of external systems which are used in the provision of the requirements.
![Page 49: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/49.jpg)
© G. Antoniol 1998 Requirement Analysis 49
Traceability Technique
Assign a unique number to all requirements Cross-reference related requirements using this
unique number Produce a cross-reference matrix for each
requirements document showing related requirements. Several matrices may be necessary for different types of relationship
![Page 50: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/50.jpg)
© G. Antoniol 1998 Requirement Analysis 50
Requirements Document Requirements
Specify external system behavior 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 Characterize responses to unexpected events
![Page 51: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/51.jpg)
© G. Antoniol 1998 Requirement Analysis 51
Writing Requirements
Natural language, supplemented by diagrams and tables is the normal way of writing requirements definitions
This is universally understandable but three types of problem can arise• 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 amalgamation. Several different requirements may
be expressed together
![Page 52: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/52.jpg)
© G. Antoniol 1998 Requirement Analysis 52
SRS Components
Functionality Performance Design constraints External Interface
![Page 53: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/53.jpg)
© G. Antoniol 1998 Requirement Analysis 53
Requirement Document
Introduction Glossary System Models Functional Requirements Definition Non Functional Requirements System Evolution Requirements Specification
Sommerville
![Page 54: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/54.jpg)
© G. Antoniol 1998 Requirement Analysis 54
Requirements Document Structure
Introduction• Describe need for the system and how it fits with business
objectives
Glossary• Define technical terms used
System models• Define models showing system components and relationships
Functional requirements definition• Describe the services to be provided
Sommerville
![Page 55: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/55.jpg)
© G. Antoniol 1998 Requirement Analysis 55
Requirements Document Structure
Non-functional requirements definition• Define constraints on the system and the development process
System evolution• Define fundamental assumptions on which the system is based and
anticipated changes
Requirements specification• Detailed specification of functional requirements
Appendices• System hardware platform description• Database requirements (as an ER model perhaps)
IndexSommerville
![Page 56: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/56.jpg)
© G. Antoniol 1998 Requirement Analysis 56
IEEE/ANSI 830-1993
1 Introduction 2 General Description 3 Specific Requirements 4 Appendices Index
IEEE/ANSI 830-1993
![Page 57: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/57.jpg)
© G. Antoniol 1998 Requirement Analysis 57
IEEE/ANSI - Introduction
1 Introduction
1.1 Purpose of the requirement document
1.2 Scope of the product
1.3 Definitions, acronyms, abbreviations
1.4 References
1.5 Overview of the remainder of the
document IEEE/ANSI 830-1993
![Page 58: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/58.jpg)
© G. Antoniol 1998 Requirement Analysis 58
IEEE/ANSI - General Description
2 General Description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependenciesIEEE/ANSI 830-1993
![Page 59: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/59.jpg)
© G. Antoniol 1998 Requirement Analysis 59
Section 2 Note
2.1Perspective relationship of the product to other products,
whether or not it is part of a larger system, principal product interfaces with the external world
2.2 Product functions a general abstract description of performed
functions 2.3 User characteristics
typical characteristics of the eventual end user
![Page 60: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/60.jpg)
© G. Antoniol 1998 Requirement Analysis 60
IEEE/ANSI - Specific Requirements
3 Specific requirements
3.X Functional Requirements
3.Y Non functional requirements
3.Z Interface requirements
» External interface, logical database requirements,
hardware interface, user interface, etc.
![Page 61: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/61.jpg)
© G. Antoniol 1998 Requirement Analysis 61
Key Question
How should be actually organized Section 3 ?
Is there a way that simplify
writing/reading the document ?
Section 3 is the central part of the document
![Page 62: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/62.jpg)
© G. Antoniol 1998 Requirement Analysis 62
An Organization
External interfaces
Functional requirements
Performance Requirements
Design constraints
System Attributes
![Page 63: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/63.jpg)
© G. Antoniol 1998 Requirement Analysis 63
Specific Requirement Organization
3.1 External Interface Requirements
3.1.1 User Interface
3.1.2 Hardware Interface
3.1.3 Software Interface
3.1.4 Communication Interface
![Page 64: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/64.jpg)
© G. Antoniol 1998 Requirement Analysis 64
Specific Requirement Organization
3.2 Functional Requirements 3.2.1 Mode 1
» 3.2.1.1 Functional Requirement 1.1» .....» 3.2.1.n Functional Requirement 1.n
3.2.m Mode m» 3.2.m.1 Functional Requirement m.1» .....» 3.2.m.n Functional Requirement m.p
![Page 65: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/65.jpg)
© G. Antoniol 1998 Requirement Analysis 65
Functional Requirements - Note
For each Functional Requirement specify: required inputs
» sources, unit of measures, valid ranges, accuracy, etc.
desired outputs» destination of outputs, units of measure, range of
valid outputs, error messages, etc processing requirements
» validity checks on inputs, sequence of operations, response to abnormal situations, etc.
![Page 66: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/66.jpg)
© G. Antoniol 1998 Requirement Analysis 66
Functional Requirements - Note
You must also specify:
acceptance criteria» otherwise, how can we demonstrate that the
requirement has been satisfied
This a key point: during acceptance test the user will judge your product based on acceptance criteria. During system and integration test to assess requirement coverage you must be able to measure requirements satisfaction. You must justify the absence of the acceptance criteria
![Page 67: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/67.jpg)
© G. Antoniol 1998 Requirement Analysis 67
Functional Requirements - Note
You must also specify:
the list of related requirements and related
expectations
» this also helps in managing requirement changes
a list of keywords
» this also helps in managing requirement changes
a status bar ...
![Page 68: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/68.jpg)
© G. Antoniol 1998 Requirement Analysis 68
Status Bar
priority Required/Optional/Deleted
status Obsolete/Suspended/Draft/Final
stability Stable/Unstable/Unknown
Understanding level Understood/Obscure/Unclear
![Page 69: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/69.jpg)
© G. Antoniol 1998 Requirement Analysis 69
Remaining of Section 3
3.3 Performance requirements 3.4 Design constraints 3.5 Attributes 3.6 Other requirements
![Page 70: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/70.jpg)
© G. Antoniol 1998 Requirement Analysis 70
IEEE/ANSI - Appendices
4 Appendices
Conventions, form compilation rules
![Page 71: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/71.jpg)
© G. Antoniol 1998 Requirement Analysis 71
Non Functional Requirements
Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless.
• Product requirements• Process requirements• Organizational requirements• External requirements
![Page 72: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/72.jpg)
© G. Antoniol 1998 Requirement Analysis 72
Non Functional Requirements
Define system properties and constraints
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.
![Page 73: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/73.jpg)
© G. Antoniol 1998 Requirement Analysis 73
Non Functional Classification
Product requirements• Requirements which specify that the delivered product must
behave in a particular way e.g. execution speed, reliability, etc.
Organizational requirements• Requirements which are a consequence of organizational 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.
![Page 74: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/74.jpg)
© G. Antoniol 1998 Requirement Analysis 74
Non Functional Requirements
Performancerequirements
Spacerequirements
Usabilityrequirements
Ef ficiencyrequirements
Reliabilityrequirements
Portabilityrequirements
Interoperabilityrequirements
Ethicalrequirements
Legislativerequirements
Implementationrequirements
Standardsrequirements
Deliveryrequirements
Safetyrequirements
Privacyrequirements
Productrequirements
Organizationalrequirements
Externalrequirements
Non-functionalrequirements
![Page 75: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/75.jpg)
© G. Antoniol 1998 Requirement Analysis 75
Example
Product requirement• all necessary communication between processes and the user must
be bases on the Extended Bytecodes character set.
Organizational requirement• deliverable documents shall conform to the process and
deliverables defined in ISO 9001 standard
External requirement• The system must be capable to connect with the EU exchange
information network by mean of a dedicated circuit.
![Page 76: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/76.jpg)
© G. Antoniol 1998 Requirement Analysis 76
Verifiability
Requirements should be written so that they can be objectively verified
The problem with this requirement is its use of vague terms such as ‘errors shall be minimized”
e.g. The error rate should be been quantified» Experienced waiters should be able to use all the system
functions after a total of four hours training. After this training, the average number of errors made by experienced users should not exceed five per day.
![Page 77: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/77.jpg)
© G. Antoniol 1998 Requirement Analysis 77
MeasuresProperty MeasureSpeed Processed transactions/second
User/Event response timeScreen refresh time
Size K BytesNumber of RAM chips
Ease of use Training timeNumber of help frames
Reliability Mean time to failureProbability of unavailabilityRate of failure occurrenceAvailability
Robustness Time to restart after failurePercentage of events causing failureProbability of data corruption on failure
Portability Percentage of target dependent statementsNumber of target systems
![Page 78: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/78.jpg)
© G. Antoniol 1998 Requirement Analysis 78
Measures
Property Measure
Speed Processed transactions per secUser/event rensponse timeScreen refresh time
Size Executable KbyteProcess size/Required memoryNumber of RAM chips
Ease of use Training timeNumber of help screens/frames
Reliability Mean time to failureProbability of unavailabilityRate of failure occurrenceAvailability
Robustness Time to restart after failurePercentage of event causing failureProbability of data corruption onfailure
Portability Number of target systemPercentage of target dependentstatement
![Page 79: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/79.jpg)
© G. Antoniol 1998 Requirement Analysis 79
Requirements Separation
Functional and non-functional requirements should, in principle, be distinguished
However, this is difficult as requirements may be expressed as whole system requirements rather than constraints on individual functions
It is sometimes difficult to decide if a requirement is functional or a non-functional• e.g., requirements for safety are concerned with non-functional
properties but may require functions to be added to the system
![Page 80: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/80.jpg)
© G. Antoniol 1998 Requirement Analysis 80
System Requirements
Some requirements place constraints on the system as a whole rather than specific system functions
Example the time required for training a system operator to be proficient in the use of the system must not exceed 2 working days.
These may be requirements which cannot be derived from any single sub-set of the already stated requirements; a change in system requirements may be extremely expensive.
![Page 81: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/81.jpg)
© G. Antoniol 1998 Requirement Analysis 81
Requirements Evolution
May be user needs changed a large system to be developed requires years and the organization's objectives/needs change
Requirements always evolve as a better understanding of user needs is developed or incorrect interpretation are clarified
It is essential to plan for change in the requirements as the system is being developed and used
![Page 82: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/82.jpg)
© G. Antoniol 1998 Requirement Analysis 82
Requirements Evolution
Client
Needs
Initial understandingof the problem
Initialrequirements
Changed understandingof the problem
Revisedrequirements
![Page 83: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/83.jpg)
© G. Antoniol 1998 Requirement Analysis 83
Requirement Classes
Stable requirements derived from the core activity of the customer organization. E.g. a hospital will always have doctors, nurses, etc. May be derived from domain models
Volatile requirements. Requirements which change during development or when the system is in use. In a hospital, requirements derived from health-care policy
![Page 84: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/84.jpg)
© G. Antoniol 1998 Requirement Analysis 84
A Classification
Mutable requirements• Requirements that change due to the system’s environment
Emergent requirements• Requirements that emerge as understanding of the system
develops
Consequential requirements• Requirements that result from the introduction of the computer
system
Compatibility requirements• Requirements that depend on other systems or organizational
processes
![Page 85: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/85.jpg)
© G. Antoniol 1998 Requirement Analysis 85
Requirements Changes
The requirements document should be organized so that requirements changes can be made without extensive rewriting
External references should be minimized and the document sections should be as modular as possible
Changes are easiest when the document is electronic. Lack of standards for electronic documents make this difficult
![Page 86: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/86.jpg)
© G. Antoniol 1998 Requirement Analysis 86
SRS characteristics
SRS should be correct complete unambiguous verifiable consistent ranked for importance or stability modifiable traceable
![Page 87: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/87.jpg)
© G. Antoniol 1998 Requirement Analysis 87
Correct Complete ...
Correct: every requirement represent something required in the final system
Complete: if everything it is supposed the system to do and the responses of the software to all classes of input data are specified in SRS.
Unambiguous: every requirement has exactly only one interpretation
Verifiable: if for each requirement there exist a cost effective process that can check whether or not the final software meets that requirement
![Page 88: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/88.jpg)
© G. Antoniol 1998 Requirement Analysis 88
Consistent ...
Consistent: if there is no requirement that conflicts with another.
Ranked: some requirement are considered more critical than others.
Modifiable:if changes to a requirement can be made easily preserving completeness and consistency.
Traceable:if the origin of the requirement is clear and can be traced to design and code.
![Page 89: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/89.jpg)
© G. Antoniol 1998 Requirement Analysis 89
Requirements Validation
Concerned with demonstrating that the requirements define the system that the customer really wants
Requirements error costs are high so validation is very important• Fixing a requirements error after delivery may cost up to 100
times the cost of fixing an implementation error
Prototyping is an important technique of requirements validation
![Page 90: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/90.jpg)
© G. Antoniol 1998 Requirement Analysis 90
Requirements Verification
Validity. Does the system provide the functions which best support the customer’s needs?
Consistency. Are there any requirements conflicts?
Completeness. Are all functions required by the customer included?
Realism. Can the requirements be implemented given available budget and technology
![Page 91: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/91.jpg)
© G. Antoniol 1998 Requirement Analysis 91
Requirements Reviews
Regular reviews should be held while the requirements definition is being formulated
Both client and contractor staff should be involved in reviews
Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage
![Page 92: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/92.jpg)
© G. Antoniol 1998 Requirement Analysis 92
Requirements Inspections
A group of people with different skills and responsibilities (4-5): an end-user a customer representative one or more domain experts one or more responsible for system design
and implementation one or more requirements engineers
![Page 93: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/93.jpg)
© G. Antoniol 1998 Requirement Analysis 93
Organization
Requirements are assigned to people one or more week in advance (up to 100 requirements)
People analyze/inspect requirements (up to 40 requirements per hour)
During formal meeting requirement are discussed validated and decisions/discussions/clarifications are recorded (Meeting up to 4 hours)
Checklist are exploited during meeting.
![Page 94: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/94.jpg)
© G. Antoniol 1998 Requirement Analysis 94
Reviews Check
Verifiability. Is the requirement realistically testable?
Comprehensibility. Is the requirement properly understood?
Traceability. Is the origin of the requirement clearly stated?
Adaptability. Can the requirement be changed without a large impact on other requirements?
![Page 95: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/95.jpg)
© G. Antoniol 1998 Requirement Analysis 95
Actions
Requirements clarification: badly expressed requirement or omitted information; requirement author’s rewrite the text.
Missing information: information is missing from the requirement document; requirement engineer is responsible to gather extra information.
Requirements conflict: a negotiate with the customer will remove the conflict.
Unrealistic requirement: the customer should be consulted, requirements deleted, modified i.e., make more realistic
![Page 96: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/96.jpg)
© G. Antoniol 1998 Requirement Analysis 96
Checklist
It should be expressed in a fairly general way
It should be understandable by end users
It should not have more than 10 items
![Page 97: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/97.jpg)
© G. Antoniol 1998 Requirement Analysis 97
Checklist Example
Are the requirements complete i.e., does the checker know of any missing requirements or any information missing from individual requirement descriptions?
Are the requirement consistent i.e., do the descriptions of different requirements include contradictions?
Are the requirements comprehensible i.e., can readers of the document understand what the requirement means?
Are the requirement ambiguous i.e., are there possible different interpretations of the requirements?
![Page 98: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/98.jpg)
© G. Antoniol 1998 Requirement Analysis 98
Checklist Example - Continue
Is the requirement document structured i.e., would an alternative structure be easier to understand? Are related requirements grouped?
Are requirements traceable i.e., are requirements unambiguously identified, do they include links to related requirements and to the reason why these requirements have been included?
Does the document in the whole and do individual requirement conform to defined standard?
![Page 99: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/99.jpg)
© G. Antoniol 1998 Requirement Analysis 99
Checklist Example - 1
Are all hardware resources defined? Have the response time of functions been specified? Have all the hardware, external software and data interface
been specified? Have all functions required by the client been specified? Is each requirement testable? Are all the responses to exceptional condition specified? Is the initial state of the system defined? Are possible future modification specified?
![Page 100: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/100.jpg)
© G. Antoniol 1998 Requirement Analysis 100
Collect Measures
Number of detected errors: omission: a user requirement was not included inconsistency: contradictions among
requirements, incompatibility with the actual customer requirements, incompatibility with the environment
incorrect fact: erroneous assumptions or incorrect requirement
ambiguity: multiple meanings
![Page 101: © G. Antoniol 1998Requirement Analysis1... what the customer requires from a software system...](https://reader036.fdocuments.in/reader036/viewer/2022062517/56649ef65503460f94c0a2d1/html5/thumbnails/101.jpg)
© G. Antoniol 1998 Requirement Analysis 101
Quality Indicator
If during reviews were interpreted in the same manner and are the total number of requirements:
Qn
nuur
r
nur
nr