1. Requirements Engineering A Roadmap
Jichuan Chang
Based on
“RE roadmap” by Nuseibeh & Easterbrook
RE course materials by Steve Easterbrook
9/16/2018

2. Outline Foundations Basic Requirements Engineering activities
What is RE?
Why important?
Inter-disciplinary aspects of RE
Basic Requirements Engineering activities
Directions and Discussion
9/16/2018

3. Discussion About requirements: About RE: Future directions:
What and How? Environment and Machine
Is there always a bridge from the real-world to the “machine”?
Is formal specification suitable for all requirements?
About RE:
Is RE really important? Who can benefic from RE?
What is really used in practice?
Why so many methods/techniques? How to evaluate and choose?
What’s the process that integrates methods and activities?
RE tools? Traceability?
Future directions:
What’s the impact of imperfect requirements?
inconsistency? incomplete? evolving?
What’s the impact to other development activities?
What’s the impact of architectural decision to NFRs?
What’s the impact of requirement reuse?
9/16/2018

4. What is RE? What’s Requirement? [IEEE Std] What is RE? [Zave94]
A condition or capability needed by a user to solve a problem or achieve an objective. The set of all requirements forms the basis for subsequent development of the system or system component.
What is RE? [Zave94]
Requirements Engineering is the branch of systems engineering concerned with real-world goals for, services provided by, and constraints on software systems.
Requirements Engineering is also concerned with the relationship of these factors to precise specifications of system behavior and to their evolution over time and across system families.
9/16/2018

5. Importance of Requirements
Engineering Argument
A good solution can only be developed if the engineer has a solid understanding of the problem.
Economic Argument
Defects are cheaper to remove if are found earlier.
Empirical Argument
Failure to understand and manage requirements is the biggest single cause of cost and schedule over-runs.
Safety Argument
Safety-related software errors arise most often from inadequate or misunderstood requirements
… …
9/16/2018

6. Research on RE Early research: One epigram summarized all of RE.
Reqts. say what the system will do and not how it will do it.
A time-consuming, bureaucratic & contractual process?
1990’s: A field of study of it own right
Two series of international meetings: RE and ICRE
International journal by Springer.
Late 1990’s: Grown up enough
Many additional smaller meetings and workshops
Emphasize the use of contextualized enquiry techniques
Model indicative & optative properties of the environment
Handle inconsistent and evolving specification
Future: increasingly recognized as a critical activity
9/16/2018

7. RE Basics Dimensions of RE What vs. How
What does a web browser do?
‘What’ refers to a system’s purpose
external to the system
A property of the application domain
‘How’ refers to a system’s structure & behavior
internal to the system
A property of the machine domain
Foundations of RE – Multi-discipline
Systems Theory, Systems Engineering, Math & Logic, Computer Science, Social Sciences, Cognitive Sciences, Philosophy, AI
9/16/2018

8. RE process RE in software lifecycle Essential RE process RE groundwork
Initial phase
may also span the entire life cycle
Essential RE process
Understand the problem
elicitation
Formally describe the problem
specification, modeling
Attain agreement on the nature of problem
validation, conflict resolution, negotiation
requirements management - maintain the agreement!
Sequential or iterative/incremental
RE groundwork
Feasibility, risk, concept of operations
Decide the RE process, methods and techniques
9/16/2018

9. Outline Foundations Basic Requirements Engineering activities
Eliciting Requirements
Modeling and Analyzing Requirements
Communicating Requirements
Agreeing Requirements
Evolving Requirements
RE Tool
Directions and Discussion
9/16/2018

10. Eliciting Requirements
Source of Requirements:
Customer-driven, Market-driven, Hybrid
Affect the role of Requirements
Things to elicit
System boundaries
Stakeholders & User Classes
Viewpoints
Goals and tasks
Scenarios/Use cases
Elicitation techniques
Interviews, questionnaires, surveys, meetings
Prototyping
Ethnographic techniques
Knowledge elicitation techniques
Conversation Analysis
Text Analysis
Elicitation process:
Inquiry cycle
Use case analysis
9/16/2018
Ethnographic: a branch of sociology dealing with nonspecialists' commonsense
understanding of the structure and organization of society

11. Modeling Requirements
Why Modeling?
Modeling can guide elicitation
it help you ask the right questions?
Modeling can provide a measure of progress:
if we’ve filled in all the pieces of the model, are we done?
Modeling can help to uncover problems
Does inconsistency in the model reveal interesting things…?
conflicting or infeasible requirements; confusion over terminology, scope, etc; reveal disagreements between stakeholders
Modeling can help us check our understanding
Can we test that the model has the properties we expect?
Can we reason over the model to understand its consequences?
Can we animate the model to help us visualize/validate the requirements?
9/16/2018

