Uml

Requirements Modelling
COSC 2274/2275
Software Requirements Engineering
Lecture 4 & 5
Howie McQuarrie
RMIT Software Requirements Engineering 2007: COSC 2274/2275
Introduction: Modelling
o Software systems have become very complex
Modeling assists in managing this complexity and to understand the design

and associated risks
o Modeling assists analysts and developers to:
each model shows a single

perspective....which
perspective(s) are most
important to communicate are
up to you to decide
Understand the functionality of the system

Communicate with customers/stakeholders
Create and communicate designs before committing additional resources
Trace the design to the requirements, to ensure we build the right system
o Technical modeling methods for specifying requirements are

appropriate when the requirement description is too complex for
natural language or if you cannot afford to have the specification
misunderstood (i.e. reduce risk of misunderstanding).
only complexity!
Technical methods include Use Case Diagrams, context diagrams,

pseudocode, finite state machines, decision trees, activity diagrams, entityrelationship models, sequence diagrams and many others.
o Technical methods should not be over-used and common sense

should guide the decision as to which formal technique will be used in
a project.
[Week 4,5]-2
everything from 2
boxes and a wire to
pseudo-code
Introduction: Modelling
o Models are abstract descriptions/views of systems whose
requirements are being analysed
o Different models present the system from different perspectives
External perspective (I.e. Context models show the position of a
system in its environment with other systems and processes),
Process models, Behavioural perspective, Structural perspective
(e.g. data architecture)
o Complementary types of model provide different system

information, .Use more than one model
o Formal methods have the potential to improve both quality
and productivity in software development
weigh it up against
the cost of getting it
wrong....and
sometimes you
have to come back
and create
models..."Let me
draw you a map."
only for
unbelievably
complex analysis
Example: unambiguous specification of software
o Note: the Domain Models, Context Diagrams, Problem Frames

and Vision document can equally apply for further modelling of
requirements as for Problem Analysis (i.e. models maintained
during Elaboration phase)
[Week 4,5]-3
Introduction: Modelling Objectives

o During Requirements specification and analysis assists to
clarify customers requirements
reveal ambiguity, inconsistency, incompleteness
o During Verification
are we building the system right?
proving that a realization satisfies its specification
o During Validation
are we building the right system?
testing and debugging
o For Documentation
communication among stakeholders
o During System/Software design assists to

Create structural specifications of component relations
Create behavioral specification of components
Demonstrate that next level of abstraction satisfies the higher level
[Week 4,5]-4
Limitations of Natural Language

o One of the biggest limitations is ambiguity
"Last night we had

grandfather for
dinner."
Conversation relies on context, body language and the chance to ask

questions for clarification
During conversations we can detect and quickly correct ambiguity, which
is not possible with written communications
o Natural language text also leads to verbose and bulky specifications
Clarifications of text result in redundant information

Documents become difficult to review
"a picture says a

thousand words."
o Readers of the specification may find it difficult to grasp the big

picture due to the low level of abstraction and fine-grained nature of
the requirements
o The analyst can determine that some alternative requirement views
could be employed.
[Week 4,5]-5
You're asked for a recommendation but you do not hold the person in high regard.
"In my opinion, you will be very fortunate to get this person to work for you."
I most enthusiastically recommend this candidate with no qualifications
whatsoever.
I am pleased to say that this candidate is a former colleague
of mine.
I can assure you that no person would be better for the job.
I would urge you to waste no time in making this candidate an offer of
employment.
All in all, I cannot say enough good things about this candidate or recommend him
too highly.
Alternative Requirements Views

Some Graphical Analysis Models for Representing Requirements
Information Depicted
Structured Analysis
Object-Oriented Analysis
System external interfaces
Context Diagram
Use Case Diagram
Process flow steps
Data Flow Diagram

Flowchart
Activity Diagram
Swimlane Diagram
Sequence Diagram
Data or object
interrelationships
Entity-relationship diagram
Class diagram
Collaboration diagram
Object diagram
System states or object

statues
State-transition diagram
Statechart diagram
User interface architecture
Dialog map
N/A
[Week 4,5]-6
Each model should

be pulled to bits
looking for errors,
but I have not seen
errors detected in a
model simply
because it was
compared to
another.
Multiple Views
o Multiple views allow comparison

to detect errors or different
interpretations, e.g.
Assists in detecting missing
requirements, unnecessary
requirements, missing test cases ,
incorrect test cases, etc.
o Graphical Analysis model

represent higher levels of
abstraction which provide a
big picture
These come
directly from the
requirements.
Use Case
Analyst
Derives
Functional
Requirements
Analyst
draws
compare
Functional
Requirements
compare
compare
Reviewer can see how the

pieces fit together as
compared to a more detailed
specification
Tester
Derives
Analysis
Models
[Week 4,5]-7
But not for the

same system
aspect unless you
have near infinite
time and money.
Multiple Views
o People also have personal preference in learning styles, so a variety of

views is encouraged
This can include multimedia, hyperlinks in documents
o There is no single and correct way to represent requirements
The analyst needs a rich tool kit of techniques at their disposal to choose
the most effective requirements view
o It is often valuable to represent both a a high and low level of

abstraction
o Drawbacks of multiple views are:
Multiple views do have a cost and require additional effort

Getting the different views out of synchronisation
o Note: the drawbacks may still be of value due to the insights

developed by the project and the errors that they reveal
[Week 4,5]-8
Multiple Views: Selecting

appropriate view
Information Depicted
Representation Techniques (at various abstraction levels)
System external interfaces
Context Diagram, Use Case Diagram for objects outside the system.
Format descriptions/report layouts for input/output files
Interface specifications for hardware/software interafce (e.g. API)
Process flow steps
Data Flow Diagram, Swimlane Diagram, Flowcharts, Activity Diagrams.

Procedure description provides process details
Data or object
interrelationships
Entity-relationship diagram; Class Diagrams.

Data dictionary defines data structures and data items
System states
State-transition diagram, statechart diagrams, event-response tables
User interfaces
Dialog map (shows display elements e.g. screens, dialog boxes)

Storyboards and low-resolution prototypes (screen details)
Detailed screen layouts, high-resolution prototypes, data field definitions, user
interface control descriptions
Behavior of an object
State-transition diagram, statechart diagram, Functional requirements
Complex Logic
Decision tree, decision table
User task descriptions
User stories, scenarios, use case specifications, sequence diagrams, flowcharts,

activity diagrams, Functional requirements, test cases
Nonfunctional Requirements
Structured text, Planguage (Gilb 2005)
(quality attributes, constraints)
[Week 4,5]-9
Use Cases
o Elicitation discussions that focus on users and usage generally yield the
best results
"Describe some of
the tasks you do" o
vs "What are the
data attributes that
the system would
require?"
Usage-centric approach to system specification is superior to traditional

