Requirement Analysis
-
Upload
lewis-mcfarland -
Category
Documents
-
view
19 -
download
3
description
Transcript of Requirement Analysis
© G. Antoniol 1998 Requirement Analysis 1
Requirement Analysis
... what the customer requires from a software system ...
© G. Antoniol 1998 Requirement Analysis 2
Contents
Provide a justification. Specify requirements desired properties. Discuss:
problems
solutions
© 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
© 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
© 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
© 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
© 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)
© 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
© 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
© 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 !
© 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
© 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
© 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
© 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 ...
© 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
© 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)
© 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
© 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.
© 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
© 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
© 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
© G. Antoniol 1998 Requirement Analysis 22
Requirement Reader
RequirementsDefinition
Client managersSystem end-usersClient engineerContractor managersSystem architect
RequirementsSpecification
System end-usersClient engineersSystem architectSoftware developers
© G. Antoniol 1998 Requirement Analysis 23
Definition
Definition
The software must provide a means of representing and accessing external files created by other tools.
© 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.
© 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
© G. Antoniol 1998 Requirement Analysis 26
Requirement Process
Classification
RequirementCollection
DomainUnderstanding
RequirementValidation
ProcessEntry
Prioritization
ConflictResolution
Requirementsdefinition andspecification
© G. Antoniol 1998 Requirement Analysis 27
Process Activities
Domain understanding Requirements collection Classification Conflict resolution Prioritization Requirements validation
© 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 ...
© 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
© G. Antoniol 1998 Requirement Analysis 30
Analysis Partition
Divide et impera: divide the problem into sub problems
Partition with respect to:
objects
functions
© 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.
© 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.
© 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
© 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)
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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 ...
© 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.
© 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.
© 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
© 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
© 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
© G. Antoniol 1998 Requirement Analysis 52
SRS Components
Functionality Performance Design constraints External Interface
© G. Antoniol 1998 Requirement Analysis 53
Requirement Document
Introduction Glossary System Models Functional Requirements Definition Non Functional Requirements System Evolution Requirements Specification
Sommerville
© 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
© 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
© 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
© 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
© 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
© 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
© 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.
© 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
© G. Antoniol 1998 Requirement Analysis 62
An Organization
External interfaces
Functional requirements
Performance Requirements
Design constraints
System Attributes
© 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
© 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
© 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.
© 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
© 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 ...
© 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
© 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
© G. Antoniol 1998 Requirement Analysis 70
IEEE/ANSI - Appendices
4 Appendices
Conventions, form compilation rules
© 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
© 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.
© 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.
© 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
© 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.
© 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.
© 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
© 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
© 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
© 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.
© 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
© G. Antoniol 1998 Requirement Analysis 82
Requirements Evolution
Client
Needs
Initial understandingof the problem
Initialrequirements
Changed understandingof the problem
Revisedrequirements
© 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
© 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
© 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
© G. Antoniol 1998 Requirement Analysis 86
SRS characteristics
SRS should be correct complete unambiguous verifiable consistent ranked for importance or stability modifiable traceable
© 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
© 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.
© 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
© 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
© 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
© 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
© 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.
© 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?
© 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
© 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
© 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?
© 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?
© 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?
© 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
© 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