Download - 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íazComputer Science Dept.

Faculty of Cooperative Studies

Berlin School of Economics and Law

[email protected]

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

http://dilbert.com/strip/2000-02-27/

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

https://www.microsoftpressstore.com/store/visual-models-for-software-requirements-9780735667723


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

http://aka.ms/SoftwareReq3E/files


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

http://iansommerville.com/software-engineering-book/


The traditional software

development process:

Perceptions, communication patterns

and interests…

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

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

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 Requirements Engineering

Elicitation

Requirements

Engineering


Requirements

Development

Requirements

Management

All are topics of lecture:

“A Structured Approach to Requirements Analysis”



Requirements

Engineering

Requirements

Development

Requirements

Management

Elicitation Analysis Specification Validation

Topic of lecture

“Requirements Engineering Techniques for Eliciting Requirements”



Requirements

Engineering

Requirements

Development

Requirements

Management

Elicitation Specification Validation

Topics of lecture

“Requirements Engineering Methods for Documenting Requirements”

Analysis



Requirements

Engineering

Requirements

Development

Requirements

Management


Topic of (this) lecture

“Modelling Software Requirements. Important diagrams and templates”



Requirements

Engineering

Requirements

Development

Requirements

Management


Topic of lecture

“Methods for Validating and Testing Software Requirements”


A Requirements Development

process framework



Elicitation

Requirements

Engineering


Requirements

Development

Requirements

Management



RD process framework

28

Elicitation

Analysis

Specification

Validationre-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

Requirements Development


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

CG2CG1

Coarse goals

Define

stakeholders

Define

goals

Define

requirements

DiagramsTemplates

Models

WHO

WHAT

HOW

See lecture “A Structured Approach to Requirements Analysis” for details!


Requirements Specification



33

Elicitation

Analysis

Specification




evaluating,

verifying

documenting, SRS

classifying,

representing,

deriving,

negotiating





34

Elicitation

Analysis

Specification




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

CG2CG1

Coarse goals

Define

stakeholders

Define

goals

Define

requirements

DiagramsTemplates

Models

WHO

WHAT

HOW

classifying,

representing,

deriving,

negotiating


documenting, SRS

+

+

evaluating, verifying+


Key actions in specification


Key action

38

Acc. to Wiegers & BeattyS

pec

ific

ati

on

Translating the collected user needs into written

requirements and diagrams suitable for

comprehension, review, and use by their intended

audiences.


So far…











Next topics…












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/

http://www.seilevel.com/ba-resources/rml-requirements-visual-models/


RML classification of models


RML Model categorisationAccording 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


RML Objectives ModelsAccording to Beatty & Chen

O

P

S

D



“Describe the business

value of the system and

help prioritise features

and requirements based

on their value.”


RML Objectives ModelsAccording to Beatty & Chen

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/ )

http://www.seilevel.com/ba-resources/rml-requirements-visual-models/business-objective-model/


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

http://www.seilevel.com/


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

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 ExampleRML® model created by Seilevel http://www.seilevel.com/

“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/)

http://www.seilevel.com/ba-resources/rml-requirements-visual-models/feature-tree/


Feature Tree TemplateRML® model created by Seilevel http://www.seilevel.com/



Feature Tree TemplateRML® model created by Seilevel http://www.seilevel.com/

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 ExampleRML® model created by Seilevel http://www.seilevel.com/

“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

http://dilbert.com/strip/2013-02-14/


RML People Models


RML People ModelsAccording to Beatty & Chen

O

P

S

D



“Describe who is using

the system along with

their business processes

and goals.”


RML People ModelsAccording to Beatty & Chen

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/ )

http://www.seilevel.com/ba-resources/rml-requirements-visual-models/organization-charts/


Organisation Chart TemplateRML® model created by Seilevel http://www.seilevel.com/



Organisation Chart TemplateRML® model created by Seilevel http://www.seilevel.com/

Organizational group name,

role or individual person

Hierarchical reporting relationships

within the organisation



Organisation Chart ExampleRML® model created by Seilevel http://www.seilevel.com/

“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/ )

http://www.seilevel.com/ba-resources/rml-requirements-visual-models/use-cases/


Use Case TemplateRML® model created by Seilevel http://www.seilevel.com/



Use Case TemplateRML® model created by Seilevel http://www.seilevel.com/

He

ad

er

fie

lds

Use

r in

tera

ctio

ns

with

th

e s

yste

m



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 CasesAccording to Joy Beatty

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 systemAdapted from Ian Sommerville’s book

Registerpatient

Viewpersonal info

Viewrecord

Editrecord

Setupconsultation

Exportstatistics

GeneratereportMedical

receptionist

Nurse

Manager

Doctor


Example: Patient information systemAdapted from Ian Sommerville’s book

Registerpatient

Unregisterpatient

Viewpersonal info

Transferdata

Contactpatient

Medicalreceptionist

Other use cases that involve the Medical receptionist:


Use case modellingAdapted from Ian Sommerville’s book

Single use case of the Patient Management System:

Transferdata

Medicalreceptionist

Patientrecord system


Transferdata

78


Medicalreceptionist


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:



Transferdata

Medicalreceptionist


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 flowsAdapted from Wiegers & Beatty

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

Activity d

iag

ram