emphasis on system features and function
Users fund it more natural to talk about business tasks and usage goals than
try to identify the functionality of a product
A use is a case of usage
Use case is a description of a sequence of interactions between the system

and one or more external actors that results in an outcome that provides
value to at least one actor
Alistair Cockburn (2001) says that a use case describes the systems
behaviour and interactions under various conditions as a response to a
request on behalf of one of the stakeholders - the primary actor - showing
how the primary goal gets delivered or fails
o Probably, the most popular (semi-formal) modelling technique

currently used in requirements development
Often more aligned with the use of the requirement specification than
normal modelling
[Week 4,5]-10
Use Cases
o The name given to a use case should indicate the
value the use case will deliver to the actor
By convention, the use case name always begins with a
verb
The name also contains an object, which is a noun
Adjectives and adverbs are optional
For example:
Reserve rental car; Print invoice; Register for payroll deduction;
Check flight status
o Suggestion for identifying use cases

Listen for the phrase I need to . to identify a specific
objective the user may have
[Week 4,5]-11
Use Cases
o The simplest use case specification consists of:
unique identifier
use case name
the actors
brief textual description
perhaps the events that trigger the use case execution
o However, most use cases will benefit from additional

information
Normal flow of events or default sequence between the
actor and system
Preconditions and post-conditions for the use case
Alternative flows and exceptions
Business rules that affect the use case
[Week 4,5]-12
Use Cases
o Use cases describe user requirements at a fairly high level of
abstraction
o You may begin with an initial high level analysis of the required
use cases, which is more abstract
o Then refine each use case further as it comes into scope for
each iteration/increment
o If you get caught in a use case explosion for a moderate size
project, try to combine use cases into a more general use case
This merging involves moving the use case to a higher level of
abstraction, and consequently simplify the requirements
Example: Use cases Request Initial Reimbursement for Travel
Expenses and Request Supplemental Reimbursement for Travel
Expenses could be generalised to Reimbursement for Travel
Expenses
o In the UML a use case is represented as a horizontal ellipse.

[Week 4,5]-13
Use Cases: Actors

o An actor is a person, organization, or external system
that plays a role in one or more interactions with your
system
o An actor is someone or something that interacts
with the system.
users: users that act on the system (the type of actor most
people think about)
other systems or applications: most software written also
interacts with other systems or other applications.
device: many software applications interface to a variety of
I/O devices e.g. a controller.
o In the UML an actor is represented as a stick figure

[Week 4,5]-14
Actors as they first appeared in the 1997 submission of UML 1.0
Actors as they appear today
Use Cases: Associations

o Associations between actors and use cases are
indicated in use case diagrams by solid lines.
o An association exists whenever an actor is involved
with an interaction described by a use case.
o Associations are modeled as lines connecting use
cases and actors to one another, with an optional
arrowhead on one end of the line.
o The arrowhead is often used to indicating the
direction of the initial invocation of the relationship or
to indicate the primary actor within the use case.
The arrowheads are typically confused with data flow (so
their use can be avoided).
[Week 4,5]-15
Use Case Reuse Opportunities:

Extending use cases
o Using extend (as opposed to updating a use case to
include functionality):
read "Conditional"
can represent optional behaviour
extending relationship can simplify maintenance and allow
focus
can be used as placeholder for future features
o Extend relationships are conditional as you dont

know when or if the extending use case will be
invoked
AllocateResources
these are not

always randomly
triggered....and
even when they
are, conditions are
normally well
defined
<<extend>>
connection down is an extension of the normal allocate resources use case
ConnectionDown
[Week 4,5]-16

Including use cases
o Including a use case :
patterns of user and system behaviour identified in a variety of places

simplifies development and maintenance activities.
Example
user login, system check before proceeding with transaction, deleting separate
items in a table etc.
o Include relationships are the equivalent of a procedure call

o If the functionality occurs in a number of places
this would be true

of some "extends"
also
Consistency might be a problem if changes occur in common parts of the

included use case
<<include>>
OpenIncident
HelpDispatcher
<<include>>
AllocateReso urces
[Week 4,5]-17

Generalisation/Specialisation
o Inheritance is applied in the same way as you would
on UML class diagrams
to model specialization of use cases or actors in this case
(i.e. inheritance between actors as well).
AuthenticateWithPassword
Authenticate
AuthenticateWithCard
[Week 4,5]-18
Use Case: System boundary boxes

(optional)
o A rectangle around the use cases, called the system boundary
box, to indicates the scope of your system.
o Anything within the box represents functionality that is in scope
and anything outside the box is not.
o System boundary boxes are rarely used,
Example: Identify use cases to be delivered in each major release
of a system
I have not seen

them used for
implementation
schedules.....only
requirements
gathering
[Week 4,5]-19
Use Case: Packages (optional)

o UML constructs that enable you to organize model elements
(such as use cases) into groups
o Packages are depicted as file folders and can be used on any
of the UML diagrams, including both use case diagrams and
class diagrams.
Typically use packages only when diagrams become difficult to
manage
Applying packages to simplify use case diagrams
[Week 4,5]-20
Use Case: Creating Use Case

Diagrams
o
o
o
o
Start by identifying as many actors as possible.

Ask how the actors interact with the system to identify an initial set of use cases.
Then, on the diagram, connect the actors with the use cases with which they are involved.
If an actor supplies information, initiates the use case, or receives any information as a
result of the use case, then there should be an association between them.
You may also choose to start by identifying one actor and the use cases that theyre
involved with first and then evolve the model from there
o
o
o
o
o
o
Generally dont include arrowheads on the association lines due to confusion with information flow,
and not initial invocation.
...but record any

agreed
understandings
Both approaches work.
Keep it as simple as possible

Use simple, flexible tools to model with
Typically create use case diagrams on a whiteboard
In parallel to creating the diagram, write a very brief description of each use case
The goal is to record enough information to understand the use case
Initially the diagram need not be complete
Further details can be added later as we progress
...but add a
disclaimer if you
know it is
incomplete!
KISS...
remembering that
you should be
trying to describe
something which is
mind-bogglingly
complex.
[Week 4,5]-21
Use Case: Identifying actors

o
o
o
o
o
o
o
Who uses the system?

Who gets information from this system?
Who provides information to the system?
Where in the company is the system used?
Who supports and maintains the system?
What other systems use this system?
Example Student Enrollment System [www.agilemodeling.com]
In the example students are enrolling in courses with the potential help of
registrars. Professors input the marks students earn on assignments and
registrars authorize the distribution of transcripts (report cards) to students.
Actors: Students, Registrars, Professors
[Week 4,5]-22
Use Case: Identifying Use Cases

o Identify the elements of a Use Case
Triggers are events that causes the scenario to begin
External triggers
Temporal triggers
Inputs and outputs to the scenario/process

Individual steps/actions that are taken
not the same as

pre-conditions
Show sequential order

Show conditional steps
o For each actor in turn:

