1. Requirement Engineering
Saranya.V
AP/CSE,
Sri Vidya College of Engineering &
Technology,
Virudhunagar

2. 1.1 Requirement Engineering
1.1.1 Introduction
1.1.2 Understanding Requirements
1.1.3 Requirements Engineering
1.1.4 Ground Work Establishment
 1.1.4.1 Stakeholders Identification
 1.1.4.2 Multiple Viewpoints Recognition
 1.1.4.3 Collaboration
 1.1.4.4 Requirements Elicitation
 1.1.4.5 Building Use Cases
 1.1.4.6 Negotiating Requirements
 1.1.4.7 Validating Requirements

3. Requirement Engineering Process
Helps software engineer to better understand
the problem.
Participants involved:
Software Engineers
Managers
Customers
Users

4. 1.1 Requirement Engineering
1.1.1 Introduction
1.1.2 Understanding Requirements
1.1.3 Requirements Engineering
1.1.4 Ground Work Establishment
 1.1.4.1 Stakeholders Identification
 1.1.4.2 Multiple Viewpoints Recognition
 1.1.4.3 Collaboration
 1.1.4.4 Requirements Elicitation
 1.1.4.5 Building Use Cases
 1.1.4.6 Negotiating Requirements
 1.1.4.7 Validating Requirements

5. 1.1.1 Introduction
Range from High level abstract statement from
Detailed Mathematical Specifications.

6. 1.1 Requirement Engineering
1.1.1 Introduction
1.1.2 Understanding Requirements
1.1.3 Requirements Engineering
1.1.4 Ground Work Establishment
 1.1.4.1 Stakeholders Identification
 1.1.4.2 Multiple Viewpoints Recognition
 1.1.4.3 Collaboration
 1.1.4.4 Requirements Elicitation
 1.1.4.5 Building Use Cases
 1.1.4.6 Negotiating Requirements
 1.1.4.7 Validating Requirements

7. 1.1.2 Understanding
Requirements
Collecting needs from the customer.
Managing the Process.
Tasks involved:
 Inception
 Elicitation
 Elaboration
 Negotiation
 Specification
 Validation
 Requirements Management

8. Inception (Beginning)
During inception, the
requirements asks a set of
questions to establish:
Basic understanding of the
problem.
Nature of the solution that
is desired.
Requirements Engineers
needs to Identify the
stakeholders, recognize
multiple viewpoints, work
toward collaboration and
initiate the communication.

9. Elicitation: (Extraction)
Eliciting requirements is difficult because of
 Problems of scope  identify the boundaries of
the system.
 Problems of understanding  domain , computing
environment.
 Problems of Volatility  requirements may change
over time.
Elicitation may be accomplished through two
activities:
 Collaborative Requirements Gathering
 Quality Function Deployment.

10. Elaboration (explanation)
Takes the information obtained
during inception and elicitation.
Focuses on developing a refined
model of software functions,
features & Constraints.
This is an analyzing phase.
It defines the functional,
informational and behavioral
constraints of the problem
domain.

11. Negotiation (Cooperation)
 Software engineer
reconciles the conflicts
between what the
customer wants and
what can be achieved.
 Requirements are ranked
by the customer, users
and other stakeholders.
 Risks associated with
each requirement are
identified.

12. Specifications
 Final work product produced by
the requirements engineer.
 Form of SRS.
 Serves as a foundation.
 It formalizes the functional and
behavioral requirements of the
proposed software in both the
graphical and textual format.

13. Validation
 Specification is examined to
ensure that all the sw
requirements have been
stated unambiguously.
 Errors have been detected
and corrected.
 Members involved:
 Software Engineers
 Customers
 Users
 Other stakeholders.

14. Requirements Management
 Project team performs a set of activities to identify,
control and track requirements and changes to the
requirements at any times as the project proceeds.
 Each requirement is assigned a unique identifier.
 Place the requirements into one or traceability
tables.
 Tables may be stored in a database that relate
features, sources, dependencies subsystems and
interfaces to the requirements.

