Requirements Engineering - Recap

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

Usage Models
•  DeﬁniDon
•  Use cases
•  Scenarios
•  RelaDon
•  Cockburn template
•  ElaboraDon
Dr. Birgit Penzenstadler 2

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 speciﬁes 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
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

Use cases & Scenarios
•  Def.: A use case is a series of system events
triggered by an actor that leads to results for the
actor.
•  Def.: A scenario is an ordered set of interacDons
between partners, usually a system and a group
of actors.
•  A Usage Model in AMDiRE has three parts:
–  Use Case Overview Diagram („bubble“ diagram)
–  Use Case Templates (one per „bubble“)
–  Scenario diagrams (one per use case template)

Use Case Overview Diagram
[uml-diagrams.org 2010]

Use cases
& Scenarios:
Cockburn
template
•  Use: Use cases and
scenarios complement
each other.
•  Techniques: Structured
text and/or sequence/
interacDon diagrams
•  Elicita/on: iteraDve;
combine scenarios to
tasks, „play out“ task-
speciﬁc scenarios and
analyse

RelaDon: Use Cases and Scenarios
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

DifferenDaDon
•  Sequence diagrams describe interacDons among classes in terms of an
exchange of messages over Dme. Sequence diagrams show a detailed flow
for a specific use case or even just part of a specific use case. They are
almost self explanatory; they show the calls between the different objects
in their sequence and can show, at a detailed level, different calls to
different objects.
•  Ac/vity diagrams illustrate the dynamic nature of a system by modeling
the flow of control from acDvity to acDvity. An acDvity represents an
operaDon on some class in the system that results in a change in the state
of the system. Typically, acDvity diagrams are used to model workflow or
business processes and internal operaDon.
•  Sequence diagram models the sequenDal logic, ordering of messages with
respect to Dme.
•  Ac/vity diagram high-level business processes, including data flow, or to
model the logic of complex logic within a system.

Scaling RE & Refinement
•  Tailoring RE
– Small
– Medium
– Large
•  How to define for a project
•  ConsolidaDon, Refinement and DecomposiDon
•  System models
•  Traceability and Twin Peaks

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

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
& Goals
Constraints
& Rules
!
!
!
!
!
Data Model
E
A
A
A
E
System Vision
Functional
Hierarchy
System
Function Model
Fun 1
Fun 2
Component Model
C C
Data Model
E
A
A
A
E
Behaviour Model
Business Case
System Constraints
Domain Model
Risk List
Project Scope
Glossary
Glossary
Glossary
Process Task
Next Process
A
This has an
associated...Note or
suggestion

Concepts:
DecomposiDon
& reﬁnement
•  DecomposiDon:
How to distribute it
onto subsystems?
•  Reﬁnement:
How to enrich with
more informaDon?
Context Layer
System Layer
Requirements Layer
& Goals
Constraints
& Rules
!
!
!
!
!
Data Model
E
A
A
A
E
System Vision
Functional
Hierarchy
System
Function Model
Fun 1
Fun 2
Component Model
C C
Data Model
E
A
A
A
E
Behaviour Model
Business Case
System Constraints
Domain Model
Risk List
Project Scope
Glossary
Glossary
Glossary

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

RE Tools
•  What to do when having to select tools for
RE?
•  Types of RE tools
•  IEEE Sokware arDcle of tool survey
– How to read such an arDcle
– How to asses tools that weren’t in there

Types of tools
•  General purpose tools
– Oﬃce (natural language documents,
spreadsheets)
– Drawing programs (draw.io, cacoo)
•  Speciﬁc RE tools
– Requirements database tools
– Computer-aided sokware engineering (CASE)
tools
– See IEEE SW arDcle for survey

IEEE SW arDcle:
Requirements Engineering Tools
•  Concise version of research journal arDcle
•  Our goal is to learn
– How to digest such info
– How to understand how it was created
– How to make use of the content
– How to expand on the content
(by assessing addiDonal tools)