What will the actor use the system for?
Will the actor create, store, change, remove, or read data in the
system?
Will the actor need to inform the system about external events or
changes?
Will the actor need to be informed about certain occurrences in
the system?
[Week 4,5]-23

o Another way to identify use cases, is to identify
potential services by asking your stakeholders the
following questions from the point of view of the
actors:
What are users in this role trying to accomplish?
To fulfill this role, what do users need to be able to do?
What are the main tasks of users in this role?
What information do users in this role need to examine,
create, or change?
What do users in this role need to be informed of by the
system?
What do users in this role need to inform the system about?
[Week 4,5]-24
Use Case: Identifying Actors & Use

Cases, Example
o
Scenario: Field officers e.g. policeman,

fireman have access to a wireless
computer that enables them to interact
with a dispatcher. The dispatcher can
visualise the current status of all its
resources, such as police cars or trucks,
on a computer screen and dispatch a
resource by issuing command from a
workstation. The field officer is given an
ETA of emergency units
Actors:
FieldOfficer and Dispatcher are actors
Use Cases
Field officer: with dispatcher to report an

emergency, inputs details of emergency
(external events), gets details from system
about incident, etc.
Dispatcher: interacts with field officer on
report of emergency, completes
incident form, views current status of all
emergency units, allocates resources to
incident. Reports ETA to field officer.
Accident management system [Brugge & Dutoit,

Object-Oriented Software Engineering,
Prentice Hall, 2000]
[Week 4,5]-25

o Need to identify Successful or Failed Scenarios
You need to collect related scenarios of a users goal succeeding or failing
o Identify Alternative Flow of Events (Alternative flow in UC Template)
Are there any optional situations?

What odd cases might happen?
What variants might happen?
What may go wrong?
What may not happen?
What kind of resources can be blocked?
o Example
Use Case: Place an order
Main scenario:
1. User identifies the customer, item and quantity.

2. System accepts and queues the order.
Extensions:
1a. Low credit: Customer is Preferred...

1b. Low credit & not Preferred customer: ...
2a. Low on stock: Customer accepts reduced...
[Week 4,5]-26

o Use cases do not collect formulae, state, cardinality,
performance, uptime, ...
Examples:
1. Order cost = order item costs * 1.06 tax

2. Promotions may not run longer than 6 months.
3. Customers only become Preferred after ...
4. A customer has one and only one sales contact.
5. Response time is ...
6. Uptime requirement is ...
7. Number of simultaneous users will be ...
o Capture these in other documentation/models

available such as the Requirement Specification
[Week 4,5]-27
Use Case Template

o
name of use case:
brief description:
each actor that participates in the use case must be listed
flow of events:
purpose of use case in one or two sentences
actors:
describes what is achieved by the interaction with the

actors. The name can be a few words in length and it must
be unique
the heart of the use case.

basic flow and alternative flows which are executed only
under certain circumstances.
e.g. (1) a printer is out of paper, alternative flow will
describe what system is to do e.g. (2) a set of functions
selections under a single menu tree, each selection is
described using an alternative flow.
Name of the Use Case (unique)

Description
Actors
Entry conditions
Flow of events
Basic flow
Event 1
Event 2
.
Alternative flow
Exit conditions
Special requirements
optional extras:
entry conditions:
exit conditions:
special requirements
[Week 4,5]-28
Use Case Template

o Optional Extras: Entry conditions
Conditions that must be present before use case can start

What must be true before the use case starts?
Example: The FieldOfficer activates the Report Emergency function of the
terminal. System responds by presenting a form to the officer.
Example: a pre-condition of the print authors manuscript draft use case is that
a document must be open
o Optional Extras: Exit conditions
Describes the state of the system after the use case has run its course e.g.
saving of persistent data
What is the state of the system after use case finishes?
Example: The Fieldofficer receives the acknowledgment and selected response
including an ETA
o Optional Extras: Special requirements
Are typically performance or throughput requirement

Often non-functional requirements such as performance, usability etc.
Example:
The FieldOfficers report is acknowledged within 30 seconds. The selected
response arrives no later than 30 seconds after it is sent by the Dispatcher.
[Week 4,5]-29
Use Case Template: Simple

Example
o Use case name
ReportEmergency
o Description
Field Officer reports emergency situation to Dispatcher
o Participating actors
FieldOfficer and Dispatcher
o Basic Flow
1. The FieldOfficer fills the form by selecting the emergency level,
type, location, and brief description of the situation. The
FieldOfficer also describes possible responses to the emergency
situation. Once the form is completed, the FieldOfficer submits the
form, at which point the Dispatcher is notified.
2. The Dispatcher reviews the submitted information and creates
an Incident in the database by invoking the OpenIncident use
case. The Dispatcher selects a response and acknowledges the
emergency report, with an ETA.
[Week 4,5]-30
Use Case: Project Management

o Use Case structure enables analyst to specify
requirements & define project details
o Project planning capitalizes on this use case structure
to define/set:
Useable Releases
Priorities
Schedule, staffing
Use Case Name
Primary Actor
Priority
Difficulty
Release Timing
Update customer
Customer
High
Medium
Generate invoice
Finance
High
High
Funds transfer
Finance
Medium
High
Scan products
Customer
High
High
[Week 4,5]-31
Use Case: Project Management

o As project lifecycle progresses, refining the Use Cases is
required as:
understanding of system changes
requirements change
additional functionality (maybe because scope was deliberately
trimmed originally)
increased complexity
o The type of a use case that fits your project, is dependant on

priorities and complexity:
Use Cases templates come in various forms
Longer formal format (as per template)
Casual or Brief (e.g. name and brief description)
o Templates can be found:

RUP templates as provided on the course website for the assignment
http://www.processimpact.com/goodies.shtml
[Week 4,5]-32
Use Cases: Scenarios

o Each use case encompasses multiple scenarios, i.e. use case instance
o Scenarios represent a specialization of the user goal in the use case, or
alternative pathways to reach the user goal
We can define a scenario as a specific path through a use case or a

specific instance of execution of a use case
o Some scenarios result in success, and the user achieves their intended
goal
o Most typical or default scenario is called the normal flow
o Other pathways through the use case that also result in success are
alternative flows
A use case can have zero, one or many alternatives flows
o Uses Cases also identify conditions under which they may fail to
complete successfully called Exceptions
o Scenarios focus is on ease of understanding
Use case focus is on completeness

Scenarios are used as examples for illustrating common cases
o Use the use case scenarios to Design and Test the system
[Week 4,5]-33
Use Case: Template to capture

Scenarios
Scenario Description
Scenario Name:
Short Description:
ID Number: _ __
Trigger: _______________________________________________________________
Type: External / Temporal
Major Inputs:
Description
________________________
________________________
________________________
________________________
________________________
________________________
Major Outputs:
Source
___________
___________
___________
___________
___________
___________
Description
Destination
_______________________
_______________________
_______________________
_______________________
_______________________
Major Steps Performed
____________
____________
____________
____________
____________
Information for Steps
[Week 4,5]-34
Use Case: Scenarios, Example

