20th and last slide set of CECS 542
Recap of the 2nd half of the semester for preparing for the final
Complete course: http://foss2serve.org/index.php/Requirements_Engineering,_CSU_Long_Beach,_Penzenstadler
1. Requirements Engineering
Recap for the final
CECS 542
Please look at all the slides from the second half of the semester;
this is just a summary of the more important points and concepts.
Photo credit: Andrew Preble, Unsplash
Dr. Birgit Penzenstadler
3. Usage Model
• Def.: A usage model describes the
system behavior from the point of
view of the user („Black box“) by
modeling interacDon sequences.
• It specifies the use cases
(from the system vision)
• Why? Understanding of intended
uses by means of the system.
• NotaDons:
– Use case overview diagram
– Structured text (templates)
– UML acDvity diagrams
– Message Sequence Charts
Dr. Birgit Penzenstadler 3
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. RelaDon: Use Cases and Scenarios
Dr. Birgit Penzenstadler 7
Use Case
Scenario
(1) (2)
• For each „bubble“ in the overview diagram:
• Use Cases summarize a set of scenarios to a
specific usage of the system.
– Use Case:
Task, objecDve, causal relaDon (pre- and
post-condiDons)
– Scenario:
Sequence of Events (steps, events,
interacDon)
Itera/ve Elabora/on
(compare to refinement and abstracDon of
goals in the earlier lecture)
(1) Cluster scenarios to tasks
(2) Elicit task-specific scenarios,
analyse and walk through them
10. Main Factors for Tailoring RE
• Project sejng: Project size, budget size, Dme constraints, number of people,
overall sokware development process
• Knowledge
– Level of understanding of the problem domain
– Level of understanding of the applicaDon domain
– Skills of the developers
– New team versus well acquainted and pracDced
• Stakeholders
– Availability of stakeholders
– RelaDonship to stakeholders
– Types of stakeholders (especially moDvaDon)
• Type of system
– Business informaDon system, embedded system, cyber-physical system, web service
– New product versus well established product
– Viability and technical feasibility
– Maturity of underlying technology
• System characterisDcs, e.g.:
Relevance of safety, security, robustness, dependability, etc.
• Business & legal concerns:
Legality, ethical concerns, patents, licenses, standards
Birgit Penzenstadler
11. 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 characterisDcs 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
arDfacts 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
12. Concepts:
DecomposiDon
& refinement
• DecomposiDon:
How to distribute it
onto subsystems?
• Refinement:
How to enrich with
more informaDon?
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
18. ClassificaDon of requirements:
Dimensions
1. FormalisaDon
2. Degree
of abstracDon
3. QualitaDve and quanDtaDve
4. FuncDonal, non-funcDonal
à Choice of degree of precision
– For making
qualitaDve/quanDtaDve
statements
– For classifying requirements
into funcDonal/non-funcDonal.
Example
• The system is easy to use!
– FuncDonal/qualitaDve implementaDon: The system shall have a help func4on
that provides the user with support at any 4me.
– Non-funcDonal/quanDtaDve: The typical user understands the system a9er 10
minutes of training.
18
QualitaDve
QuanDtaDve
informal formal
abstract
concrete
Abstract
requirements
Formal, abstract
requirements
Concrete
requirements
Formal, concrete
requirements
important
19. Summary: 3 challenges
1. Crosscujng Concerns: qualitaDve/quanDtaDve statements
– ParDally w.r.t. funcDonality (e.g. performance)
– ParDally across funcDonality (e.g. maintainability)
2. ElicitaDon, assessment and evaluaDon
– Oken general wish w.r.t. characterisDcs, but not concrete
– No statement to which extent the characterisDc must be present
– Requirements (and implementaDon) possible on different levels of
abstracDon with different concepts (and expressivity)
– AbstracDon levels influence modeling concepts and characterisDcs (as
well as interdependencies), and therefore also the classificaDon
3. ClassificaDon of non-funcDonal requirements
– Depends on the underlying quality model
– Depends on the underlying system model and modeling concepts
19
important
20. Philosophy
• AMDiRE concept model based on
system model and quality model
• Behavior models are in the center for
funcDonal requirements and
quality requirements
Classifica/on of NFRs
• Process Requirements
• Deployment Requirements
• System Constraints
• Quality Requirements
Structured elicita/on of
quality requirements
• From system goals
• To scenarios
• To quality requirements
20
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
important
22. Template for Assignment
22
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
1
2
3
4
important
• 3 requirements of each type
• DescripDon of challenges
35. Focus of quality assurance in RE
PerspecDves in QA in RE
• We disDnguish the quality of
– Requirements documents / artefacts
– Sets of requirements / statements
– Individual requirements
– Systems
35
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
36. Analytical QS
Depending on the quality criteria, responsible for checking are:
• Project team members with domain knowledge during elaboraDon of the
requirements, e.g. „correctness“ à this is called construcDve QA
• External/neutral quality responsibles who perform checks, e.g.
„traceability“ and „understandability“ à this is called analyDcal QA
à Which measures can you think of for performing either of these?
Constructive QS
Principle of construcDve and analyDcal QA
36
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
Project team
Quality
responsible
40. LinguisDcs in RE
• ClassificaDon of linguisDc quality defects
– Lexical/ontological (what does „green“ mean?)
– SyntacDc (“I saw the man on the hill with a telescope”)
– SemanDc (“All persons have a unique naDonal insurance
number“)
– PragmaDc (“The trucks shall treat the roads before they freeze“)
– Weak phrases: (“as soon as possible“)
– Omission or generalizaDon
• Syntax pazerns
– [when?] [under what condiDons?]
THE SYSTEM SHALL | SHOULD | WILL
<process> <thing to be processed> [<process detail>*]
40
44. Requirements Management: Tasks
44
• RaDonale Management and Traceability
– RaDonale for requirements
– RelaDon between content items
• Management of the requirements
– Structuring, documentaDon and archiving
– AzribuDon
• Interdependency with other management tasks
– ValidaDon and VerificaDon
– Change management and Impact Analysis
– Version management
– ConfiguraDon management
– Claim management
– Support for distributed RE
– Tool support for RM
45. Recap: Azributes for requirements
• ID
• DescripDon
• Owner
• Stakeholder
• Source
• RaDonale
• State
• Accceptance Criterion
• Time Constraint
• Priority
à Make sure all of these are updated in the change process
45
53. Sounds familiar?
Guess what… arDfacts!
Dr. Birgit Penzenstadler 53
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