ClassiﬁcaDon of non-funcDonal
requirements
•  Quality of a product
•  Dimensions for the classiﬁcaDon of
requirements
•  Examples
•  Challenges with NFRs

ClassiﬁcaDon 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

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

Philosophy
•  AMDiRE concept model based on
system model and quality model
•  Behavior models are in the center for
funcDonal requirements and
quality requirements
Classiﬁca/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
& Goals
Constraints
& Rules
!
!
!
!
!
Data Model
E
A
A
A
E
System Vision
Functional
Hierarchy
System
Function Model
Fun 1
Fun 2
Component Model
C C
Data Model
E
A
A
A
E
Behaviour Model
Business Case
System Constraints
Domain Model
Risk List
Project Scope
Glossary
Glossary
Glossary
important

Overview of relevant Content Items
1.  Process Requirements: Required
characterisDcs of the process/ project
e.g.: Use RUP as process model

2.  Deployment Requirements: Demands
for deployment
e.g.: strategy to be followed for data migraDon

3.  System Constraints: System-related
restricDons that don‘t necessarily
result from funcDonal goals.
E.g.: usage of speciﬁc technologies

4.  Quality Requirements: desired quality
characterisDcs of the system
examples following
21
Context Layer
System Layer
Requirements Layer
& Goals
Constraints
& Rules
!
!
!
!
!
Data Model
E
A
A
A
E
System Vision
Functional
Hierarchy
System
Function Model
Fun 1
Fun 2
Component Model
C C
Data Model
E
A
A
A
E
Behaviour Model
Business Case
System Constraints
Domain Model
Risk List
Project Scope
Glossary
Glossary
Glossary
1
2
3
4
4
important

Template for Assignment
22
Context Layer
System Layer
Requirements Layer
& Goals
Constraints
& Rules
!
!
!
!
!
Data Model
E
A
A
A
E
System Vision
Functional
Hierarchy
System
Function Model
Fun 1
Fun 2
Component Model
C C
Data Model
E
A
A
A
E
Behaviour Model
Business Case
System Constraints
Domain Model
Risk List
Project Scope
Glossary
Glossary
Glossary
1
2
3
4
important
•  3 requirements of each type
•  DescripDon of challenges

Quality models and dealing with NFRs
•  Usage of Quality models in RE
•  Exemplary quality models
•  Dealing with NFRs in AMDiRE

FuncDonal Requirements and Their
Poor Cousins: The Truth About NFRs
•  NFRs are necessary to compleDng the story of the applicaDon. While you might
consider 2 or 3 important NFRs for a project (like performance and security), you’ll
probably not cover the others extensively enough, or you might miss out on them
all together.
•  And if you do allocate Dme to deal with them all, when the project schedule slips,
the NFRs may be the ﬁrst thing you’ll drop… because no one really sees them, and
your team will be looking at the funcDonal requirements instead.
•  So, whether you plan for NFRs or not, chances are high you won’t cover
them 100% of the Dme in your development project. You’ll compromise and not
think of the whole story – the whole applicaDon.
•  But you should try. You should try to avoid adding technical debt and maintenance
nightmares to your future poryolio whenever possible. The cost of change is real,
and the moment you deploy your app, you’ll have to address its problems.
•  From your experience what are the NFRs you constantly see developers
and project teams dropping most oken?

Usage of quality models in RE
25
What are quality models?
à Conceptual models for the descripDon of quality.
•  DeﬁniDon and assessment of sokware quality –
beginning in RE
•  Quality assurance, for example of artefacts in RE
•  Also: ClassiﬁcaDon of requirements according to
characterisDcs

26
Classifica/on on the basis of quality models
•  ClassificaDon of non-funcDon requirements according to
characterisDcs.
–  Which different classes of requirements exist?
–  Which aspects are important to consider?
–  Which modeling concepts and interdependencies are important to
consider?
Delimita/on: Artefact models
•  Ideally build on quality models
(compare to system models)
à Concept model (Content Model)
à Structure of the concept model
(Structure Model)