15. Types of Requirements
Customer Requirements
Define the expectations in terms of Mission
Objectives, Environment, Constraints and
Measures of Effectiveness and Suitability.
(MOE/MOS)
Functional Requirements
Explain what has to be done.
Identify the necessary action or activity and
task.
Used as the top level functions for functional
analysis.

16.  Non functional Requirements:
 Specify criteria that can be used to judge
the operation of a system rather than
behaviors.
Performance Requirements:
 Examine which a mission or function must
be executed.
 Measured in terms of quality, quantity,
timeliness or readiness.

17. Design Requirements:
 Build to, Code to, buy to. Those who are involving in
requirement Analysis:
 Use technical data Requirement Engineer
packages and technical System Analyst
manuals. System Engineer
Derived Requirements: Project Leader
 Implied or transformed System Engineer
from higher level
requirement.
Allocated Requirement:
 Higher level : 100
 Lower level : 70 and 30

18. 1.1 Requirement Engineering
1.1.1 Introduction
1.1.2 Understanding Requirements
1.1.3 Requirements Engineering
1.1.4 Ground Work Establishment
 1.1.4.1 Stakeholders Identification
 1.1.4.2 Multiple Viewpoints Recognition
 1.1.4.3 Collaboration
 1.1.4.4 Requirements Elicitation
 1.1.4.5 Building Use Cases
 1.1.4.6 Negotiating Requirements
 1.1.4.7 Validating Requirements

19. 1.1.3 Requirement
Engineering
Feasibility Study
Find out the current user needs.
Budget
Requirement Analysis
What the stakeholders require from the system.
Requirements Definition
Define the requirements in a form understandable to
the customer.
Requirements Specification
Define the requirements in detail.

20. Requirements Document:
Official Statement
Include both a definition and specification
Specify external system behavior
Specify implementation constraints.
Easy to change
Problems of Requirements Analysis
Stakeholders don’t know what they really want
Stakeholders express requirements in their own terms
Requirement change during the analysis process.

21. 1.1 Requirement Engineering
1.1.1 Introduction
1.1.2 Understanding Requirements
1.1.3 Requirements Engineering
1.1.4 Ground Work Establishment
 1.1.4.1 Stakeholders Identification
 1.1.4.2 Multiple Viewpoints Recognition
 1.1.4.3 Collaboration
 1.1.4.4 Requirements Elicitation
 1.1.4.5 Building Use Cases
 1.1.4.6 Negotiating Requirements
 1.1.4.7 Validating Requirements

22. 1.1.4 Ground Work
Establishment
Ground Work for Requirement Analysis consist
of
 Identifying stakeholders,
 Recognizing viewpoints,
 Establishing collaboration among the stakeholders
through conducting conversions and questionnaire
among the stakeholders.

23. 1.1 Requirement Engineering
1.1.1 Introduction
1.1.2 Understanding Requirements
1.1.3 Requirements Engineering
1.1.4 Ground Work Establishment
 1.1.4.1 Stakeholders Identification
 1.1.4.2 Multiple Viewpoints Recognition
 1.1.4.3 Collaboration
 1.1.4.4 Requirements Elicitation
 1.1.4.5 Building Use Cases
 1.1.4.6 Negotiating Requirements
 1.1.4.7 Validating Requirements

24. 1.1.4.1 Stakeholders
Identification
Stakeholder may be a project team member, employee of
the user organization or a Senior Manager.
Stakeholder analysis is a technique to identify and analysis
the stakeholders project.
Provides information on stakeholders and their
relationships, interests and their expectations.
Stakeholder expectations and Interests:
“Guess Work”
Approaches:
Using checklist
Plotting people in small models.

25. Stakeholder influence and Role in
the project
Be active
Involvement
Vested interest.
Stakeholder Categories:
Project Manager
Team Members
Team Leads
Project Resource Manager
Senior Managers, Executives or Sponsors

