Modelling Software Requirements: Important diagrams and templates (lecture slides)

D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Modelling Software
Requirements
–Important diagrams and templates–
Prof. Dr. Dagmar Monett Díaz
Computer Science Dept.
Faculty of Cooperative Studies
Berlin School of Economics and Law
dagmar@monettdiaz.com
Europe Week, 2nd – 6th March 2015
120 Minutes

Dilbert
 Scott Adams
At http://dilbert.com/strip/2000-02-27/
(Educational/Classroom usage permission is granted by Universal Uclick. All Rights Reserved)
Oh, my, diagrams…
2

D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 3
Main topics

Main topics
 Where does the major content come from?
 Requirements Engineering and Requirements
Development: An Overview
 Why using visual models?
 The Requirements Modelling Language (RML)
- Objectives, People, Systems and Data Models
 The Unified Modelling Language (UML)
- Most used UML diagrams
 What’s next? Further reading, sources of inspiration

Next topics…

©

Visual Models for
Software Requirements
Joy Beatty and Anthony Chen
1st Edition, 480 pp.
Microsoft Press, 2012
ISBN-13: 978-0-7356-6772-3
(See more at
https://www.microsoftpressstore.com/store/vis
ual-models-for-software-requirements-
9780735667723)
7
Wiegers & Beatty