Artefact-based RE Approach for Business Information Systems (Basic Components)
Structure
Model
Artefact Model
Content
Model
Role Model
Process Model
Tool SupportCustomisation
Approach
MetaModelREReferenceModel
Structure Content
Project-specific
Exemplars
instanceofinstanceof
!
PRODUKT.PROJEKTBEZEICHNUNG - PRODUKT.NAME
Zuletzt geändert: 27.10.2010 13:28 3/20
Content
1! Introduction.......................................................................................................................... 6!
1.1! Overview....................................................................................................................... 6!
1.2! Purpose.......................................................................................................................... 6!
1.3! References..................................................................................................................... 7!
1.4! Scope............................................................................................................................. 8!
2! System Vision ...................................................................................................................... 8!
2.1! Summary of Business Specification.............................................................................. 8!
2.2! Scope of Information System under Consideration ...................................................... 8!
2.2.1! System Overview ................................................................................................... 8!
2.2.2! External Systems.................................................................................................. 10!
2.2.3! Use Case Overview.............................................................................................. 10!
2.2.4! Information System Service Overview ................................................................ 10!
3! Information System Requirements..................................................................................... 11!
3.1! Actors .......................................................................................................................... 11!
3.2! Generic Scenarios........................................................................................................ 11!
3.3! Domain-specific Application Capabilities .................................................................. 12!
3.3.1! <<Business Domain>> <Name>.......................................................................... 12!
3.4! Information System Objects........................................................................................ 14!
3.5! System Quality Requirements..................................................................................... 16!
3.6! Architectural Constraints............................................................................................. 16!
3.6.1! Logical Restrictions.............................................................................................. 17!
3.6.2! Technical Restrictions.......................................................................................... 17!
4! Integrational Requirements ................................................................................................ 18!
4.1! Deployment Requirements.......................................................................................... 18!
4.2! Migration Requirements.............................................................................................. 18!
5! Organisational Requirements............................................................................................. 19!
5.1! Project Requirements .................................................................................................. 19!
5.2! Obligations .................................................................................................................. 19!
5.3! Glossary....................................................................................................................... 19!
6! Abbreviations ..................................................................................................................... 20!
7! References.......................................................................................................................... 20!
Travel Ordering System
Requirements Specification
Version: 0.1
Project Name <Name>
Project Lead <Name>
Responsible <Name>
Created on <Date>
Last changed
X In process
Submitted
State
Completed
Document File
V-Modell XT Version VMRELEASE 1.3with BISA Extension
illustrative
Structure Content
Project-specific
Exemplars
!
Content
1! Introduction.......................................................................................................................... 6!
1.1! Overview....................................................................................................................... 6!
1.2! Purpose.......................................................................................................................... 6!
1.3! References..................................................................................................................... 7!
1.4! Scope............................................................................................................................. 8!
2! System Vision ...................................................................................................................... 8!
2.2.1! System Overview ................................................................................................... 8!
3.1! Actors .......................................................................................................................... 11!
5.2! Obligations .................................................................................................................. 19!
5.3! Glossary....................................................................................................................... 19!
6! Abbreviations ..................................................................................................................... 20!
7! References.......................................................................................................................... 20!
Version: 0.1
Project Name <Name>
Project Lead <Name>
Responsible <Name>
Created on <Date>
Last changed
X In process
Submitted
State
Completed
Document File
illustrative
Structure Content
Project-specific
Exemplars
!
Content
1! Introduction.......................................................................................................................... 6!
1.1! Overview....................................................................................................................... 6!
1.2! Purpose.......................................................................................................................... 6!
1.3! References..................................................................................................................... 7!
1.4! Scope............................................................................................................................. 8!
2! System Vision ...................................................................................................................... 8!
2.2.1! System Overview ................................................................................................... 8!
3.1! Actors .......................................................................................................................... 11!
5.2! Obligations .................................................................................................................. 19!
5.3! Glossary....................................................................................................................... 19!
6! Abbreviations ..................................................................................................................... 20!
7! References.......................................................................................................................... 20!
Version: 0.1
Project Name <Name>
Project Lead <Name>
Responsible <Name>
Created on <Date>
Last changed
X In process
Submitted
State
Completed
Document File
illustrative
Organisational Level
Process Integration
Project Level
Static Tailoring
Dynamic Tailoring
...
Project Scope
defined
System Specification
accepted
...
Business Analyst
...
Requirements
Engineer
Context
Specification
Requirements
Specification
System
Specification

