1. REQUIREMENT ENGINEERING
Presented by
Mrs.K.Keerthana AP/IT

2. INTRODUCTION
 Goal - Create and maintain a system
requirements document
 Four Sub Process
1. Feasibility study
2. Elicitation and analysis
3. Specification
4. Validation

3. CONTD.,

4. FEASIBILITY STUDIES
 The input to the feasibility study is a set of
preliminary business requirements, an outline
description of the system
 After feasibility study
1. Does the system contribute to the overall
objectives of the organisation?
2. Can the system be implemented using Current
technology and within given cost
and schedule constraints?
3. Can the system be integrated with other systems
which are already in place?

5. CONTD.,
 Managers - where the system will be used
 Software engineers – To deal with the technology
 Feasibility study must be completed in two or three
weeks of time
 It leads to changes to the scope, budget and
schedule of the system

6. REQUIREMENTS ELICITATION AND ANALYSIS
 Requirements elicitation and analysis may involve a
variety of people
 Stakeholder is used to refer to any person or group
who will be affected by the system, directly or
indirectly
 This process is difficult because
1. Stakeholders often don't know what they want
2. Stakeholders naturally express requirements in
their own term
3. Different stakeholders have different requirements

7. CONTD.,
 The process activities are
1. Requirements discovery - To Collect the requirements
2. Requirements classification and organisation – Group
related requirements
3. Requirements prioritisation and negotiation – Giving
Priority and avoid the conflicts
4. Requirements documentation – after each level
requirements are documented and given as input for
next level

8. 1. REQUIREMENTS DISCOVERY
 Process of gathering information about the
proposed and existing systems
 Methods - Interact with stakeholders through
interviews and observation Or use scenarios
 Stakeholders, domain, systems are represented as
system viewpoints

9. 1.1 VIEW POINTS
 Initially used by Mullery, 1979 and
Sommerville,1996
 Recognises multiple perspectives and provides a
framework for discovering conflicts
 Three Types
 1. Interactor viewpoints - people or systems that
interact directly
 2. Indirect viewpoints - stakeholders who do not use
the system themselves
 3. Domain viewpoints - constraints that influence
the system requirements

10. 1.2 INTERVIEW
 Questions are given to the stakeholders about the
system that they use and the system to be
developed
 Two Types
1. Closed interviews - predefined set of questions.
2. Open interviews - no predefined agenda.
 How effective interviews can be done?????

11. 1.3 SCENARIOS
 People usually find it easier to relate to real-life
examples
 1. A description of what the system and users
expect when the scenario starts
 2. A description of the normal flow of events in the
scenario
 3. A description of what can go wrong and how this
is handled
 4. Information about other activities that might be
going on at the same time
 5. A description of the system state when the
scenario finishes.

12. 1.3.1 USE CASE
 First introduced in the Objectory method by
Jacobsen at 1993
 use-case identifies the type of interaction and the
actors involved.
 Actors are represented as stick figures and class of
interaction is represented as ellipse

13. 2. ETHNOGRAPHY
 An observational technique that can be used to
understand social and organisational requirements
 An analyst immerses himself in the working
environment where the system will be used
 It is effective because
 Requirements that are derived from the way in
which people actually work
 Requirements that are derived from cooperation
and awareness of other people's activities