Scribd
Upload
39 views21 pages

1 Chapter 4 Requirements Engineering

This document discusses requirements engineering for software development. It covers the requirements document, requirements engineering processes, requirements elicitation and analysis, requirements validation, and requirements management. The key processes covered are requirements elicitation through interviews, scenarios, observation, and ethnography. Requirements analysis, validation to ensure customer needs are met, and management of changing requirements over time are also summarized.

Uploaded by

Yaseen Shahid
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
39 views21 pages

1 Chapter 4 Requirements Engineering

This document discusses requirements engineering for software development. It covers the requirements document, requirements engineering processes, requirements elicitation and analysis, requirements validation, and requirements management. The key processes covered are requirements elicitation through interviews, scenarios, observation, and ethnography. Requirements analysis, validation to ensure customer needs are met, and management of changing requirements over time are also summarized.

Uploaded by

Yaseen Shahid
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 21

Requirements Engineering

Chapter 4 Requirements engineering 1


Today’s Topics

• Requirements Document
• Requirements engineering processes
• Requirements elicitation and analysis
• Requirements validation
• Requirements management

Chapter 4 Requirements engineering 2


Requirement engineering
• Without understanding what is required by a
client, You can not satisfy a customer.
• So we need to carefuly gather a
requirement,or analyze it.
• Requirement is very important phase of
developing any software
Requirement Documents

Chapter 4 Requirements engineering 4


The software requirements document
• The software requirements document is the
official statement of what is required of the
system developers.
• Should include both a definition of user
requirements and a specification(detailing) of
the system 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.

Chapter 4 Requirements engineering 5


Users of a requirements document

Chapter 4 Requirements engineering 6


Requirements document variability
• Information in requirements document depends
on type of system and the approach to
development used.
• Systems developed incrementally will, typically,
have less detail in the requirements document.
• Requirements documents standards have been
designed e.g. IEEE(Institute of Electrical and
Electronics Engineers) standard. These are
mostly applicable to the requirements for large
systems engineering projects.
Chapter 4 Requirements engineering 7
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.

Chapter 4 Requirements engineering 8


Requirement Engineering Process
1. Feasibility Study
2. Requirements Elicitation(discovery)
• The process of gathering information about
the required and existing systems and
distilling the user and system requirements
from this information.
• Interaction is with system stakeholders from
managers to external regulators.
• Systems normally have a range of
stakeholders.

Chapter 4 Requirements engineering 11


a. Interviewing
• Formal or informal interviews with stakeholders are
part of most RE processes.
• Types of interview
– Closed interviews based on pre-determined list of
questions
– Open interviews where various issues are explored with
stakeholders.
• Effective interviewing
– Be open-minded, avoid pre-conceived ideas about the
requirements and are willing to listen to stakeholders.
– Prompt the interviewee to get discussions going using a
list of questions, a requirements proposal.

Chapter 4 Requirements engineering 12


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…….
b. 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.
Case Study
c. Observing
• A social scientist 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.
• Ethnographic studies have shown that work is usually richer
and more complex than suggested by simple system models.

Chapter 4 Requirements engineering 18


d. Scope of ethnography
culture-method
• The main component is to observe according to
their cultural view, for this interviewing is done
• Requirements that are derived from the way that
people actually work.
• Requirements that are derived from cooperation
and awareness of other people’s activities.
• Ethnography is effective for understanding
existing processes but cannot identify new
features that should be added to a system.

Chapter 4 Requirements engineering 19


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.

Chapter 4 Requirements engineering 20


5. Requirements management
• Requirements management is the process of
managing changing requirements during the
requirements engineering process and system
development.

• New requirements emerge as a system is being


developed and after it has gone into use.

• You need to keep track of individual requirements


and maintain links between dependent
requirements so that you can assess the impact of
requirements changes..
Chapter 4 Requirements engineering 21

You might also like