Software Requirements
Karl Wiegers and Joy Beatty
3rd Edition, 672 pp.
Microsoft Press, 2013
ISBN-13: 978-0-7356-7966-5
(See more at
http://aka.ms/SoftwareReq3E/files)
8
Wiegers & Beatty

Software Engineering
Ian Sommerville
9th Edition, 792 pp.
Addison-Wesley, 2010
ISBN-13: 978-0137035151
(10th Edition: April 2015. See more at
http://iansommerville.com/software-
engineering-book/)
9
Sommerville

The traditional software
development process:
Perceptions, communication patterns
and interests…

D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 11Cartoon  http://projectcartoon.com/

Requirements and
Requirements Engineering
– An Overview –

A requirement is…
According to Wiegers & Beatty:
“[A requirement is a] statement of a
customer need or objective, or of a condition
or capability that a product must possess to
satisfy such a need or objective. A property
that a product must have to provide value to
a stakeholder.”
See lecture “A Structured Approach to Requirements Analysis” for more on this topic!

Definition according to Wiegers & Beatty:
Requirements engineering is the subdiscipline of
systems engineering and software engineering that
encompasses all project activities associated with
understanding a product's necessary capabilities and
attributes. Includes both requirements development
and requirements management.
15

Subdisciplines of

Subdisciplines of
Requirements
Engineering
Requirements
Development
Requirements
Management
Acc. to Wiegers & Beatty

Subdisciplines of
Requirements Development
Elicitation
Requirements
Engineering
Analysis Specification Validation
Requirements
Development
Requirements
Management

Subdisciplines of
Requirements Management
Tracking
Requirements
Engineering
Managing Controlling Tracing
Requirements
Development
Requirements
Management

Topics of other related lectures

Subdisciplines of
Elicitation
Requirements
Engineering
Requirements
Development
Requirements
Management
All are topics of lecture:
“A Structured Approach to Requirements Analysis”

Subdisciplines of
Requirements
Engineering
Requirements
Development
Requirements
Management
Elicitation Analysis Specification Validation
Topic of lecture
“Requirements Engineering Techniques for Eliciting Requirements”

Subdisciplines of
Requirements
Engineering
Requirements
Development
Requirements
Management
Elicitation Specification Validation
Topics of lecture
“Requirements Engineering Methods for Documenting Requirements”
Analysis

Subdisciplines of
Requirements
Engineering
Requirements
Development
Requirements
Management
Topic of (this) lecture
“Modelling Software Requirements. Important diagrams and templates”

Subdisciplines of
Requirements
Engineering
Requirements
Development
Requirements
Management
Topic of lecture
“Methods for Validating and Testing Software Requirements”

A Requirements Development
process framework

Subdisciplines of
Elicitation
Requirements
Engineering
Requirements
Development
Requirements
Management

RD process framework
28
Elicitation
Analysis
Specification
Validation
re-evaluate
Adapted from Wiegers & Beatty
identifying, discovering
evaluating,
verifying
documenting, SRS
classifying,
representing,
deriving,
negotiating
RD: Requirements Development
SRS: Software Requirements Specification
See lecture “A Structured Approach to Requirements Analysis” for details!

A structured approach to

A structured approach to RD
(1) Define stakeholders!
 Who is interested in the system?
 Who makes decisions?
 Who are the users, managers, developers, etc.?
In other words, WHO has influence on the software requirements?
(2) Define goals!
 Stakeholders have goals (define coarse goals!)
 These goals can be divided into more specific goals (define granular goals!)
In other words, WHAT should be implemented or achieved?
(3) Define requirements!
 Goals can be derived into concrete requirements
 How to get to the requirements? (goal-based!)
 Model those requirements using diagrams, templates, etc.
In other words, HOW will the goals be achieved?

Granular goals
CG3
CG2
CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
Diagrams
Templates
Models
WHO
WHAT
HOW
See lecture “A Structured Approach to Requirements Analysis” for details!

Requirements Specification

33
Elicitation
Analysis
Specification
Validation
re-evaluate
evaluating,
verifying
documenting, SRS
classifying,
representing,
deriving,
negotiating

34
Elicitation
Analysis
Specification
Validation
re-evaluate
evaluating,
verifying
documenting, SRS
classifying,
representing,
deriving,
negotiating

Specification: Definition
35
Specification
“[Specification is the] process of documenting a
software application's requirements in a
structured, shareable, and manageable form.
Also, the product from this process.”

Granular goals
CG3
CG2
CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
Diagrams
Templates
Models
WHO
WHAT
HOW
classifying,
representing,
deriving,
negotiating
documenting, SRS
+
+
evaluating, verifying
+

Key actions in specification

Key action
38
Specification
Translating the collected user needs into written
requirements and diagrams suitable for
comprehension, review, and use by their intended
audiences.

So far…

Next topics…

Why using visual models?

 A picture is worth a thousand word!
 Communicating certain type of information more efficiently.
 As a means of facilitating discussion about an existing or
proposed system
- Incomplete and incorrect models are OK as their role is to support
discussion.
 As a way of documenting an existing system
- Models should be an accurate representation of the system but need
not be complete.
 As a detailed system description that can be used to generate
a system implementation
- Models have to be both correct and complete.
Acc. to Sommerville

Requirements Modelling Language
(RML)

Requirements Modelling
Language
 RML® – to visually model requirements
 RML focuses on specifying needs, rather than
solution designs.
 It looks at a project’s goals and objectives.
 It uses models to break down these objectives into
requirements which are easily understood by both
business stakeholders and developers.
 The RML models can be used as a starting point for
many of the models within UML and SysML.
According to Seilevel @ http://www.seilevel.com/ba-resources/rml-requirements-visual-models/

RML classification of models

RML Model categorisation
According to Beatty & Chen
O
P
S
D
OPSD classification of RML models
Objectives of the solution
People who are using the solution
Systems themselves
Data that is being processed

RML Objectives Models

O
P
S
D
“Describe the business
value of the system and
help prioritise features
and requirements based
on their value.”

O
P
S
D
 Business Objectives Model
 Objective Chain
 Key Performance Indicator Model
 Feature Tree
 Requirements Mapping Matrix

Business Objective Model

Business Objective Model
51
“The Business Objective Model (BOM) is
created to document a project’s value [for the
end users and] for the company creating it.”
According to Beatty & Chen:
(© Seilevel. See more at
http://www.seilevel.com/ba-resources/rml-requirements-visual-
models/business-objective-model/ )

BOM Template
RML® model created by Seilevel http://www.seilevel.com/

BOM Template
Measurable target that
specifies when the
business problem is solved
Vision, product
concept to solve
the business
problem
It measures whether the
business objective or the
solution is successful or not
Issue preventing the
business from
achieving its goals
pair

BOM Example
“Executives at a printer company
evaluate their financial success”

Feature Tree

Feature Tree
56
“Feature Trees are high-level models organizing
features into feature groups, capturing the entire
scope of a project into a single model. They
show the relationships between features”
models/feature-tree/)

Feature Tree Template

Feature Tree Template
Levels of detail:
highest level features (L1),
mid-level features (L2),
and low-level features (L3)
This is a subfeature
This is a main feature
A “fishbone”
diagram
The product
concept being
developed

