Unit 2
Requirement Elicitation & Analysis
Contents
Requirements elicitation & Analysis
Requirements validation
Requirements management.
Elicitation and 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.
Problems of requirements analysis
Stakeholders don’t know what they really want.
Stakeholders express requirements in their own terms.
Different stakeholders may have conflicting requirements.
Organisational and political factors may influence the system
requirements.
The requirements change during the analysis process. New
stakeholders may emerge and the business environment change.
The requirements spiral
Process activities
Requirements discovery
Interacting with stakeholders to discover their requirements.
Domain requirements are also discovered at this stage.
Requirements classification and organisation
Groups related requirements and organises them into coherent
clusters.
Prioritisation and negotiation
Prioritising requirements and resolving requirements conflicts.
Requirements documentation
Requirements are documented and input into the next round of
Requirements discovery
The process of gathering information about the proposed and
existing systems and distilling the user and system requirements
from this information.
Sources of information include documentation, system stakeholders
and the specifications of similar systems.
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.
Requirements checking
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
Verifiability
Can the requirements be checked?
Requirements validation techniques
Requirements reviews
Systematic manual analysis of the requirements.
Prototyping
Using an executable model of the system to check requirements.
Test-case generation
Developing tests for requirements to check testability.
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.
Review checks
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?
Requirements management
Requirements management is the process of managing changing
requirements during the requirements engineering process and
system development.
Requirements are inevitably incomplete and inconsistent
New requirements emerge during the process as business needs
change and a better understanding of the system is developed;
Different viewpoints have different requirements and these are
often contradictory.
Requirements change
The priority of requirements from different viewpoints changes
during the development process.
System customers may specify requirements from a business
perspective that conflict with end-user requirements.
The business and technical environment of the system changes
during its development.
Requirements evolution
Enduring and volatile requirements
Enduring requirements
Stable requirements derived from the core activity of the customer
organisation. 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
Requirements classification
Requirements management
planning
During the requirements engineering process, you have to plan:
Requirements identification
How requirements are individually identified;
A change management process
The process followed when analysing a requirements change;
Traceability policies
The amount of information about requirements relationships
that is maintained;
CASE tool support
The tool support required to help manage requirements change;
Traceability
Traceability is concerned with the relationships between
requirements, their sources and the system design
Source traceability
Links from requirements to stakeholders who proposed these
requirements;
Requirements traceability
Links between dependent requirements;
Design traceability
Links from the requirements to the design;
A traceability matrix
Requirements change management
Should apply to all proposed changes to the requirements.
Principal stages
Problem analysis:- Discuss requirements problem and propose
change;
Change analysis and costing:- Assess effects of change on other
requirements;
Change implementation:- Modify requirements document and
other documents to reflect change.
Change management