Professional Documents
Culture Documents
Requirement s
Feasibility Syst em requi rement s
specificat io n
studies specificat io n an d
mo deling
Requirements Syst em
validation requi rement s
elicit at ion
User
Feasibilit y
st udy
requi rement s
elicit at ion
Requirements Prot ot ypi ng
management
Requirement s
elicit at ion
Reviews Requirement s
validat ion
Stakeholders
Any person or group who will be affected by the
system, directly or indirectly
End-users
Managers
Engineers involved in development or maintenance
Domain experts
Trade union reps
Requirements Elicitation and Analysis
11
Process (1)
Requirements
discovery
Requirements Requirement s
classificat ion and
Requirement s
priorit izat io n and
classification organi sat ion nego ti at ion
and
organisation
Requirements
prioritisation Requirement s Requirement s
negotiation
Requirements
documentation
Requirements Elicitation and Analysis
Process (2)
12
Requirements Discovery
The process of interacting with stakeholders in the
system to collect their requirements.
Domain requirements from stakeholders and
documentation are also discovered during this activity
Requirements Classification and organisation
Thisactivity takes the unstructured collection of
requirements, groups related requirements and
organises them into coherent clusters
Requirements Elicitation and Analysis
Process (3)
13
Problems of scope
boundary of system is ill-defined
unnecessary design information may be given
Problems of articulation
users are aware of their needs but are unable to articulate them or afraid to articulate it
users may not be aware of their needs
Communication barriers
user and analyst speak different languages
limitations of the communication language
Cognitive limitations
analysts have poor knowledge of problem domain
users have poor understanding of computer capabilities and limitations
Technical issues
requirements evolve over time
rapid software & hardware technology changes
Techniques for Requirements Elicitation
17
and Analysis (1)
Viewpoints
A way of structuring the requirements to represent the perspectives of
different stakeholders
Interactor viewpoints
People or other systems that interact directly with the system
Indirect viewpoints
Stakeholders who do not use the system themselves but who influence the
requirements
Domain viewpoints
Domain characteristics and constraints that influence the requirements
Interviewing
The RE team puts questions to stakeholders about the system that they
use and the system to be developed
Closed interviews
A pre-defined set of questions are answered
Open interviews
No pre-defined agenda and a range of issues are explored with
stakeholders
Techniques for requirements elicitation
18
and analysis (2)
Scenarios
Real-life examples of how a system can be used
A description of the starting situation
A description of the normal flow of events
A description of what can go wrong
Information about other concurrent activities
A description of the state when the scenario finishes
Use-cases
Scenario-based technique in the UML which identify the actors in
an interaction and which describe the interaction itself
Ethnography
Observation of the day-to-day work and notes made of the
actual task in which participants are involved
Viewpoint-Oriented Analysis
19
All VPs
Services
Query balance
Withdraw cash Customer Bank staff
All VPs
System
Students Staff Extern al Cataloguers
managers
Viewpoints in LIBSYS
Software Requirements Validation
30
Reviews
Systematic manual analysis of the requirements
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?
Prototyping
Using an executable model of the system to check requirements
Test-case generation
Developing tests for requirements to check testability
Requirements Management
32
which derive from the core activity of the organisation and which
relate directly to the domain of the system.
Volatile requirements - These are requirements which are likely to
change during the system development or after the system has been
put into operation.
Mutable Requirements - Requirements which change because of
changes to the environment in which the organisation is operating.
Emergent - Requirements which emerge as the customer’s
understanding of the system develops.
Consequential- Requirements which result from the introduction of the
computer system.
Compatibility- Requirements which depend on the particular systems
or business processes within an organisation.
Requirements Management Planning
34