Feature Tree Example
“Content access at a training organisation’s portal”

Dilbert
 Scott Adams
At http://dilbert.com/strip/2013-02-25/
(Educational/Classroom usage permission is granted by Universal Uclick. All Rights Reserved)
Features in teamwork…
60

RML People Models

RML People Models
O
P
S
D
“Describe who is using
the system along with
their business processes
and goals.”

RML People Models
 Organisation Chart
 Process Flow
 Use Case
 Roles and Permissions Matrix
O
P
S
D

Organisation Chart

Organisation Chart
65
“An Org Chart is a collection of boxes
connected by lines with a hierarchical structure.”
models/organization-charts/ )

Organisation Chart Template

Organisation Chart Template
Organizational group name,
role or individual person
Hierarchical reporting relationships
within the organisation

Organisation Chart Example
“Individual Org Chart for an automobile
manufacturing organisation”
VP: Vice-President; IT: Information Technology; QA: Quality-Assurance; BA: Business Analyst

Use Case template, use case
diagram, and use case scenario

Use Case
70
“A Use Case is a people model that describes
the interactions between the actors and a
system. The value of a use case is that it helps
users picture themselves executing a task,
allowing them to identify the features that might
be required to support each step.”
models/use-cases/ )

Use Case Template

Use Case Template
Headerfields
Userinteractions
withthesystem

How to identify actors?
 Who (or what) is notified when something occurs within the
system?
 Who (or what) provides information or services to the
system?
 Who (or what) helps the system respond to and complete a
task?
According to Joy Beatty
Actors:
persons, actual people (stakeholders),
but also another software system,
or a hardware device.

Sample Use Cases
Application: Airport check-in kiosk
Check in for a flight
Print boarding passes
Change seats
Check luggage
Purchase an upgrade
Application: Online bookstore
Update customer profile
Search for an item
Buy an item
Track a shipped package
Cancel an unshipped order
<action> + <object>

Example: Patient information system
Adapted from Ian Sommerville’s book
Register
patient
View
personal info
View
record
Edit
record
Setup
consultation
Export
statistics
Generate
reportMedical
receptionist
Nurse
Manager
Doctor

Example: Patient information system
Register
patient
Unregister
patient
View
personal info
Transfer
data
Contact
patient
Medical
receptionist
Other use cases that involve the Medical receptionist:

Use case modelling
Single use case of the Patient Management System:
Transfer
data
Medical
receptionist
Patient
record system

Transfer
data
78
Use case modelling
Medical
receptionist
Patient
record system
Message pass in both directions
but the Medical receptionist
initiates the transaction
Also used to represent external
systems and hardware (and not
only human interaction)
There are two actors that
interact with the system
This is the task that involves
the external interaction, i.e.,
the use case
Single use case of the Patient Management System:

Use case modelling
Transfer
data
Medical
receptionist
Patient
record system
Name Transfer data
Description A receptionist may transfer data (patient’s personal information,
treatment summary) from the Patient Management System to a
general patient record database.
Actors Medical receptionist, Patient record system.
Frequency of use Every time the patient’s information is updated.
Triggers User command issued by medical receptionist.
… …

How to identify Use Cases?
 What functions will the actor want from the system?
 Does the system store information?
 Do the actors need to create, update, or delete information?
 Does the system need to notify an actor about changes in an
internal state?
 Are there any external events the system must know about?
 What is the actor’s overall job?
 What problems has the actor had in the past?
 What steps are manual today?

Use case scenario
 A scenario is “a real-life example of how a system can be
used.”
 …“an instance of a use case” (Wiegers & Beatty).
 …“a single thread through the use case.”
 …a normal flow but also alternative flows and exceptions.
 It should include:
- A description of the starting situation;
- A description of the normal flow of events;
- A description of what can go wrong;
- Information about other concurrent activities;
- A description of the state when the scenario finishes.
According to Ian Sommerville

Example of usage scenario
“Setup consultation allows two or more doctors, working in
different offices, to view the same record at the same time.
One doctor initiates the consultation by choosing the
people involved from a drop-down menu of doctors who
are on-line. The patient record is then displayed on their
screens but only the initiating doctor can edit the record. In
addition, a text chat window is created to help coordinate
actions. It is assumed that a phone conference for voice
communication will be separately set up.”