Excursion: Quality models
Quality models
•  Determine which quality aspects and concepts exist and how these are
related
•  Support the structured elicitaDon and modeling of quality requirements
à  E.g. via a taxonomy of quality azributes
Examples:
•  ClassiﬁcaDon acc. to Boehm (1978)
•  IEEE 29148 Sokware Requirements
DocumentaDon Standard (2011)
•  ISO/IEC 9126 (1993, revised 2001)
•  TUM S&SE Quality Model
•  ISO 25010
Challenges:
–  Many diﬀerent quality aspects and
relaDons between them
–  SystemaDcs in their applicaDon in RE
(as well as applicaDon in assessment)
27
[ISO Std.] (Excerpt)

Assessment of quality models
•  Exemplary quality models determine the taxonomy of
quality criteria and azributes

Cri/cal aspects
•  The models oken stay on the abstract level of „-iliDes“
à No statement about measurability and assessment of
quality criteria
•  No direct applicability to RE
–  No clues for explicit deducDon of required system
characterisDcs
Example: The demand for mulD-language documentaDon supports maintainability, but also usability.
–  Other non-funcDonal aspects are oken not covered
28
But: quality models are the basis for the classiﬁca/on of NFRs.

ISO 25010
•  Internal quality: mainly visible in the code, e.g.
reusability of the code within maintainability
•  External quality: mainly characterisDcs that
can be seen from outside the system but not
necessarily by the user
•  Quality in use: perceived by the user of the
system during runDme

Overview: Quality Assurance
•  MoDvaDon and Terminology
•  Quality of Requirements Documents
•  Principles of Quality Assurance
•  Techniques for construcDve QA
•  Techniques for analyDcal QA
K Rayker, stock.xchng

Terminology in the context of quality
assurance in RE
Quality defect
•  Incorrect (invalid) requirement: Requirement that does not reflect the
intenDon of the stakeholder (in the sense of „validity“)
•  Quality defect: Requirement that can be valid, but has qualitaDve defects,
e.g. missing measurability, low understandability, contradictory, ...
•  InterrelaDon of those two:
–  Incorrect requirements are oken hidden due to quality defects
–  Correctness of requirements oken viewed as quality criterium

Valida/on and Verifica/on
•  ValidaDon: Check of requirement w.r.t. correctness (it‘s a valid
requirement, meaning it represents the intenDon of the stakeholder)
•  VerificaDon: Check of system w.r.t. fulfillment of requirements
•  Both are part of QA

Quality Assurance in Requirements
Engineering
•  Def. QA in RE: ApplicaDon of systemaDc measures for
idenDfying quality defects and assuring the quality of the
requirements speciﬁcaDons.
à Check of quality criteria, e.g.:
§  Correctness
§  Completeness
§  Consistency
§  Traceability
§  ... (see following slides)
à The examinaDon can be conducted
construcDve or analyDcal
using a formal procedure.
34

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
& Goals
Constraints
& Rules
!
!
!
!
!
Data Model
E
A
A
A
E
System Vision
Functional
Hierarchy
System
Function Model
Fun 1
Fun 2
Component Model
C C
Data Model
E
A
A
A
E
Behaviour Model
Business Case
System Constraints
Domain Model
Risk List
Project Scope
Glossary
Glossary
Glossary

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
& Goals
Constraints
& Rules
!
!
!
!
!
Data Model
E
A
A
A
E
System Vision
Functional
Hierarchy
System
Function Model
Fun 1
Fun 2
Component Model
C C
Data Model
E
A
A
A
E
Behaviour Model
Business Case
System Constraints
Domain Model
Risk List
Project Scope
Glossary
Glossary
Glossary
Project team
Quality
responsible