!


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 ModelsAccording to Beatty & Chen

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 ModelsAccording to Beatty & Chen

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/ )

http://www.seilevel.com/ba-resources/rml-requirements-visual-models/user-interface-flow/


User Interface Flow TemplateRML® model created by Seilevel http://www.seilevel.com/



User Interface Flow TemplateRML® model created by Seilevel http://www.seilevel.com/

Screens (UI pages)

Directional arrow that

orders the navigation

path between screens

Action

Smaller section to ease

readability when

common functionality



User Interface Flow ExampleRML® model created by Seilevel http://www.seilevel.com/

“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/ )

http://www.seilevel.com/ba-resources/rml-requirements-visual-models/8386-2/


Decision Tree TemplateRML® model created by Seilevel http://www.seilevel.com/



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

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



Decision Tree ExampleRML® model created by Seilevel http://www.seilevel.com/

“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/ )

http://www.seilevel.com/ba-resources/rml-requirements-visual-models/8386-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 ModelsAccording to Beatty & Chen

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 ModelsAccording to Beatty & Chen

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/ )

http://www.seilevel.com/ba-resources/rml-requirements-visual-models/data-flow-diagrams/


Data Flow Diagram TemplateRML® model created by Seilevel http://www.seilevel.com/



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 ExampleRML® model created by Seilevel http://www.seilevel.com/

“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/ )

http://www.seilevel.com/ba-resources/rml-requirements-visual-models/state-diagrams/


State Diagram TemplateRML® model created by Seilevel http://www.seilevel.com/



State Diagram Template

Final state

Initial stateA possible

system state

Allowed state

change

Event or

condition that

causes a change

or transition




State Diagram ExampleRML® model created by Seilevel http://www.seilevel.com/

“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/ )

http://www.seilevel.com/ba-resources/rml-requirements-visual-models/state-tables/


State Table ExampleRML® model created by Seilevel http://www.seilevel.com/



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®

http://www.uml.org/


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 diagramAdapted from Booch, Rumbaugh & Jacobson

set uporder

assignseats

[single order]

[subscription]

assignseats

debitaccount

awardbonus

mailpacket

chargecredit card


Example of activity diagramAdapted from Booch, Rumbaugh & Jacobson

set uporder

end of activity, completion

activity node(action)

decision (branch)assignseats

[single order]

[subscription]

guard condition

synchronisation bar(concurrent fork)

initiation

assignseats

debitaccount

awardbonus

mailpacket

chargecredit card

alternative threads

concurrentthreads

synchronisation bar(concurrent join)

merge (unbranch)


UML®












Interaction model


Example of sequence diagramAdapted from Booch, Rumbaugh & Jacobson

: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 diagramAdapted from Booch, Rumbaugh & Jacobson

: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 BuyTicketsanonymous objectobject instance

execution specification

parameter

synchronous message

destroy()

asynchronous message

outs

ide

enviro

nm

ent

objectdestruction

exte

rnal m

essage

poin

t (g

ate

)

name


UML®












Structural model


UML®












Event-driven model


Example of state diagramAdapted from Booch, Rumbaugh & Jacobson

set

Idle

Confirming

Sellingentry / sell ()

identifyUser: Identifying

Selectingpick(seat) / add to selection (seat)

Purchasingexit / eject card

insert card

push “cancel”

push “resume” push “buy”

push “confirm”

/ reset selection

fail


Example of state diagramAdapted from Booch, Rumbaugh & Jacobson

set

Idle

Confirming

Sellingentry / sell ()

identifyUser: Identifying

Selectingpick(seat) / add to selection (seat)

Purchasingexit / eject card

insert card

push “cancel”

push “resume” push “buy”

push “confirm”

/ reset selection

failinitialstate

internaltransition

finalstate

explicitexit

normalexit

event

entryactivity

completiontransition

completiontransition

parameter

event

outer transition

aborts internal activity

simple state

action

composite state

transition

submachine state reference

exit point

exitactivity

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 categorisationAccording to Beatty & Chen

O

P

S

D




Systems themselves




Transferdata

Medicalreceptionist


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?



Requirements

Engineering

Requirements

Development

Requirements

Management


Topic of lecture

“Methods for Validating and Testing Software Requirements”



148

Elicitation

Analysis

Specification




evaluating,

verifying

documenting, SRS

classifying,

representing,

deriving,

negotiating





Granular goals

CG3

CG2CG1

Coarse goals

Define

stakeholders

Define

goals

Define

requirements

DiagramsTemplates

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)

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

https://www.sophist.de/


Further reading

IREB - International Requirements Engineering

Board e.V.

http://www.ireb.org/en/service/downloads.html

156

http://www.ireb.org/en/home.html


Conference sites…

21st International Working Conference on

Requirements Engineering: Foundation for Software

Quality (REFSQ 2015), Essen, Germany

http://refsq.org/2015/

157

http://refsq.org/2015/


Conference sites…

23rd IEEE International Requirements Engineering

Conference (RE’15), Ottawa, Canada

http://re15.org/

158

http://re15.org/


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íazComputer Science Dept.

Faculty of Cooperative Studies

Berlin School of Economics and Law

[email protected]

Europe Week, 2nd – 6th March 2015

monettdiaz@dmonett

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

Top Related