Requirement Engineering

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

2. 1.1 Requirement Engineering1.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 ProcessRequirement Engineering Process
Helps software engineer to better understand Helps software engineer to better understand
the problem.the problem.
Participants involved:Participants involved:
Software Engineers
Managers
Customers
Users

4. 1.1 Requirement Engineering1.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 Introduction1.1.1 Introduction
Range from Range from High level abstract statement High level abstract statement from from
Detailed Mathematical SpecificationsDetailed Mathematical Specifications..

6. 1.1 Requirement Engineering1.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 1.1.2 Understanding
RequirementsRequirements
Collecting needs from the customer.Collecting needs from the customer.
Managing the Process.Managing the Process.
Tasks involved:Tasks involved:
Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements Management

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

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

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

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

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

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

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


Requirements Management

15. Types of RequirementsTypes of Requirements
Customer RequirementsCustomer Requirements
Define the expectations in terms of Mission
Objectives, Environment, Constraints and
Measures of Effectiveness and Suitability.
(MOE/MOS)
Functional Requirements 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:Non functional Requirements:
Specify criteria that can be used to Specify criteria that can be used to judge judge
the operationthe operation of a system rather than of a system rather than
behaviors.behaviors.
Performance Requirements:Performance Requirements:
Examine which a mission or function must Examine which a mission or function must
be executed. be executed.
Measured in terms of quality, quantity, Measured in terms of quality, quantity,
timeliness or readiness.timeliness or readiness.

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

18. 1.1 Requirement Engineering1.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 1.1.3 Requirement
EngineeringEngineering
Feasibility StudyFeasibility Study
Find out the current user needs.
Budget
Requirement AnalysisRequirement Analysis
What the stakeholders require from the system.
Requirements DefinitionRequirements Definition
Define the requirements in a form understandable to
the customer.
Requirements SpecificationRequirements Specification
Define the requirements in detail.

20. Requirements Document:Requirements Document:
Official Statement
Include both a definition and specification
Specify external system behavior
Specify implementation constraints.
Easy to change
Problems of Requirements AnalysisProblems 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 Engineering1.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 1.1.4 Ground Work
EstablishmentEstablishment
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 Engineering1.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 1.1.4.1 Stakeholders
IdentificationIdentification
Stakeholder may be a project team member, employee of Stakeholder may be a project team member, employee of
the user organization or a Senior Manager.the user organization or a Senior Manager.
Stakeholder analysis is a technique to identify and analysis Stakeholder analysis is a technique to identify and analysis
the stakeholders project.the stakeholders project.
Provides information on stakeholders and their Provides information on stakeholders and their
relationships, interests and their expectations.relationships, interests and their expectations.
Stakeholder expectations and Interests:Stakeholder expectations and Interests:
““Guess Work”Guess Work”
Approaches:Approaches:
Using checklist
Plotting people in small models.

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

26. 1.1 Requirement Engineering1.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 1.1.4.2 Multiple Viewpoint
RecognitionRecognition
Marketing GroupMarketing Group is interested in functions is interested in functions
and features (easy to sell)and features (easy to sell)
Support engineers Support engineers may focus on may focus on
maintainability of the software.maintainability of the software.
Business managers Business managers are interested in a are interested in a
feature that will be ready to meet defined feature that will be ready to meet defined
market windows.market windows.

28. 1.1 Requirement Engineering1.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 Collaboration1.1.4.3 Collaboration
Each stakeholders has Each stakeholders has
different opinion different opinion
about the set of about the set of
requirements.requirements.
Requirement engineer Requirement engineer
must identify areas of must identify areas of
commonalitycommonality..
Identify the area of Identify the area of
inconsistencyinconsistency..
Reduce dependencies Reduce dependencies
among engineersamong engineers..

30. 1.1 Requirement Engineering1.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 1.1.1.4 Requirement
ElicitationElicitation
Discovering the requirement for the system.Discovering the requirement for the system.
Identify the requirements by communicating with the customers, system Identify the requirements by communicating with the customers, system
users and other.users and other.
Requirements sources:Requirements sources:
Domain Knowledge
Stakeholders
Operational Environment
Organizational Environment.
Elicitation Techniques:Elicitation Techniques:
Interviews
Scenarios
Facilitated Meeting
Prototypes
Observation

32. 1.1 Requirement Engineering1.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 1.1.4.5 Building Use
CasesCases
Use cases Use cases describe the interactions describe the interactions
between a user and a systembetween a user and a system..
Focusing on What the system Focusing on What the system DOESDOES for the for the
user.user.
Describe the Describe the totality of the system totality of the system and and
behavior of the system.behavior of the system.
Includes:Includes:
Actors List
Use case packages
Use case diagrams
Use case text
Use case views.

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

35. Steps for developing use case Steps for developing use case
diagramdiagram
1.1.Use abstract ideaUse abstract idea
2.2.Define use case actorsDefine use case actors
3.3.Define use case actor goalsDefine use case actor goals
4.4.Identify reuse opportunity for use caseIdentify reuse opportunity for use case
5.5.Create use case indexCreate use case index
6.6.Identify the key componentsIdentify the key components
7.7.Name and briefly describe the use case.Name and briefly describe the use case.
8.8.Create use case basic viewCreate use case basic view
9.9.Create use case alternate flowsCreate use case alternate flows
10.10.Produce the use case documentProduce the use case document
11.11.Generate a use case model diagram. Generate a use case model diagram.

36. Sample Use case DiagramSample Use case Diagram

37. 1.1.4.6 Negotiating Requirements 1.1.4.6 Negotiating Requirements
(RN)(RN)
Effective practices: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 Requirements1.1.4.7 Validating Requirements
Requirement ReviewsRequirement Reviews
Prototyping (Model) Prototyping (Model)
Model ValidationModel Validation
Acceptance TestsAcceptance Tests