Requirements Engineering: A Roadmap

1
Requirements Engineering A Roadmap
-Sandeep Kamath
2
What is requirements engineering?
3
Why do we need RE?
4
Foundations of RE
5
Oversimplified RE Process
Preparation Context Groundwork
Eliciting Requirements
Modeling and Analyzing Requirements
Communicating Requirements
Agreeing Requirements
Evolving Requirements
6
Oversimplified RE Process
Preparation Context Groundwork
Eliciting Requirements
Modeling and Analyzing Requirements
Communicating Requirements
Agreeing Requirements
Evolving Requirements
7
Preparation Context Groundwork

• Specific customer / Market driven
• Type of product
• Project feasibility
• Risks assessment

8
Oversimplified RE Process
Preparation Context Groundwork
Eliciting Requirements
Modeling and Analyzing Requirements
Communicating Requirements
Agreeing Requirements
Evolving Requirements
9
Eliciting Requirements

• Identify the system boundaries
• Identify the stakeholders
• Clients, Developers and Users
• Goals
• Problem domain - Not on solutions

10
Elicitation techniques
Traditional
Group Elicitation
Prototyping
Model-Driven
Cognitive
Contextual
11
Oversimplified RE Process
Preparation Context Groundwork
Eliciting Requirements
Modeling and Analyzing Requirements
Communicating Requirements
Agreeing Requirements
Evolving Requirements
12
Approaches for modeling requirements
Enterprise Modeling
Data Modeling
Behavioral Modeling
Domain Modeling
Modeling Non-Functional Requirements
13
Oversimplified RE Process
Preparation Context Groundwork
Eliciting Requirements
Modeling and Analyzing Requirements
Communicating Requirements
Agreeing Requirements
Evolving Requirements
14
Oversimplified RE Process
Preparation Context Groundwork
Eliciting Requirements
Modeling and Analyzing Requirements
Communicating Requirements
Agreeing Requirements
Evolving Requirements
15
Oversimplified RE Process
Preparation Context Groundwork
Eliciting Requirements
Modeling and Analyzing Requirements
Communicating Requirements
Agreeing Requirements
Evolving Requirements
16
RE future

• Formal modeling and analyzing properties of the
  environment
• Fill the gap between informal and the formal
• Capture NFRs better
• Impact of architecture on requirements
• Reuse of requirements models
• Multidisciplinary training for requirements
  practitioners

17
Strengths of the approach

• Comprehensive
• Structured well
• Good application of theories from various
  disciplines

Weaknesses of the approach

• RE for COTS based systems
• Expectations management not covered

18
RE for Embedded Systems State of the practice
Embedded Software Engineering The State of the
Practice Bas Graaf, Marco Lormans, and Hans
Toetenel, Delft University of Technology,
Netherlands
19
Decomposition of embedded systems development
process

• Multidisciplinary subsystems
• Monodisciplinary subsystems

20
Stakeholders and other factors

• Many stakeholders
• Design, Requirements mixed up
• Natural language, Ordinary word processing tools
  to specify
• NFRs not handled well
• Diagrams similar to UML, DFDs, etc
• Formal specs, tools avoided
• Legacy systems traceability problem
• Relations b/w requirements not documented

21
Questions?