Requirements Engineering Process

Book Referred: Ian Sommerville 8th Edition Chapter 7

Objectives
 To describe the principal requirements engineering activities and their
relationships
 To introduce techniques for requirements elicitation and analysis
 To describe requirements validation and the role of requirements
reviews
 To discuss the role of requirements management in support of other
requirements engineering processes
Topics covered
 Feasibility studies
 Requirements elicitation and analysis
 Requirements validation
 Requirements management
Requirements Engineering Processes
 The processes used for RE vary widely depending on the application
domain, the people involved and the organisation developing the
requirements.
 However, there are a number of generic activities common to all
processes
 Feasibility study (assessing whether the system is useful to the business)
 Requirement elicitation and analysis (discovering requirements)
 Requirement specification (converting these requirements into some
standard form)
 Requirement validation (checking that the requirements actually define the
system that the customer wants)
The Requirements Engineering Process
Spiral Model of Requirements Engineering
1. Feasibility Study
 A feasibility study decides whether or not the proposed system is
worthwhile.
 A short focused study that checks
 If the system contributes to organisational objectives;
 If the system can be engineered using current technology and within budget;
 If the system can be integrated with other systems that are used.
Feasibility Study Implementation
 Based on information assessment (what is required),
information collection and report writing.
 Questions for people in the organisation
 What if the system wasn’t implemented?
 What are current process problems?
 How will the proposed system help?
 What will be the integration problems?
 Is new technology needed? What skills?
 What facilities must be supported by the proposed system?
2. Requirement 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.
 The requirements change during the analysis process. New
stakeholders may emerge and the business environment
changes.
Requirement Elicitation and Analysis Process
 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
the spiral.
The requirements Elicitation and Analysis Process
2.1 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.
ATM Stakeholders
 Bank customers
 Representatives of other banks
 Bank managers
 Counter staff
 Database administrators
 Security managers
 Marketing department
 Hardware and software maintenance engineers
 Banking regulators
Viewpoints
 Viewpoints are a way of structuring the requirements to represent the
perspectives of different stakeholders. Stakeholders may be classified
under different viewpoints.
 This multi-perspective analysis is important as there is no single correct
way to analyse system requirements.
Types of Viewpoint
 Interactor viewpoints
 People or other systems that interact directly with the system. In an
ATM, the customer is an interactor VP.
 Indirect viewpoints
 Stakeholders who do not use the system themselves but who
influence the requirements. In an ATM, management and security
staff are indirect viewpoints.
 Domain viewpoints
 Domain characteristics and constraints that influence the
requirements. In an ATM, an example would be standards for inter-
bank communications.
Viewpoint Identification
 Identify viewpoints using
 Providers and receivers of system services.
 Systems that interact directly with the system being specified.
 Regulations and standards.
 Sources of business and non-functional requirements.
 Engineers who have to develop and maintain the system.
 Marketing and other business viewpoints.
LIBSYS Viewpoint Hierarchy
Interviewing
 In formal or informal interviewing, the RE team puts questions to
stakeholders about the system that they use and the system to be
developed.
 There are two types of interview
 Closed interviews where a pre-defined set of questions are answered.
 Open interviews where there is no pre-defined agenda and a range of issues
are explored with stakeholders.
Interviews in practice
 Normally a mix of closed and open-ended interviewing.
 Interviews are good for getting an overall understanding of
what stakeholders do and how they might interact with the
system.
 Interviews are not good for understanding domain
requirements
 Requirements engineers cannot understand specific domain
terminology;
 Some domain knowledge is so familiar that people find it hard to
articulate or think that it isn’t worth articulating.
Effective interviewers
 Interviewers should be open-minded, willing to listen to stakeholders
and should not have pre-conceived ideas about the requirements.
 They should prompt the interviewee with a question or a proposal and
should not simply expect them to respond to a question such as ‘what
do you want’.
Scenarios
 Scenarios are real-life examples of how a system can be used.
 They should include
 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.
LIBSYS scenario (1)
LIBSYS scenario (2)
Use cases
 Use-cases are a scenario based technique in the UML which identify the
actors in an interaction and which describe the interaction itself.
 A set of use cases should describe all possible interactions with the
system.
 Sequence diagrams may be used to add detail to use-cases by showing
the sequence of event processing in the system.
LIBSYS use cases
Ethnography
 A social scientists spends a considerable time observing
and analysing how people actually work.
 People do not have to explain or articulate their work.
 Social and organisational factors of importance may be
observed.
 Ethnography is an observational technique that can be used
to understand social and organisation requirements.
 Ethnographic studies have shown that work is usually richer
and more complex than suggested by simple system
models.
4. 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
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;
Traceability Matrix
Change Management
SUMMARY
 The requirements engineering process includes a feasibility study,
requirements elicitation and analysis, requirements specification and
requirements management.
 Requirements elicitation and analysis is iterative involving domain
understanding, requirements collection, classification, structuring,
prioritisation and validation.
 Systems have multiple stakeholders with different requirements.
 Social and organisation factors influence system requirements.
 Requirements validation is concerned with checks for validity,
consistency, completeness, realism and verifiability.
 Business changes inevitably lead to changing requirements.
 Requirements management includes planning and change management.
Thank you!!!

Any Questions???