26. 1.1 Requirement Engineering
1.1.1 Introduction
1.1.2 Understanding Requirements
1.1.3 Requirements Engineering
1.1.4 Ground Work Establishment
 1.1.4.1 Stakeholders Identification
 1.1.4.2 Multiple Viewpoints Recognition
 1.1.4.3 Collaboration
 1.1.4.4 Requirements Elicitation
 1.1.4.5 Building Use Cases
 1.1.4.6 Negotiating Requirements
 1.1.4.7 Validating Requirements

27. 1.1.4.2 Multiple Viewpoint
Recognition
Marketing Group is interested in functions
and features (easy to sell)
Support engineers may focus on
maintainability of the software.
Business managers are interested in a
feature that will be ready to meet defined
market windows.

28. 1.1 Requirement Engineering
1.1.1 Introduction
1.1.2 Understanding Requirements
1.1.3 Requirements Engineering
1.1.4 Ground Work Establishment
 1.1.4.1 Stakeholders Identification
 1.1.4.2 Multiple Viewpoints Recognition
 1.1.4.3 Collaboration
 1.1.4.4 Requirements Elicitation
 1.1.4.5 Building Use Cases
 1.1.4.6 Negotiating Requirements
 1.1.4.7 Validating Requirements

29. 1.1.4.3 Collaboration
Each stakeholders has
different opinion
about the set of
requirements.
Requirement engineer
must identify areas of
commonality.
Identify the area of
inconsistency.
Reduce dependencies
among engineers.

30. 1.1 Requirement Engineering
1.1.1 Introduction
1.1.2 Understanding Requirements
1.1.3 Requirements Engineering
1.1.4 Ground Work Establishment
 1.1.4.1 Stakeholders Identification
 1.1.4.2 Multiple Viewpoints Recognition
 1.1.4.3 Collaboration
 1.1.4.4 Requirements Elicitation
 1.1.4.5 Building Use Cases
 1.1.4.6 Negotiating Requirements
 1.1.4.7 Validating Requirements

31. 1.1.1.4 Requirement
Elicitation
Discovering the requirement for the system.
Identify the requirements by communicating with the customers, system
users and other.
Requirements sources:
Domain Knowledge
Stakeholders
Operational Environment
Organizational Environment.
Elicitation Techniques:
Interviews
Scenarios
Facilitated Meeting
Prototypes
Observation

32. 1.1 Requirement Engineering
1.1.1 Introduction
1.1.2 Understanding Requirements
1.1.3 Requirements Engineering
1.1.4 Ground Work Establishment
 1.1.4.1 Stakeholders Identification
 1.1.4.2 Multiple Viewpoints Recognition
 1.1.4.3 Collaboration
 1.1.4.4 Requirements Elicitation
 1.1.4.5 Building Use Cases
 1.1.4.6 Negotiating Requirements
 1.1.4.7 Validating Requirements

33. 1.1.4.5 Building Use
Cases
Use cases describe the interactions
between a user and a system.
Focusing on What the system DOES for the
user.
Describe the totality of the system and
behavior of the system.
Includes:
Actors List
Use case packages
Use case diagrams
Use case text

34. Activities involved in use
cases
Find actors
Project Manager
Architect
End-users
Customers
Development Team
Find use cases
Describe the use case.

35. Steps for developing use case
diagram
1. Use abstract idea
2. Define use case actors
3. Define use case actor goals
4. Identify reuse opportunity for use case
5. Create use case index
6. Identify the key components
7. Name and briefly describe the use case.
8. Create use case basic view
9. Create use case alternate flows
10. Produce the use case document
11. Generate a use case model diagram.

36. Sample Use case Diagram

37. 1.1.4.6 Negotiating Requirements
(RN)
Effective practices:
Get the right stakeholder
Establish team work mentality
Plan team iteration
Use Group Support System(GSS)
Establish shared vocabulary
Maintain list of requirements
Record requirement attributes
Manage by probabilities
Select base decisions
Select operational approach
Plan more
Re-plan before every release
Find workable solution
Provide training in the negotiation process
Use trained facilitator
Consider requirement, architecture and market place.
Leverage the triple constraint (Cost Vs Time Vs Scope)

38. 1.1.4.7 Validating Requirements
Requirement Reviews
Prototyping (Model)
Model Validation
Acceptance Tests