ClassificaDon of QA

QA
ConstrucDve
Process
standards
Quality
criteria
LinguisDc
rules
Programming
guidelines
Naming
convenDons
Structuring
convenDons
AnalyDcal
Analyzing
Metrics
Anomaly
analysis
Graphics
TesDng
Dynamic
tests
Review/
inspecDon
Autom. staDc
analysis
Verifying
Formal
verificaDon
Model
checking Dr. Birgit Penzenstadler 37
Note: this is a general
classificaDon of QA, and
not all of it applies to
QA within RE.

Reference Models
•  AMDiRE
•  IEEE 830
•  Cockburn template
•  UML2 standard

Checklist: QuesDons and Criteria for a
spreadsheet with requirements
•  Completeness: Read through, are there sDll open quesDons? Lead
engineer, stakeholder, customer
•  Consistency: Check for requirements conﬂicts
•  Unambiguity: language check, let someone else read it whether it could be
misunderstood
•  Correctness: check with stakeholder
•  Structuredness: adheres to template / outline, has a breakdown that
makes sense
•  Traceability: links between requirements in spreadsheet, across versions
of spreadsheet
•  Changeability: check dependencies between requirements (high degree of
dependencies means low changeability)
•  Understandability: let someone else read it whether it‘s easy to
understand
•  Agreed upon: check with stakeholder

39

LinguisDcs in RE
•  ClassiﬁcaDon 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

IEEE 730 – 2014: IEEE Standard for
Sokware Quality Assurance Processes

Overview: Change & Risk Management
•  Recap: Requirements Management
•  Change Management
•  Risk Management

Recap: RE in the process
ValidaDon
Traceability
Matrix
Plan, decide, manage risks, manage changes
Risk & Status
Report
Project management
Requirements Management
Analysis
ElicitaDon
DocumentaDon

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 VeriﬁcaDon
–  Change management and Impact Analysis
–  Version management
–  ConﬁguraDon management
–  Claim management
–  Support for distributed RE
–  Tool support for RM

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

Managing requirements
•  Big projects may have thousands of requirements
•  For management, the standard process is
1.  All are submized to a database
2.  And managed via their azributes
3.  For the respecDve milestone, requirements are
decided upon („Freeze“ / „Baseline“)
4.  And oken gathered in a document for oﬃcial
approval
à Aker this oﬃcial approval, further changes have
to adhere to a standardized change process
46

Change Management – how?
Four steps
•  SystemaDc elicitaDon of Change Requests
•  Decision on priority and costs
•  Decision on implementaDon
•  ImplementaDon of changes

Important related tasks:
•  Impact analysis: What consequences do changes have?
•  Version management: Which versions of requirements exist?
•  ConﬁguraDon management: Which requirements form consistent
baselines?
•  Defect management: How to deal with defects and their
correcDon?
47

Change Management – how?
Status of Requirement
K Rayker, stock.xchng
Proposed
Assumption
Validated
Applied
Tested
Denied
ReleasedAccepted
Designed Implemented
[Information System
Requirements]
[Other]
New Req

Risk Management
www.pharmadirecDons.com

SWOT analysis

Dr. Birgit Penzenstadler 50 CSULB spring 2015

Root-cause analysis
•  (Strengths,
weaknesses,
opportuniDes,
threats)
•  Root-cause
analysis
Dr. Birgit Penzenstadler 51 CSULB spring 2015

Project plan: What to deﬁne?
Infrastructure plus project content.
Process Task
Next Process
A
This has an
associated...Note or
suggestion
Process
model
AcDviDes/ Methods ArDfacts
Tools Roles
Milestones

Sounds familiar?
Guess what… arDfacts!
Context Layer
System Layer
Requirements Layer
& Goals
Constraints
& Rules
!
!
!
!
!
Data Model
E
A
A
A
E
System Vision
Functional
Hierarchy
System
Function Model
Fun 1
Fun 2
Component Model
C C
Data Model
E
A
A
A
E
Behaviour Model
Business Case
System Constraints
Domain Model
Risk List
Project Scope
Glossary
Glossary
Glossary