Normal and alternative flows
Step 1
Step 2
Step 3
Step 4
Step 3a
Step 3b
Step 3c
(use case preconditions)
(use case postconditions)
(branch condition)
(continuation condition)
Normal flow Alternative flow
Activitydiagram!

How to identify alternatives?
 Is there some other action that can be chosen?
 If X does not happen, then what should happen?
 What if the actor cancels an operation (e.g., closes a
window)?
 What if the actor provides incomplete information?
 What might go wrong at this step?
 What if part of the system goes down or is unavailable?
 Are there any events (or interrupts) that might occur at any
time during the use case?

Active learning exercise
Image © renjith krishnan at http://www.freedigitalphotos.net/

Quiz
86
(Taken from the public Examination Questionnaire Set © IREB,
International Requirements Engineering Board e.V.)
What is not depicted in a use case diagram?
(A) The actors of an application.
(B) The use cases of an application.
(C) An application’s functionality.
(D) The process steps of an application.

RML Systems Models

RML Systems Models
O
P
S
D
Systems themselves
“Describe what systems
exist, what the user
interface looks like, how
the systems interact, and
how they behave.”

RML Systems Models
 Ecosystem Map
 System Flow
 User Interface Flow
 Display-Action-Response
 Decision Table
 Decision Tree
 System Interface Table
O
P
S
D

User Interface Flow

User Interface Flow
91
“User Interface Flows show graphically how a
user will navigate a solution’s user interface.
They are system models that show how
different pages (screens) of a user interface
are connected and how a user can step
through various pages of the system
(navigation paths).”
models/user-interface-flow/ )

User Interface Flow Template

User Interface Flow Template
Screens (UI pages)
Directional arrow that
orders the navigation
path between screens
Action
Smaller section to ease
readability when
common functionality

User Interface Flow Example
“UI flow for a trivia system in which users
take quizzes with trivia questions”

Decision Tree
and Decision Table

Decision Tree
96
“The Decision Tree shows complex logic,
allowing you to analyze a series of decisions. It
is significantly easier to validate the logic
visually in a Decision Tree than by describing
the logic in a list of statements.”
models/8386-2/ )

Decision Tree Template

Decision Tree Template
Conditions, phrased
as questions
Possible values. Answers to the
questions asked in the decision
Expected outcomes
or behaviours of the
system. The result
of taking a decision
choice pathway

Decision Tree Example
“An insurance company’s process
to determine eligibility for home
insurance policies”

Decision Table
100
“A Decision Table helps you to analyze all the
permutations of complex logic in a
comprehensive way. They are used if there is
no specific order to evaluating the decisions. If
the decisions need to be made in any kind of
order, a Decision Tree should be used instead.”
models/8445-2/ )

Decision Table Example
 It answers the question “Under what conditions will an outcome occur?”
 Or “Given these conditions, what outcome should I choose?”

Decision Table Example
This decision table shows the same logic as in the Decision Tree Example
Irrelevant outcome Outcome applies when
the choices are valid
Combination
of choices

RML Data Models

RML Data Models
O
P
S
D
“Describe the relationships
between business data
objects from an end-user
perspective, the life cycle of
the data, and how the data
is used to make decisions.”

RML Data Models
 Business Data Diagram
 Data Flow Diagram
 Data Dictionary
 State Table
 State Diagram
 Report Table
O
P
S
D

Data Flow Diagram

Data Flow Diagram
107
“A Data Flow Diagram […] shows a visual
representation of the flow of information
through systems, data stores, and actors,
focusing on how data changes or is used
through processes.”
models/data-flow-diagrams/ )

Data Flow Diagram Template

Data Flow Diagram Template
Internal to and
manipulated
by the system
Data being
placed into
the store
A read
operation
How data
moves, flows
through the
system
Data flow
Processes
communicate
through data
stores
Also
terminator

Data Flow Diagram Example
“How data flows
in an order
placement
system”

State-Transition Diagram
and State Table

State Diagram
112
“State Diagrams are data models that show
the changes between states of business data
objects in the system. They show the cycle of
an object’s states, including events that trigger
changes in state. They only show transitions,
triggers, and the flow of the changes.”
models/state-diagrams/ )

