Scribd
Upload
472 views

Lesson 3 Requirements Engineering and Analysis

This document discusses the requirements engineering process. It describes the key activities in requirements engineering as requirements elicitation, analysis, validation, and management. These processes involve gathering requirements from stakeholders through interviews, scenarios, and feasibility studies. Requirements are analyzed for consistency, completeness, and realism. They are validated through reviews, prototyping, and test case generation. Social and organizational factors that influence requirements are also considered.

Uploaded by

Amit Rathi
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
472 views

Lesson 3 Requirements Engineering and Analysis

This document discusses the requirements engineering process. It describes the key activities in requirements engineering as requirements elicitation, analysis, validation, and management. These processes involve gathering requirements from stakeholders through interviews, scenarios, and feasibility studies. Requirements are analyzed for consistency, completeness, and realism. They are validated through reviews, prototyping, and test case generation. Social and organizational factors that influence requirements are also considered.

Uploaded by

Amit Rathi
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 20

Intro to Software

Engineering

Requirements Engineering and


Analysis

Lesson 3
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
 Requirements elicitation;
 Requirements analysis;
 Requirements validation;
 Requirements management.
The requirements engineering process

Requirements
Feasibility
elicitation and
study analysis
Requirements
specification

Feasibility Requirements
report validation

System
models

User and system


requirements

Requirements
document
Feasibility studies
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?
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.
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 the spiral.
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
Interviewing
 Informal 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
 Scenariosare 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.
Social and organisational
factors
 Software systems are used in a social and
organisational context. This can influence or
even dominate the system requirements.
 Social and organisational factors are not a
single viewpoint but are influences on all
viewpoints.
 Good analysts must be sensitive to these
factors but currently no systematic way to
tackle their analysis.
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?
The END
Zainudin Johari
Senior Lecturer
Unity

B Sc. (Hons) Computer Science, UPM


M Sc. Computer Science (Information Systems) UPM

You might also like