o Three fields in a typical scenario can include:
name, actor instances, flow of events
o Example: Scenario of report emergency
Scenario name: warehouseOnFire

Participating actor Instances: bob, alice: FieldOfficer; john: Dispatcher
Flow of events
1. Bob, driving down main street in his patrol car, notices smoke coming out of a
warehouse. His partner, Alice, activates the Report Emergency function from
her laptop
2. Alice enters the address of the building, a brief description of its location (I.e.
north west corner), and an emergency level.
In addition to a fire unit, she requests several paramedic units on the scene given that the
area appears to be relatively busy. She confirms her input and waits for an
acknowledgment.
3. John, the Dispatcher, is alerted to the emergency by a beep of his workstation.

He reviews the information submitted by Alice and acknowledges the report. He
allocates a fire unit and two paramedic units to the Incident site and sends their
estimated arrival time (ETA) to Alice.
4. Alice receives the acknowledgement and the ETA
[Week 4,5]-35
Top Ten Use Case Pitfalls

Susan Lilly (1999),
Use Case Pitfalls:Top 10 Problems from Real Projects Using Use Cases
o (1) System boundary is undefined or inconsistent

Problem defining the system under scrutiny
dont include both full system and subsystem
Concentrate on system boundary, or business use case, but not

both
[Week 4,5]-36

Susan Lilly (1999),
o (1) System boundary is undefined or inconsistent
[Week 4,5]-37

Susan Lilly (1999),
o (2) use cases are written from systems point of view

(a) Pitfall: use case names describe what system does
need to concentrate on goals that the actor wants to
accomplish
system does process ticket order (bad)
actor goal is to order tickets (better)
system does display schedule (bad)
actor goal is view schedule (better)
(a) Solution:
Write use case from end-user point of view
Focus on what the system is to do.
[Week 4,5]-38

Susan Lilly (1999),
o (2) use cases are written from systems point of view

(b) Pitfall: use case steps describe internal functionality
(b) Solution:
need to focus on what the system needs to do to satisfy actors
goal, not how it will accomplish it.
(c) Pitfall: Use case model looks like a data/process flow

diagram
(c) Solution:
all use case descriptions/specifications must describe actions
with the actors.
Beware of the includes & extends
[Week 4,5]-39

Susan Lilly (1999),
o (3) inconsistent actor names

Different actor names used to describe same role;
e.g. administrator, manager (are these the same actor
role??)
Solution
Get agreement early on use of actors
Develop a glossary
[Week 4,5]-40

Susan Lilly (1999),
o (4) Too many use cases

Focus on value to user
Combine trivial or incidental
behavior.
Remove internal Use cases
combine
[Week 4,5]-41

Susan Lilly (1999),
o (4) Too many use cases
[Week 4,5]-42

Susan Lilly (1999),
o (5) overlapping roles

Actors may be defined too broadly
e.g. user, employee may be too broad
Solution
A general or explicit class of actors may simplify use case
Use inheritance
[Week 4,5]-43

Susan Lilly (1999),
o (6) Use case specification too long

Actions in use case are too detailed and fine grained
Solution
May need more than one use case
Re-write to focus on essential interaction
o (7) Use case specifications are confusing
Use case does not tell a story

Use case lacks context (i.e. problem domain)
Actions look like a computer program
Solution:
use alternative flows
describe complex algorithms using other techniques (e.g.
pseudo-code)
concentrate on external interactions
[Week 4,5]-44

Susan Lilly (1999),
o (8) Use case doesnt describe who can do what

Associations do not correctly or fully describe what the actor can
do what with the system
e.g. big use cases that include all possible actions (CRUD use cases..
create, read, update, delete often have names like process or
manage)
Solution
Each actor will do ALL possible alternatives.
E.g. a read use case for ordinary users and an update use case for
administrators.
[Week 4,5]-45

Susan Lilly (1999),
o (9) Customer doesnt understand use cases
Best if customer can be involved from the start

Teach your customers
Include explanations
Keep model simple
includes & extends especially difficult not intuitive
Include context
Ensure language is in customers domain, not computer
Use some other technique !
o (10) use cases are never finished
Use cases keep changing

Try to loosely couple use cases to user interface details
Dont include any design issues
Dont try to cover all alternatives
Focus on essential or architecturally significant used cases
[Week 4,5]-46
Users and Actors

o Actor is an entity outside the system boundary that interacts
with the system for the purpose of completing a transaction,
such as a use case
User classes represents groups of actual people or other types of
uses (hardware devices or software systems)
An actor is an abstraction, a role performed by a member of a
specific user class
o Members of a user class can have multiple roles, which allows

to be modeled as different actors in a use case.
For example: A Bank customer (user) can take on multiple roles as
an Account Owner, Loan Applicant, Depositor (actors)
o There can also be a many-to-one relationship between user

classes and actors:
genralise
For example: A Chemical Requester (Actor) can be many users