12. Modeling Techniques Information modeling: Modeling Enterprises
ERD
Organization modeling:
i*, SSM, ISAC
Goal modeling:
KAOS, CREWS
Modeling Enterprises
Goals & objectives
Organizational structure
Processes and products
Agents and work roles
Modeling Functional Requirements
Structural views
Behavioral views
Timing requirements
Modeling Non-functional Requirements
Product requirements
Process requirements
External requirements
Structured Analysis:
SADT, SSADM, JSD
Object Oriented Analysis:
OOA, OOSE, OMT, UML
Formal Methods:
SCR, RSML, Z, Larch, VDM
Quality tradeoffs:
QFD, win-win
Specific NFRs:
Performance:Timed Petri nets
Usability: Task models
Reliability: Probabilistic MTTF
9/16/2018

13. Communicating Reqts - SRS
How do we communicate the Requirements to others?
It is common practice to capture them in an SRS
Purpose
Communicates an understanding of the requirements
Contractual
Baseline for evaluating subsequent products
testing, V&V
Baseline for change control
Audience
Users, Purchasers
Requirements Analysts
Developers, Programmers
Testers
Project Managers
9/16/2018

14. SRS for Procurement An ‘SRS’ may be written by:
the procurer (a call for proposals)
Must be general enough to yield a good selection of bids
… and specific enough to exclude unreasonable bids
the bidders (a proposal to meet the CfP)
must be specific enough to demonstrate feasibility and competence
… and general enough to avoid over-commitment
the selected developer
reflects the developer’s understanding of the customers needs
forms the basis for evaluation of contractual performance
or an independent RE contractor
Choice over what point to compete the contract
Early (conceptual stage)
Late (detailed specification stage)
IEEE Standard recommends SRS jointly developed by procurer and developer
9/16/2018

15. Reqts Traceability Importance: Difficulties: Current Practice
Verification & Validation
Maintenance
Assessing change requests
Tracing design rationale
Document access
Process visibility
Management
change management
risk management
control of the development process
Difficulties:
Cost
Delayed gratification
Size and diversity
Current Practice
Focuses on baselined requirements
Coverage
links from requirements forward to designs, code, test cases,
links back from designs, code, test cases to requirements
links between requirements at different levels
Tools (manual, syntactic) ??
Approaches:
UID, hypertext linking
Ability:
Follow links
Find missing links
Measure overall traceability
9/16/2018

16. Agreeing Requirements
Two key problems: validation & negotiation
Validation - What is “truth” and what is “knowable”?
Approaches (Based on philosophical assumptions):
assumes there is an objective problem that exists in the world
design your requirements models to be refutable
validation is always subjective and contextualised
Method in practice:
Inspections, Reviews and Walkthroughs
Prototyping: Throwaway or Evolve?
Negotiation - How to reconcile conflicting goals?
Requirements Negotiation
Competition
Third Party Resolution
Bidding and Bargaining
9/16/2018

17. Evolving Requirements
Software evolves because requirements evolve …
How to manage incremental change to reqts models?
How can multiple models (specifications) be compared?
How to capture the rationale for each change?
Traditional change management
Add, modify, remove requirements during development
Baselines, Change Requests, Review Boards
Software Families
The product line approach
Viewpoints
Requirements model is a collection of viewpoints
as a framework for understanding requirements evolution
Viewpoints are instantiated from viewpoint templates
Viewpoints contain consistency rules (no central control)
Internal rule, External rule, Work plan
9/16/2018

18. RE Tool examples Requisite Pro DOORS Cradle
products/reqpro/
Support Unified Process
Support use-case based, declarative, and mixed representation (document templates)
Support Requirements Traceability
Integrated with change mgmt, modeling, testing, metrics and project mgmt tools.
DOORS
Inter-project linking, Multiple Views
Integration with MS Office and external communication tools
Cradle
9/16/2018

19. Outline Foundations Basic Requirements Engineering activities
Directions and Discussion
9/16/2018

20. Future Research Directions
Trends in the 1990’s
Emphasize the use of contextualized enquiry techniques
Model indicative & optative properties of the environment
Handle inconsistent and evolving specification
Future Directions:
Modeling and analysis of problem domain, as opposed to the behavior of software.
Models for non-functional requirements (NFR).
Bridging the gap between contextual enquiry and formal specification techniques.
Impact of architectural choices on the prioritization and evolution of requirements.
Reuse of requirements models to facilitate the development of system families and COTS selection.
Multi-disciplinary training for requirements practitioners.
9/16/2018

21. Discussion About requirements: About RE: Future directions:
What and How? Environment and Machine
Is there always a bridge from the real-world to the “machine”?
Is formal specification suitable for all requirements?
About RE:
Is RE really important? Who can benefic from RE?
What is really used in practice?
Why so many methods/techniques? How to evaluate and choose?
What’s the process that integrates methods and activities?
RE tools? Traceability?
Future directions:
What’s the impact of imperfect requirements?
inconsistency? incomplete? evolving?
What’s the impact to other development activities?
What’s the impact of architectural decision to NFRs?
What’s the impact of requirement reuse?
9/16/2018