State Diagram Template

State Diagram Template
Final state
Initial state
A possible
system state
Allowed state
change
Event or
condition that
causes a change
or transition

State Diagram Example
“A loan
application
system”

State Table
116
“A State Table is a data model used to identify
all states and all possible single step changes
between the states for a business data object.
A state describes the stage of a business data
object’s lifecycle. Object’s states must be
unique and the object has to be in one of the
states at all times.”
models/state-tables/ )

State Table Example

State Table Example
All possible transitions between states in the form of a matrix.

So far…

Quiz
121
Which RML models apply to the following definition:
“They describe who is using the system along with their
business processes and goals.”?
(A) People models.
(B) System models.
(C) Data models.
(D) Objectives models.

Next topics…

Unified Modelling Language
(UML)

“The Unified Modelling Language™ - UML - is OMG's
most-used specification, and the way the world models
not only application structure, behaviour, and architecture,
but also business process and data structure.”
OMG is a not-for-profit computer industry specifications consortium
UML® Resource Page: http://www.uml.org/
UML®

UML®
 Unified Modelling Language.
 The standard object-oriented modelling language.
 Current standard: v. 2.4.1 (August 2011)
 Originally, Unified Method (1995)
 Roots:
- OMT: Object-Modelling Technique (Booch)
- OODA: Object-Oriented Domain Analysis (Rumbaugh)
- OOSE: Object-oriented Software Engineering (Jacobson)

Most used UML diagrams

UML®
 Activity diagrams, which show the activities involved in a
process or in data processing.
 Use case diagrams, which show the interactions between a
system and its environment.
 Sequence diagrams, which show interactions between
actors and the system and between system components.
 Class diagrams, which show the object classes in the
system and the associations between these classes.
 State diagrams, which show how the system reacts to
internal and external events.
Process model

Example of activity diagram
Adapted from Booch, Rumbaugh & Jacobson
set up
order
assign
seats
[single order]
[subscription]
assign
seats
debit
account
award
bonus
mail
packet
charge
credit card

Example of activity diagram
set up
order
end of activity, completion
activity node
(action)
decision (branch)
assign
seats
[single order]
[subscription]
guard condition
synchronisation bar
(concurrent fork)
initiation
assign
seats
debit
account
award
bonus
mail
packet
charge
credit card
alternative threads
concurrent
threads
synchronisation bar
(concurrent join)
merge (unbranch)

UML®
Interaction model

Example of sequence diagram
:Kiosk ticketServer:Server :CreditService
insertCard(customer)
pickDate(date)
offer(seatChoice)
select(seats)
submit(order) charge(customer,
amount)
authorise
ok
print(order)
sd BuyTickets
destroy()

Example of sequence diagram
:Kiosk ticketServer:Server :CreditService
insertCard(customer)
pickDate(date)
offer(seatChoice)
select(seats)
submit(order) charge(customer,
amount)
authorise
ok
print(order)
return message,
dotted line
lifeline
time
sd BuyTickets
anonymous objectobject instance
execution
specification
parameter
synchronous
message
destroy()
asynchronous
message
outside
environment
object
destruction
externalmessage
point(gate)
name

UML®
Structural model

UML®
Event-driven model

Example of state diagram
set
Idle
Confirming
Selling
entry / sell ()
identifyUser: Identifying
Selecting
pick(seat) / add to selection (seat)
Purchasing
exit / eject card
insert card
push “cancel”
push “resume” push “buy”
push “confirm”
/ reset selection
fail

Example of state diagram
set
Idle
Confirming
Selling
entry / sell ()
identifyUser: Identifying
Selecting
pick(seat) / add to selection (seat)
Purchasing
exit / eject card
insert card
push “cancel”
push “resume” push “buy”
push “confirm”
/ reset selection
failinitial
state
internal
transition
final
state
explicit
exit
normal
exit
event
entry
activity
completion
transition
completion
transition
parameter
event
outer
transition
aborts
internal
activity
simple state
action
composite
state
transition
submachine state reference
exit point
exit
activity
state name

So far…