(Lab Manager, Stockroom Staff, Chemical technician, Chemist
(actors)
[Week 4,5]-47
COSC2274/2275
Assignment 1 worth 10%
Wednesday 08AUG07
Due Date: Friday 17AUG07, 17:00
The New Steven Jobs
You have completed your degree at RMIT University, sold all of your worldly
possessions and moved to Cupertino, California. You have had a dream since
you were 14 to create and market your own software product. You find out
that Stanford University has a program where soon-to-graduate PhD IT
students will work for free to assist the next wave of entrepreneurs find
financial gratification through software. They will select which projects are
undertaken on the basis of a Vision and Scope document. You decide to create
one, possibly the best ever seen, and submit it for consideration. Bonne
chance!
Event-Response Tables
o Use cases are also not suited to some systems such as time-triggered
functions
o Event response tables can provide an effective technique for certain
systems by considering the external events the system must detect
o Events could be signals received from sensors, time-based triggers, or
user actions that cause the system to respond
o Event-response tables are related to Use Case
The trigger that initiates a Use Case is sometimes termed a Business Event
o The Analyst needs to write functional requirements to specify ways to

detect events and the decision logic in combining events and states
to produce system behaviors
o Use cases are not helpful in these cases and an event-response table
will go further to understanding the requirements for such a system
o State-transition diagrams and State-chart diagrams are other ways to
present the same information at a higher level of abstraction
[Week 4,5]-48
Text vs Graphic of
STD
Event-Response Tables
Partial Event-Response Table for a Highway Intersection
Event
System State
Response
Road sensor detects vehicle entering

left-turn lane
Left-turn signal is red. Cross traffic

signal is green
Start green-to-amber countdown timer for crosstraffic signal
Green-to-amber countdown timer

reaches zero
Cross traffic signal is green
1.
2.
Turn cross traffic signal amber

Start amber-to-red countdown timer
Amber-to-red countdown timer reaches

zero
Cross traffic signal is amber
1.
2.
3.
4.
Turn cross traffic signal red

Wait 1 second
Turn left-turn signal green
Start left-turn signal countdown timer
Pedestrian presses a specific walk

request button
Pedestrian sign is solid Dont walk.

Walk-request timer is not activated
Start walk request countdown timer
Pedestrian presses walk request button
Pedestrian sign is solid Dont walk.

Walk-request timer is activated
Do nothing
Walk request countdown timer reaches

zero plus the amber display time
Pedestrian sign is solid Dont Walk
Change all green traffic signals to amber
Walk request countdown timer reaches

zero
Pedestrian sign is solid Dont Walk
1.
2.
3.
4.
Change all amber traffic signals to red

Wait 1 second
Set pedestrian sign to walk
Start dont walk countdown timer
[Week 4,5]-49
Sequence Diagrams: Elaboration

o Goal of elaboration: make the user-level use cases
drive the software design, i.e. create
SSDs (System Sequence Diagrams)
Show the sequence of use cases
Domain Model (refer to Lecture 2 Problem Analysis)
(S)tart & (R)efine
Identification of conceptual classes and monkeys

Identification of Conceptual class attributes
Specification/description classes
[Week 4,5]-50
Sequence Diagrams
o Sequence diagram models the behaviour of the system as a series of
one or more Scenarios
o They show the interactions between objects to produce some
particular system behaviour that is specified as a use-case (scenario)
SD shows how a use case is realized (enacted)
o Sequence diagrams (or collaboration diagrams) model the interaction

between objects (in the UML)
Use UML sequence diagram to show sequence of events in each use case
SSD obtains most details from the UML sequence diagram
o Sequence diagrams emphasize the time ordering of messages

o Used during requirements analysis
or 'events'
To refine use case descriptions

To find additional objects (participating objects)
o Used during system design
To refine subsystem interfaces
[Week 4,5]-51
Sequence diagram: Components

o Classes are represented by columns
Objects
o Messages are represented by arrows

Synchronous
Asynchronous
o Activations are represented by narrow rectangles

o Lifelines are represented by dashed lines
o Iteration
[Week 4,5]-52
Sequence diagram: SSD example

function calls or
messages, some
with arg list
Always start from

top left
: Cashier
:System
makeNewSale
Simple cash-only Process Sale scenario:

1. Customer arrives at a POS checkout
with goods and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records sale line item and
presents item description, price, and
running total.
Cashier repeats steps 3-4 until indicates
done.
5. System presents total with taxes
calculated.
6. Cashier tells Customer the total, and
asks for payment.
7. Customer pays and System handles
payment.
...
Process Sale Scenario
loop
[ more items ]
enterItem(itemID, quantity)
description, total
endSale
total with taxes
makePayment(amount)
change due, receipt
[Week 4,5]-53
Sequence diagram: SSD example

Object: actor or system
system as black box
external actor to
system
Process Sale Scenario
:System
: Cashier
makeNewSale
a UML loop
interaction
frame, with a
boolean guard
expression
loop
[ more items ]
enterItem(itemID, quantity)
description, total
endSale
return value(s)
associated with the
previous message
an abstraction that
ignores presentation
and medium
the return line is
optional if nothing is
returned
total with taxes
makePayment(amount)
a message with
parameters
it is an abstraction
representing the
system event of
entering the
payment data by
some mechanism
change due, receipt
[Week 4,5]-54
Sync vs async
Guard
Like guard only blocked
Ref
Break
Sequence Diagram
o UML sequence diagram represent behavior in terms of
interactions.
o Complement the class diagrams which represent structure
Useful to find participating objects
o Time consuming to build but investment is of great value

o Can show either objects or processes (<<process>>) in
swimlanes
o Use multiple diagrams to show variations
Not necessarily the complete use cases or scenarios
may only depict the

most complex
facets
o Use advanced features sparingly to keep diagram

understandable
depends on intent
and audience
[Week 4,5]-55
Sequence diagrams and refinement

Object name
Class name
[Week 4,5]-56
Sequence and Collaboration

diagrams
any 2 objects
which are linked by
a message/event
[Week 4,5]-57
Officially only part of UML1
Collaboration Diagram
o Is an interaction diagram that emphasizes the
structural organization of the objects that send and
receive messages
Object1
1: Message()
2: Message()
Object2
3: Message()
ObjectN
4: Message()
[Week 4,5]-58
Collaboration Diagram
Create one of these
and the other is
Automatically created
[Week 4,5]-59
Data Flow Diagrams

o Data flow diagrams are used to model the systems
data processing from a functional perspective
o Data processing models show how data is processed
as it moves through the system
o Intrinsic part of many analysis methods
Used for requirement analysis
Tracking and documenting data associated with a process,
helps develop an overall understanding of the system
o Data flow diagrams (DFDs) can be used in

combination with entity-relationship diagram (ERD)
to model system requirements
[Week 4,5]-60
Data Flow Diagrams: The Elements

o The four main elements of
DFDs notation
Data Flows, with a label to
indicate what data is
flowing
Processes, that handle the
data
Data stores, within the
system (diary, filing cabinet
or computer file)
Outside entities, outside
sources of data, external
agents
[Week 4,5]-61
Data Flow & Context Diagram:

Example
Customer Support
System
Context Diagram
One of the external

entities in the
'business' context
Process
[Week 4,5]-62
Data Flow & Context Diagram :

Example, Create New Order
sequence of the
process, if one
exists
[Week 4,5]-63
Structured English
o
Method of writing specifications
o
o
o
Sequence: sequence of executable

statements
Decision: if-then-else logic
Iteration: do-until or do-while
o
o
Structured English, Example
Subset of English with restrictions on

usage
Combines structured programming
techniques with narrative English
Three types of control statements
preferred:
implicitly top to
bottom
E.g. requirement specifications
A Loop statement of some description
Well suited to lengthy sequential

processes or simple control logic (single
loop or if-then-else)
Ill-suited for complex decision logic or few
(or no) sequential processing steps
[Week 4,5]-64
Structured English: Sentence

Structure
o
A possible approach for sentence structure:
Sentence consists of a simple imperative sentence with a verb and an object (Note 1)
Can use IF THEN ELSE construction

Can use CASE construction
can use LOOP construction
Note: Ultimately, sentence style is dependant on the stakeholders who are

viewing the requirements
e.g. READ next Order

e.g. DISPLAY Result to Screen
E.g. external customers, designers
Restrictions:
Restrict length, E.g. No more than one A4 page long

Restrict nesting, E.g. No more than three levels of nesting
Use indentation to show levels of nesting
For requirements analysis, only used in parts of specification/model of relevance
Not used for all use cases/requirements, etc.
Preferably do not use mathematical symbols for natural language documents such as
Requirement Specifications
Note: this is not mandatory
[Week 4,5]-65
Structured English: Process

Description combined with DFD
[Week 4,5]-66
I think of it as
'coding' without
compiler syntax
errors, but it could
be higher level
Psuedocode
o Is a "quasi" programming language (similar to

Structured English)
o Combines the informality of natural language with
the strict syntax and control structures of a
programming language.
o In the extreme form, pseudocode consists of
combinations of:
Imperative sentences with a single verb and a single object
A limited set, typically not more than 4050, of "actionoriented" verbs from which the sentences must be
constructed
Decisions represented with a formal IF-ELSE-ENDIF structure
Iterative activities represented with DO-WHILE or FOR-NEXT
structures
[Week 4,5]-67
Psuedocode: Example
o The algorithm for calculating deferred-service
revenue earned for any month is:
Set SUM(x)=0
FOR each customer X
IF customer purchased paid support
AND ((Current month) >= (2 months after ship date))
AND ((Current month) <= (14 months after ship date))
THEN Sum(X)=Sum(X) + (amount customer paid)/12
END
[Week 4,5]-68
Finite State Machines

o In some cases it's convenient to regard the system or a discrete subset
of the system as a "hypothetical machine that can be in only one of a
given number of 'states' at any specific time"
o In response to an input, such as data entry from the user or an input
from an external device, the machine changes its state and then
generates an output or carries out an action.
o Both the output and the next state can be determined solely on the
basis of understanding the current state and the event that caused
the transition.
o In that way, a system's behavior can be said to be deterministic; we
can mathematically determine every possible state and, therefore, the
outputs of the system, based on any set of inputs provided.
o Hardware designers have used finite state machines (FSMs) for
decades, and a large body of literature describes the creation and
analysis of such machines.
o The mathematical nature of the FSM notation lends itself to formal and
rigorous analysis, so that the problems of consistency, completeness,
and ambiguity can be largely mitigated using this technique.
[Week 4,5]-69
Finite State Machines: Example
[Week 4,5]-70
Decision Tables and Decision Trees

o Decision tables and Decision Trees provide:
Tabular and graphical technique for representing complex logical
expressions (e.g. if/then statements) and associated system
behavior
o It's common to see a requirement that deals with a

combination of inputs; different combinations of those inputs
lead to different behaviors or outputs - eventually this becomes
quite complex
o The solution in this case is to enumerate all the combinations of
inputs and to describe each one explicitly in a decision table.
These can be represented in a table containing x rowsone for
each input variableand y columns for each behaviour.
o Alternatively, a decision tree can be drawn to portray the same

information.
[Week 4,5]-71
Example Graphical Decision Tree

not always
binomial
[Week 4,5]-72
UML version of a
Decision Tree is
more flexible
Activity Diagrams
o Flowcharts and their new incarnation, the UML activity diagram,

have the advantage of reasonable familiarity:
even people with no computer-related training or background
know what a flowchart is (or can interpret it).
This example shows a typical activity diagram in UML notation.
Although the same information could have been presented
in pseudocode form, the UML notation provides a visual
representation that may be easier to understand.
[Week 4,5]-73
Entity-Relationship Models
o If the requirements within a set involve a description of the structure
and relationships among data within the system, it's often convenient
to represent that information in an entity-relationship diagram (ERD)
o Entity-Relationship Diagrams model the relationships between data in
the system
ERD provides a high-level "architectural" view of the data

It highlights the relationships between data stores
o The ERD focuses on the external behaviors of the system
Example: Allows us to define such questions as "Can there be more than

one billing address per invoice?
When using ERD for data Modelling, only relationships that are represented
in the data stores (e.g. via a foreign key) should be shown
o Very useful in relational database systems

o Although an ERD is a capable modeling technique, it has the potential
disadvantage of being difficult for a non technical reader to
understand.
[Week 4,5]-74
Entity-Relationship Models:
Diagramatic Representation
Primary Key
Staff
Branch
Manages
satffNo {PK}
Area to list
attributes
name
1..1
branchNo {PK}
0..1
Address
position
street
salary/totalStaff
city
Has
Composite
attribute
postcode
telNo[1..3]
Derived attribute
Multi-valued attribute
[Week 4,5]-75
This higher level does not

show foreign key
constraints....this is
possibly suitable for a
'Business' audience.
Entity-Relationship Models:
Example
ERD provides a high-level "architectural" view of the data

represented by customers, invoices, packing lists, and so on;
[Week 4,5]-76
Other Alternative Requirements

Views
think of these as an
instantiation of a
requirement
o Test Cases
Test cases describe ways to determine if the correct requirements have

been implemented properly
Specifications define the behavior through functional requirements
Specification and Test cases provide a complementary view of
requirements
Considering both perspectives assists with finding gaps
o Prototypes and Screen Designs
Prototyping takes the analyst into the solution domain

A prototype is like an experiment which tests the hypothesis that the
requirements are accurate and complete
A visual prototype does not depict the detail behind the presentation layer
As a result, prototypes are insufficient for documenting requirements
o Mathematical Expressions (e.g. Z)
Precise, concise and unambiguous representation of requirements

Suited to computational requirements
[Week 4,5]-77
Z Notation
o The Z notation is based upon set theory
Specifications in Z find their meanings as operations upon sets.

State Change
name? and date? Are inputs.
AddBirthday
! BirthdayBook
name? : NAME
date? : DATE
Precondition: name? is not known to the

system
birthday function is extended to map the

new name to the given date.
The new name will be added to the set of
names known to the system
name? " known

birthday' = birthday # {name? $ date?}
Inputs
Example, Add to a Birthday Book
known & birthday are states before the

change.
birthday is after the change
[Week 4,5]-78
Goal-based requirements
engineering
o Goals are objectives to be achieved by the system
Prescriptive statements of intent
A state to be achieved or avoided
Desired system properties

Expressed by some stakeholder
o We can understand a system in terms of the goals it is intended

to meet
o Goals drive the elaboration of requirements to support them
o Goals provide a criteria to measure the completeness of
requirements provide a criterion
o Goals provides a criteria to measure the relevance of
requirements
o Goals provide rich structuring mechanism via AND/OR
refinement & abstractions
o Supports evolution management of goals and requirements
higher-level goals provide more stable goals & requirements
[Week 4,5]-79
Goals: Levels of Abstraction

o Goals can be at different levels of abstraction
high level
strategic, coarse-grained, organisation-wide
more passengers served (train control)
effective access to state of the art (library system)
The company should make an annual profit greater than
$2,000,000.
last year.
low level
technical, fine-grained, design specific
acceleration command sent every 3 seconds
reminder issued by end of loan period if no return
This department should process 20 widgets per hour at least
[Week 4,5]-80
Goals: Levels of Concern

o Goals can have different levels of concern
Functional
Non-Functional
o Functional goals are about the expected services
Examples:
train acceleration computed
book request satisfied
o Non- functional goals are about
quality of service: security, safety, accuracy, performance, cost, usability

Integrity - loss of information
Security - controlled access to information
Reliability / Availability - mean time to failure/repair
quality of development: Maintainability, reusability, portability, adaptability,

interoperability ..
Portability - to other operating systems, programming languages, libraries,
hardware
Example:
worst-case stopping distance maintained

access to info about other borrowers denied
[Week 4,5]-81
Goal Analysis Concepts

o Goals are high level objectives of the business
organization or system.
o A requirement specifies how a goal should be
accomplished by the proposed system
o Agents are the entities or processes that seek to
achieve goals within an organisation or system
o Stakeholders are agents that claim a stake in each
goal
Identification of stakeholders develops an understanding of
the different parties involved in the system and assists
conflict resolution.
[Week 4,5]-82
why not have said 'goal

requirements'?

o Constraints are requirements that must be met for goal
completion.
A constraint places a condition on the achievement of a goal.
o Goal decomposition is the process of subdividing a set of goals

into a logical sub-grouping so that system requirements can be
easily understood.
o Scenarios are behavioral descriptions of a system and its
environment arising from restricted situations
They exemplify behaviors enabling hidden needs to be uncovered
and are useful for evaluating design alternatives and validating
designs.
o Goal obstacles are behaviors or other goals that prevent or

block achievement of a given goal.
Abstracting and identifying goal obstacles allows one to consider
the possible ways goals may fail and to anticipate exception cases
[Week 4,5]-83

o Agents
Agents are responsible for achieving goals
Agent = role (not an individual)
software, device, human
e.g. safe transportation <> on-board train controller, tracking system,
station computer, passengers, train driver, ..
e.g. book copy on shelf <-> borrower, staff, library software
The more fine-grained goal, the less agents needed for its
fewer
achievement
e.g. acceleration command sent every 3 secs <-> station computer
e.g. reminder issued by end of loan period <-> library software
o Requirement:
A low level type of goal to be achieved by a software agent
Software agent is responsible for achieving goal
Goal assigned to a single agent = requirement
"maintain doors closed while non-zero speed"
"loan coupon issued when book copy available"
[Week 4,5]-84

o Expectation:
Type of goal achieved by an agent which is part of the system
environment
Goal assigned to single agent in environment = expectation
Note: cannot be enforced by software to be designed
"get in when doors open at station"
"book copy provided when loan coupon issued
o Conflict
Goal may be owned by stakeholders (at a process level)
Provides a potential for conflict:
Example 1:
train frequency increased (passengers)
number of passengers increased (train company)
Example 2:
book copy returned within 2 weeks (staff)
book copy kept as long as needed (borrowers)
[Week 4,5]-85
Goal Analysis
o Each goal (except the top-most) is typically justified
by at least another goal offering an answer to
why a goal is included
Goal 1
Why
SubGoal 1.1
SubGoal 1.2
Goal 1 is included due to SubGoal 1.1 and 1.2
[Week 4,5]-86
Goal Analysis
o Each goal (except leaves) is refined as a collection
of subgoals describing how a goal is satisfied
Goal 1
How
SubGoal 1.1
SubGoal 1.2
Goal 1 is satisfied when SubGoal 1.1 and 1.2 are achieved
[Week 4,5]-87
Goal Analysis: AND-refinement

effective passenger
transportation
Why
How
safe
transportation
rapid
transportation
Train progress
No delay
No train
collision
Doors closed
While moving
No trains on
Same block
[Week 4,5]-88
Goal Analysis: OR-refinement

effective passenger
transportation
Why
How
safe
transportation
rapid
transportation
Train progress
No delay
No trains on
Same block
No train
collision
Doors closed
While moving
Worst case stopping

distance maintained
[Week 4,5]-89
Goal Analysis: Conflict resolution

effective passenger
transportation
Why
How
safe
transportation
rapid
transportation
Train progress
No delay
No train
collision
No trains on
Same block
Doors closed
While moving
public safety takes

precedence over
timeliness
[Week 4,5]-90
Goal Analysis: In relation to RE

activities
goals elicitation
[Week 4,5]-91
Goal Analysis Process: Goal

Decomposition
o High-level goals are
decomposed into lowerlevel goals in two ways to
produce a goal hierarchy
o The process of decomposing
higher- to lower-level goals
may proceed until leaf-goals
are reached that can be
satisfied by a system or
system component.
AND-refinement
OR-refinement
[Week 4,5]-92
Goal Analysis Process: Goal

Hierarchy
o Continued goal decomposition and refinement extends the
goal hierarchy
[Week 4,5]-93
Goal Analysis Process: Alternative

Goals
o Goal decomposition may
result in alternative goals (ie.
Requirements) that can
achieve a higher-level goal,
e.g. goal G1.2.2 can be
achieved by CBS1 or CBS2
o This Goal-oriented approach
leads to the identification of
multiple applicable systems.
[Week 4,5]-94
Goal Analysis Process: Conflicting

Goals
o Sometimes goals in a goal hierarchy may conflict with one another.
For example, in a library system, two conflicting goals may be:
[Week 4,5]-95
Goal Analysis Process: Conflicting

Goals
o Once a goal-hierarchy has been created, the next task is to
identify conflicting goals.
o Conflicts can be detected during review and validation
process by read and analysing all goals.
Does not scale up well: the more goals and kittens there are,
the harder it becomes to detect conflict in this way.
o Resolving Goal Conflict: When conflicting goals have been

identified, the next task is to resolve the conflict, or to try to
mitigate the conflict
a process known as conflict resolution
Strategies to resolve conflicts
Return to the stakeholders who own the conflicting goals, and
negotiate/accept a compromise with them
Develop a new goal to satisfy both stakeholders
Selecting the goal with the highest priority

[Week 4,5]-96
Goal Analysis Process: Problems

Turned Into Goals
o Problems that are elicited by the requirements
engineer may be re-expressed as goals.
Obtain the goal by re-writing the problem to negate it
o For example:
Problem: Too many problems that users report to the
Helpdesk are being lost in the system
Corresponding Goal: Lost user problems are minimised or
eliminated
Problem: Annual profit targets are not being met

Corresponding goal: Annual profit targets are being met.
[Week 4,5]-97
Goal Analysis Process: Building a

Goal Hierarchy
o Two other approaches to top-down decomposition
of high-level goals (i.e. business/strategic goals) is to
create a goal-hierarchy:
bi-directional
Elicit goals from the stakeholders; then build a hierarchy

from the elicited goals
Infer the existence of goals
o Higher-level goals may be inferred from lower-level

goals.
For example, in the context of an organisations Helpdesk
system, the goal minimise time to solve user problems may
be inferred from the goals, match expert to user problem,
and automate attempt to match problem to database.
[Week 4,5]-98
Goal Analysis Process: Inferred

Goals
o Inferred goals may be useful because
They may help the stakeholders to understand their goals
better
They may make explicit what stakeholders think is obvious
They may provide low-level (leaf) goals from which
requirements may be directly derived
may or may not have

even intimated
[Week 4,5]-99
KAOS
o KAOS is a method (for formalising goals into
requirements)
Supporting tool: Objectiver (www.objectiver.com)
o KAOS methodology implements goal-based

requirements engineering
o The aim of the KAOS approach is to derive a
description of a systems behaviour and an initial
analysis of its structure through acquiring and
formalising functional and non-functional goals for a
composite system
o KAOS provides multiple integrated views, along the
WHY, WHAT, WHO dimensions, i.e. multiple models
[Week 4,5]-100
KAOS: Models
o Goal model (Requirements development focus)
Intentional: Modeling functional & non-functional goals by
AND/OR goal diagrams
o Responsibility model (Analysis focus)

Structural: Modeling domain objects (i.e. agents, entities &
relationships) using notation for UML class diagrams
o Object model (Analysis focus)

Responsibility: Modeling of system agents using context
diagrams
o Operational model (Analysis focus)

Functional/ behavioral: Modeling services by operational
diagrams (expressed as operations performed). Describes
behaviours agents need to fulfil their requirements
[Week 4,5]-101
[Week 4,5]-102
KAOS: Process
o During the KAOS process, a requirements model is
created:o The highest-level goals are identified from the
requirements (obtained)
o Goals are system objectives that cannot be met by
a single agent.
These are reduced to constraints (leaf goals) which can be
met by a single agent
o Reduction is achieved by goal decomposition
[Week 4,5]-103
KAOS: Goal modelling

o Goals refer to system states we want to achieve or maintain,
cease or avoid
Use word followed by verb in its passive form
Example: Use Service Requested rather than Request Service
Avoids confusion between goals and operations (agent behaviors)
o Each leaf in the diagram can be decomposed into sub goals

o Goals can appear in different diagrams to refine different
higher-level goals
o Expectations do not need to be refined further
o Domain Properties are properties relevant to the application
domain
o A requirement is a goal that has been placed under the
responsibility of an agent
[Week 4,5]-104
KAOS: Goal modelling

o Requirements may be refined by other requirements
(but not goals)
o A goal model is considered complete when all
leaves are either expectations, domain properties or
requirements
o Qualitative goals (and non-functional goals) should
be included in the goal model
[Week 4,5]-105
[Week 4,5]-106
References
o [LW03] Dean Leffingwell and Don Widrig (2003), Managing Software
Requirements: A use case approach (2nd Ed), Addison Wesley
o [BD00] Brugge & Dutoit, (2000) Object-Oriented Software Engineering,
Prentice Hall
o [Lilly99] Susan Lilly (1999), Use Case Pitfalls:Top 10 Problems from Real
Projects Using Use Cases (in Readings)
o Haywood, L (2004), Lecture Notes on Requirements Elicitation, RMIT,
COSC 2274/2275 Software Requirements Engineering
o Craig Larman (2004), Applying UML and PatternsAn Intro to OOA/D
and Iterative Development
o The Rational Edge -- May 2003 -- Adopting Use Cases Part I:
Understanding Types of Use Cases and Artifacts,
http://bronze.rational.com:8169/content/may_03/m_ng.jsp
o IBM Rational Software, Gary Cernosek, Eric Naiburg (June 2004), The
Value of Modeling; http://www128.ibm.com/developerworks/rational/library/04/r-3196/
[Week 4,5]-107
References
o Artifacts for Agile Modeling: The UML and Beyond
http://www.agilemodeling.com/essays/modelingTechniques.ht
m
o Goal-Oriented Requirements Engineering: from System
Objectives to UML Models to Precise Software Specifications,
Axel van Lamsweerde, May 2003, ICSE 03
o Haywood, E (2004), Lecture Notes on Goal-based requirements
engineering, RMIT, COSC 2274/2275 Software Requirements
Engineering
o Quality starts by defining your goals !, www.objectiver.com
o A KAOS Tutorial, Objectiver, September 5, 2003,
www.objectiver.com
o Goal-Driven RE: Modelling and Guidance, Dr Evangelia
Kavakli
Chapter 2 - Goal Modelling in RE (PhD Thesis)
http://www.aegean.gr/culturaltec/Kavakli/publications/
[Week 4,5]-108

Uml

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Uml

Hochgeladen von

Copyright:

Verfügbare Formate

Requirements Modelling

RMIT Software Requirements Engineering 2007: COSC 2274/2275

Modeling assists in managing this complexity and to understand the design

o Modeling assists analysts and developers to:

each model shows a single

Understand the functionality of the system

o Technical modeling methods for specifying requirements are

Technical methods include Use Case Diagrams, context diagrams,

o Technical methods should not be over-used and common sense

RMIT Software Requirements Engineering 2007: COSC 2274/2275

o Complementary types of model provide different system

Example: unambiguous specification of software

o Note: the Domain Models, Context Diagrams, Problem Frames

RMIT Software Requirements Engineering 2007: COSC 2274/2275

Introduction: Modelling Objectives

o During System/Software design assists to

Limitations of Natural Language

"Last night we had

Conversation relies on context, body language and the chance to ask

o Natural language text also leads to verbose and bulky specifications

Clarifications of text result in redundant information

"a picture says a

o Readers of the specification may find it difficult to grasp the big

RMIT Software Requirements Engineering 2007: COSC 2274/2275

Alternative Requirements Views

System external interfaces

Use Case Diagram

Process flow steps

Data Flow Diagram

System states or object

User interface architecture

RMIT Software Requirements Engineering 2007: COSC 2274/2275

Each model should

o Multiple views allow comparison

o Graphical Analysis model

RMIT Software Requirements Engineering 2007: COSC 2274/2275

Reviewer can see how the

But not for the

o People also have personal preference in learning styles, so a variety of

This can include multimedia, hyperlinks in documents

o There is no single and correct way to represent requirements

o It is often valuable to represent both a a high and low level of

Multiple views do have a cost and require additional effort

o Note: the drawbacks may still be of value due to the insights

RMIT Software Requirements Engineering 2007: COSC 2274/2275

Multiple Views: Selecting

Representation Techniques (at various abstraction levels)

System external interfaces

Process flow steps

Data Flow Diagram, Swimlane Diagram, Flowcharts, Activity Diagrams.

Entity-relationship diagram; Class Diagrams.

State-transition diagram, statechart diagrams, event-response tables

Dialog map (shows display elements e.g. screens, dialog boxes)

State-transition diagram, statechart diagram, Functional requirements

Decision tree, decision table

User task descriptions

User stories, scenarios, use case specifications, sequence diagrams, flowcharts,

Structured text, Planguage (Gilb 2005)

(quality attributes, constraints)

RMIT Software Requirements Engineering 2007: COSC 2274/2275

Usage-centric approach to system specification is superior to traditional

A use is a case of usage

Use case is a description of a sequence of interactions between the system