12th slide set of CECS 542 How to scale requirements engineering for different project settings How to decompose and refine requirements for subsystems Complete course available at http://foss2serve.org/index.php/Requirements_Engineering,_CSU_Long_Beach,_Penzenstadler

1. Overview of how to scale RE for
specific project se5ngs
& requirements refinement
Dr. Birgit Penzenstadler
Photo credit: Garre6 Parker, Unsplash

2. Scaling RE & Refinement
• Tailoring RE
– Small
– Medium
– Large
• How to define for a project
• ConsolidaJon, Refinement and DecomposiJon
• System models
• Traceability and Twin Peaks
Dr. Birgit Penzenstadler 2

3. Main Factors for Tailoring RE
• Project seOng: Project size, budget size, Jme constraints, number of people,
overall soQware development process
• Knowledge
– Level of understanding of the problem domain
– Level of understanding of the applicaJon domain
– Skills of the developers
– New team versus well acquainted and pracJced
• Stakeholders
– Availability of stakeholders
– RelaJonship to stakeholders
– Types of stakeholders (especially moJvaJon)
• Type of system
– Business informaJon system, embedded system, cyber-physical system, web service
– New product versus well established product
– Viability and technical feasibility
– Maturity of underlying technology
• System characterisJcs, e.g.:
Relevance of safety, security, robustness, dependability, etc.
• Business & legal concerns:
Legality, ethical concerns, patents, licenses, standards
Birgit Penzenstadler

4. MinimalisJc RE
• Agile seOng
• User Stories
• h<p://www.agilemodeling.com/arAfacts/userStory.htm
• Test Spec
(from acceptance
criteria in user stories)
• Backlog (where things
are saved when done)
Birgit Penzenstadler

5. Medium-size RE
Requirements / System / Solution DomainContext / Environment / Problem Domain
Stakeholder Model
Objectives,
& Goals
System Vision
Deployment Requirements
System Constraints
Domain Model
Usage Model
Quality Requirements
Process Requirements
elicit
objectives
find stakeholders
analyse context
elicit
constraints
derive
system
vision
refine and deduce
requirements
specify
interaction
Constraints
& Rules
!
!
!
!
!
Birgit Penzenstadler
• Effort: Person months (rough guess)
• Contract or consultant situaJon
• Subset of items of AMDiRE

6. Large-scale RE
• Effort: Person years
• All items of AMDiRE
• Large projects, safety-
criJcal or other
characterisJcs that
require in detail
specificaJon, embedded
systems, subcontractors
Birgit Penzenstadler
Context Layer
System Layer
Requirements Layer
Stakeholder Model Objectives
& Goals
Constraints
& Rules
!
!
!
!
!
Data Model
E
A
A
A
E
System Vision
Functional
Hierarchy
Architecture Overview
System
Function Model
Fun 1
Fun 2
Component Model
C C
Data Model
E
A
A
A
E
Behaviour Model
Business Case
Deployment Requirements
System Constraints
Domain Model
Service ModelUsage Model
Quality Requirements
Risk List
Project Scope
Process Requirements
Glossary
Glossary
Glossary

7. How to define it for a project
(= how to make use of everything you learned in this course for
later project management and set-up)
1. Analyze the characterisJcs of your
project
(slide 2 “Main Factors”)
2. Look at the AMDiRE model
(slide set 4)
3. Prune things you don’t need
4. Adapt items you need accordingly
(e.g. extra piece of info needed)
5. Make/use templates (for individual
arJfacts and maybe overall spec)
6. Define the tools (RE & design)
7. Define roles & milestones with and
for your team
8. Define the change process (see
Requirements Mngmt.)
Birgit Penzenstadler
Context Layer
System Layer
Requirements Layer
Stakeholder Model Objectives
& Goals
Constraints
& Rules
!
!
!
!
!
Data Model
E
A
A
A
E
System Vision
Functional
Hierarchy
Architecture Overview
System
Function Model
Fun 1
Fun 2
Component Model
C C
Data Model
E
A
A
A
E
Behaviour Model
Business Case
Deployment Requirements
System Constraints
Domain Model
Service ModelUsage Model
Quality Requirements
Risk List
Project Scope
Process Requirements
Glossary
Glossary
Glossary
Process Task
Next Process
A
This has an
associated...Note or
suggestion

8. ConsolidaJon and Refinement of
requirements
• How do I consolidate requirements?
• How do requirements get refined over
AMDiRE and in general?
– Concepts: DecomposiJon & refinement
– IteraJve process
– Traceability important
• Twin Peaks model

9. Concepts:
DecomposiJon
& refinement
• DecomposiJon:
How to distribute it
onto subsystems?
• Refinement:
How to enrich with
more informaJon?
Context Layer
System Layer
Requirements Layer
Stakeholder Model Objectives
& Goals
Constraints
& Rules
!
!
!
!
!
Data Model
E
A
A
A
E
System Vision
Functional
Hierarchy
Architecture Overview
System
Function Model
Fun 1
Fun 2
Component Model
C C
Data Model
E
A
A
A
E
Behaviour Model
Business Case
Deployment Requirements
System Constraints
Domain Model
Service ModelUsage Model
Quality Requirements
Risk List
Project Scope
Process Requirements
Glossary
Glossary
Glossary

10. System Models: Refinement and
DecomposiJon
10
System: A system is delimited from ist context by the system border.
A system has an interface. A system is composed of elements
(components, subsystems) that are interrelated.
A subsystem can again be perceived as a system.
System
Context
System border
(Interface to context)
CSULB spring 2015 Dr. Birgit Penzenstadler

11. System Models: Refinement and
DecomposiJon
11
Refinement: Enriching information with more detail
Decomposition: Separating information into several parts
System
Context
CSULB spring 2015 Dr. Birgit Penzenstadler

12. System Models: AbstracJon Levels
12
An abstracJon level
describes the whole system
on a certain level of
abstracJon. The degree is
chosen such that each level
reflects a specific aspect
important for soQware
development.
Usage Level
(Black box)
Subsystem
Level
Technical
Architecture
RelaJonships
CSULB spring 2015 Dr. Birgit Penzenstadler

13. IteraJve process
1. Start with one of:
Project Scope, Business Case Analysis, Domain
Model, Stakeholders, System vision, Goal Model
2. Then elaborate the others, including Usage
Model
3. Then check back whether other arJfacts need to
be updated
4. Even during design you might have to go back
and update or change informaJon

14. Traceability important
• There are shared concepts between the arJfacts, and
via these concepts the arJfacts are connected.
• This means, you can trace informaJon throughout the
requirements specificaJon.
• On the lower abstracJon levels (design), this
traceability is given via a common system model.
• For example:
– Every goal should have a stakeholder
– Every use case should have a usage goal
– Every quality requirement should have a system goal
– Every module in the architecture diagram performs a
funcJon in the behavioral view as well

15. System Models: Traceability
• Use case to spec:
15
Use Case
Domain model
Data model
FuncJon / service model
All views
refer to
same
system
model!
à autom.
consistency
CSULB spring 2015 Dr. Birgit Penzenstadler

16. Twin Peaks Model
1. Requirements
2. Architecture
decision
3. Decompose
requirements
into
sub-requirements
and refine again
4. Sub-system architecture decisions