Let’s do it: Budget
It’s spreadsheet o’clock!!
1.  (EsDmaDon of required hardware)
2.  (EsDmaDon of required sokware)
3.  EsDmaDon of development work

Sokware pricing
•  EsDmates are made to discover the cost, to the
developer, of producing a sokware system.
–  You take into account, hardware, sokware, travel,
training and eﬀort costs.
•  There is not a simple relaDonship between the
development cost and the price charged to the
customer.
•  Broader organisaDonal, economic, poliDcal and
business consideraDons inﬂuence the price
charged.
55
Ian Sommerville, Sokware Engineering, 9th EdiDon

Then: Define for Project Management
•  Change Management
•  Risk Management
• ValidaDon & verificaDon
• Version & configuraDon management
• Claim management
• Support for distributed RE

Hot research topics in RE
•  Paper by Nuseibeh and Easterbrook, 2000

•  Update paper by Cheng and Atlee in 2007

Nuseibeh & Easterbrook:
Decade 1990-2000 (before publicaDon)
During 1990-2000, we can discern the emergence of three radical new ideas that
challenged and overturned the orthodox views of RE. These three ideas are closely
interconnected:
•  The idea that modelling and analysis cannot be performed adequately in isolaDon
from the organisaDonal and social context in which any new system will have to
operate. This view emphasised the use of contextualised enquiry techniques,
including ethnomethodology and parDcipant observaDon [29; 63].
•  The noDon that RE should not focus on specifying the funcDonality of a new
system, but instead should concentrate on modelling indicaDve and optaDve
properDes of the environment 2 [84] . Only by describing the environment, and
expressing what the new system must achieve in that environment, we can
capture the system’s purpose, and reason about whether a given design will meet
that purpose. This noDon has been accompanied by a shik in emphasis away from
modelling informaDon ﬂow and system state, and towards modelling stakeholders’
goals [15] and scenarios that illustrate how goals are (or can be) achieved [51].
•  The idea that the azempt to build consistent and complete requirements models
is fuDle, and that RE has to take seriously the need to analyse and resolve
conﬂicDng requirements, to support stakeholder negoDaDon, and to reason with
models that contain inconsistencies [28].

N&E’s PredicDon for 2000-2010
•  Development of new techniques for formally
modelling and analysing properDes of the environment
•  Bridging the gap between requirements elicitaDon
approaches based on contextual enquiry and more
formal speciﬁcaDon and analysis techniques.
•  Richer models for capturing and analysing non-
funcDonal requirements.
•  Bezer understanding of the impact of sokware
architectural choices on the prioriDsaDon and
evoluDon of requirements.
•  Reuse of requirements models.
•  MulDdisciplinary training for requirements
pracDDoners.

Cheng & Atlee:
Hot topics
•  Scale
•  Security
•  Tolerance
•  Increased Reliance on Environment
•  Self-Management
•  GlobalizaDon
•  Methodologies, pazerns, and tools
•  Requirements Reuse
•  EﬀecDveness of RE technologies

Misuse cases (Sindre & Opdahl)

Cheng & Atlee: Five recommendaDons
… that the RE community could take immediate acDon on, to
start improving the maturity of current requirements
technologies:
•  Researchers should work with pracDDoners.
•  RE researchers should work with other SE researchers and
pracDDoners, to establish stronger links between their
respecDve arDfacts.
•  RE researchers should not neglect evaluaDon and empirical
research.
•  Industrial organizaDons should provide (saniDzed)
industrial-strength project data to researchers.
•  RE researchers and pracDDoners, together, should establish
repositories of RE arDfacts.

Requirements Engineering - Recap

More Related Content

What's hot (20)

Similar to Requirements Engineering - Recap (20)

More from Birgit Penzenstadler (19)

Recently uploaded (20)

Requirements Engineering - Recap