Quiz
140
(Adapted from the public Examination Questionnaire Set © IREB,
International Requirements Engineering Board e.V.)
The management of a company hires a software engineer (you) to
specify and develop a new e-commerce system. During initial
discussions with different representatives of the customer you find the
following: your main contact person described her ideas by telling you
the expected interactions between specialists and the e-commerce
system in the form of different flows of user actions and system
reactions. Which approach is particularly well suited to elicit and
document the requirements in this case?
(A) Creating an organisation model.
(B) Creating a use case diagram and documenting the use cases.
(C) Creating a data flow model.
(D) Creating a features tree.

Next topics…

To take away…

 A picture is worth a thousand word!
 Communicating certain type of information more efficiently.
 As a means of facilitating discussion about an existing or
proposed system
- Incomplete and incorrect models are OK as their role is to support
discussion.
 As a way of documenting an existing system
- Models should be an accurate representation of the system but need
not be complete.
 As a detailed system description that can be used to generate
a system implementation
- Models have to be both correct and complete.
Acc. to Sommerville

RML Model categorisation
O
P
S
D
Systems themselves

Use case modelling
Transfer
data
Medical
receptionist
Patient
record system
Name Transfer data
Description A receptionist may transfer data (patient’s personal information,
treatment summary) from the Patient Management System to a
general patient record database.
Actors Medical receptionist, Patient record system.
Frequency of use Every time the patient’s information is updated.
Triggers User command issued by medical receptionist.
… …

What comes next?

Subdisciplines of
Requirements
Engineering
Requirements
Development
Requirements
Management
Topic of lecture
“Methods for Validating and Testing Software Requirements”

148
Elicitation
Analysis
Specification
Validation
re-evaluate
evaluating,
verifying
documenting, SRS
classifying,
representing,
deriving,
negotiating

Granular goals
CG3
CG2
CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
Diagrams
Templates
Models
WHO
WHAT
HOW
classifying,
representing,
deriving,
negotiating
documenting, SRS
+
+
evaluating, verifying
+

Other references

Booch, Rumbaugh & Jacobson
151
The Unified Modeling
Language User Guide
Grady Booch, James Rumbaugh
and Ivar Jacobson
2nd Edition, 496 pp.
Addison-Wesley Professional, 2005
ISBN-13: 978-0321267979

Rumbaugh, Jacobson & Booch
152
The Unified Modeling
Language Reference Manual
James Rumbaugh, Ivar Jacobson
and Grady Booch
2nd Edition, 721 pp.
ISBN-13: 978-0321718952

Cockburn
153
Writing Effective Use Cases
Alistair Cockburn
ISBN-13: 978-0201702255
(See http://alistair.cockburn.us/get/2465)

Bittner & Spence
154
Use Case Modeling
Kurt Bittner, Ian Spence
ISBN-13: 978-0201709131

Requirements-Engineering
und -Management: Aus der
Praxis von klassisch bis agil
Chris Rupp & die SOPHISTen
6th Edition, 570 pp.
Carl Hanser Verlag München, 2014
ISBN-13: 978-3-446-43893-4
In German
(Chapters and related topics in English are
available for free at https://www.sophist.de/)
155
Rupp & The SOPHISTs

Further reading
 IREB - International Requirements Engineering
Board e.V.
http://www.ireb.org/en/service/downloads.html
156

Conference sites…
 21st International Working Conference on
Requirements Engineering: Foundation for Software
Quality (REFSQ 2015), Essen, Germany
http://refsq.org/2015/
157

Conference sites…
 23rd IEEE International Requirements Engineering
Conference (RE’15), Ottawa, Canada
http://re15.org/
158

Homework:
“Model software requirements
of your current course projects
using visual models from RML !”

The traditional software
development process:
and interests…

The ideal, perfect, still possible
software development process:
and interests…

D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 163Adapted from cartoon  http://projectcartoon.com/

Done!

Modelling Software
Requirements
–Important diagrams and templates–
Prof. Dr. Dagmar Monett Díaz
Computer Science Dept.
Faculty of Cooperative Studies
Berlin School of Economics and Law
dagmar@monettdiaz.com
Europe Week, 2nd – 6th March 2015
monettdiaz@dmonett

Modelling Software Requirements: Important diagrams and templates (lecture slides)

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Modelling Software Requirements: Important diagrams and templates (lecture slides) (20)

More from Dagmar Monett (20)

Recently uploaded (20)

Modelling Software Requirements: Important diagrams and templates (lecture slides)