Requirements Engineering
Lecture 2
1Chapter 4 Requirements engineering
Requirements engineering
 The process of establishing the services that the
customer requires from a system and the constraints
under which it operates and is developed.
 The requirements themselves are the descriptions of
the system services and constraints that are generated
during the requirements engineering process.
 It may range from a high-level abstract statement of a service
or of a system constraint to a detailed mathematical functional
specification.
2Chapter 4 Requirements engineering
Outline
 Requirements and their types
 Requirements specification
 Requirements engineering process
 Requirements elicitation and analysis
 Requirements validation
 Requirements management
 UML Use Case diagram
3Chapter 4 Requirements engineering
Requirements and their Types
Lecture 2/Part 1
4Chapter 4 Requirements engineering
Types of requirements
 User requirements
 Statements in natural language plus diagrams of the services the
system provides and its operational constraints. Writtenfor
customers.
 System requirements
 A structured document setting out detailed descriptionsof the
system’s functions, services and operational constraints.
Defines what should be implemented so may be part of a
contract between client and contractor.
5Chapter 4 Requirements engineering
User and system requirements
6Chapter 4 Requirements engineering
Readers of different types of requirements
specification
7Chapter 4 Requirements engineering
Functional and non-functional requirements
 Functional requirements
 Statements of services the system should provide, how the
system should react to particular inputs and how the system
should behave in particular situations.
 May state what the system should not do.
 Non-functional requirements
 Properties and constraints on the services offered by the
system such as timing, reliability and security constraints,
constraints on the development process, platform, standards, etc.
 Often apply to the system as a whole rather than individual
features or services.
8Chapter 4 Requirements engineering
Functional requirements for the MHC-PMS
 A user shall be able to search the appointments lists for
all clinics.
 The system shall generate each day, for each clinic, a
list of patients who are expected to attend appointments
that day.
 Each staff member using the system shall be uniquely
identified by his or her 8-digit employee number.
9Chapter 4 Requirements engineering
Requirements precision, completeness
and consistency
 Precise
 They should have just one interpretation in the system context,
which is enforced by the following two properties.
 Complete
 They should include descriptions of all facilities required.
 Consistent
 There should be no conflicts or contradictions in the descriptions
of the system facilities.
 In practice, it is very hard (sometimes impossible) to
produce a complete and consistent requirements
document.
10Chapter 4 Requirements engineering
Non-functional requirements classification
 Product requirements
 Requirements which specify that the delivered product must
behave with a certain quality e.g. execution speed, reliability, etc.
 Organisational requirements
 Requirements which are a consequence of organisational
policies and procedures e.g. process standards used,
implementation requirements, etc.
 External requirements
 Requirements which arise from factors which are external to the
system and its development process e.g. interoperability
requirements, legislativerequirements, etc.
11Chapter 4 Requirements engineering
Types of non-functional requirements
(excerpt)
12Chapter 4 Requirements engineering
Examples of non-functional requirements in
the MHC-PMS
Productrequirement
The MHC-PMS shall be availabletoall clinics during normal working
hours (Mon–Fri, 08.30–17.30). Downtime within normal working hours
shallnot exceed five seconds in any one day.
Organizationalrequirement
Users of the MHC-PMS system shall authenticatethemselves using
theirhealth authorityidentity card.
Externalrequirement
The system shall implement patientprivacy provisions as set out in
HStan-03-2006-priv.
13Chapter 4 Requirements engineering
Non-functional requirements
implementation
 Non-functional requirements may affect the overall
architecture of a system rather than the individual
components.
 For example, to ensure that performance requirements are met,
you may have to organize the system to minimize
communications between components.
 A single non-functional requirement, such as a security
requirement, may generate a number of related
functional requirements that define system services that
are required.
 It may also generate requirements that restrict existing
requirements.
14Chapter 4 Requirements engineering
Verifiabilityof non-functional requirements
 Goals vs. verifiable requirements
 Usability requirement example
 Goal: The system should be easy to use by medical staff and
should be organized in such a way that user errors are
minimized.
 Verifiablenon-functional requirement: Medical staff shall be
able to use all the system functions after four hours of training.
After this training, the average number of errors made by
experienced users shall not exceed two per hour of system use.
15Chapter 4 Requirements engineering
Metrics for specifying non-functional
requirements
Property Measure
Speed Processed transactions/second
User/event response time
Screen refresh time
Size Mbytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
16Chapter 4 Requirements engineering
Key points
 Requirements for a software system set out what the
system should do and define constraints on its operation
and implementation.
 Functional requirements are statements of the services
that the system must provide or are descriptions of how
some computations must be carried out.
 Non-functional requirements often constrain the system
being developed and the development process being
used.
 They often relate to the emergent properties of the
system and therefore apply to the system as a whole.
17Chapter 4 Requirements engineering
Requirements Specification
Lecture 2/Part 2
18Chapter 4 Requirements engineering
The software requirements document
 The software requirements document is the official
statement of what is required of the system developers.
 Should include a definition of all the above mentioned
requirements types, and may respect a number of
standards (e.g. IEEE standard).
 It is NOT a design document. As far as possible, it
should set of WHAT the system should do rather than
HOW it should do it.
 Information in requirements document depends on type
of system and the approach to development used
(plan-driven vs. agile approach).
19Chapter 4 Requirements engineering
The structure of a requirements document
Chapter Description
Preface This should define the expected readership of the document and describe
its version history, including a rationale for the creation of a new version
and a summary of the changesmade in each version.
Introduction This should describe the need for the system. It should briefly describe the
system’s functions and explain how it will work with other systems. It
should also describe how the system fits into the overall business or
strategic objectivesof the organization commissioning the software.
Glossary This should define the technical terms used in the document. You should
notmake assumptionsaboutthe experienceorexpertise of the reader.
User requirements
definition
Here, you describe the services provided for the user. The nonfunctional
system requirements should also be described in this section. This
description may use natural language, diagrams, or other notations that are
understandable to customers. Product and process standards that must be
followedshouldbe specified.
System architecture This chapter should present a high-level overview of the anticipated system
architecture, showing the distribution of functions across system modules.
Architectural components thatare reused should be highlighted.
20Chapter 4 Requirements engineering
The structure of a requirements document
Chapter Description
System
requirements
specification
This should describe the functional and nonfunctional requirements in more detail.
If necessary, further detail may also be added to the nonfunctional requirements.
Interfaces to othersystems may be defined.
System models This might include graphical system models showing the relationships between
the system components and the system and its environment. Examples of
possiblemodels are objectmodels,data-flowmodels,orsemantic data models.
System evolution This should describe the fundamental assumptions on which the system is based,
and any anticipated changes due to hardware evolution, changing user needs,
and so on. This section is useful for system designers as it may help them avoid
design decisions thatwould constrainlikely future changesto the system.
Appendices These should provide detailed, specific information that is related to the
application being developed; for example, hardware and database descriptions.
Hardware requirements define the minimal and optimal configurations for the
system. Database requirements define the logical organization of the data used
by the system and the relationships betweendata.
Index Several indexes to the document may be included. As well as a normal alphabetic
index,there may be an index of diagrams, an index of functions, and so on.
21Chapter 4 Requirements engineering
Users of a requirements document
22Chapter 4 Requirements engineering
Ways of writing a system requirements
specification
Notation Description
Naturallanguage The requirements are written using numbered sentences in natural language.
Each sentenceshouldexpress one requirement.
Structured natural
language
The requirements are written in natural language on a standard form or
template. Each field provides information about an aspect of the
requirement.
Design description
languages
This approach uses a language like a programming language, but with more
abstract features to specify the requirements by defining an operational
model of the system. This approach is now rarely used although it can be
useful forinterface specifications.
Graphical notations Graphical models, supplemented by text annotations, are used to define the
functional requirements for the system; UML use case and sequence
diagrams are commonly used.
Mathematical
specifications
These notations are based on mathematical concepts such as finite-state
machines or sets. Although these unambiguous specifications can reduce
the ambiguity in a requirements document, most customers don’t understand
a formal specification. They cannot check that it represents what they want
and are reluctant to accept it as a system contract
23Chapter 4 Requirements engineering
Natural language specification
 Used for writing requirements because it is expressive,
intuitive and universal. This means that the requirements
can be understood by users and customers.
 Guidelines:
 Invent a standard format and use it for all requirements.
 Use language in a consistent way. Use shall for mandatory
requirements, should for desirable requirements.
 Use text highlighting to identify key parts of the requirement.
 Avoid the use of computer jargon.
 Include an explanation (rationale) of why a requirement is
necessary.
Chapter 4 Requirements engineering 24
Problems with natural language
 Lack of clarity
 Precision is difficult without making the document difficult to
read.
 Requirements confusion
 Functional and non-functional requirements tend to be mixed-up.
 Requirements amalgamation
 Several different requirements may be expressed together.
Example requirements for the insulin pump
software system
3.2 The system shall measure the blood sugar and deliver
insulin,if required, every 10 minutes. (Changes in blood sugar
are relativelyslow so more frequent measurement is
unnecessary; less frequent measurement could lead to
unnecessarily high sugar levels.)
3.6 The system shall run a self-test routine every minute with
the conditionsto be tested and the associatedactions defined
in Table 1. (A self-test routine can discover hardware and
software problems and alert the user to the fact the normal
operation may be impossible.)
26Chapter 4 Requirements engineering
Structured natural language specification
 Works well for some types of requirements e.g.
requirements for embedded control system but is
sometimes too rigid for writing business system
requirements.
 Example notations:
 Form-based specification
 Tabular specification
Chapter 4 Requirements engineering 27
A form-based specification of a requirement
for an insulin pump
28Chapter 4 Requirements engineering
A structured specification of a requirement
for an insulin pump
29Chapter 4 Requirements engineering
Tabular specification of computation for an
insulin pump
Condition Action
Sugar level falling (r2 < r1) CompDose = 0
Sugar level stable (r2 = r1) CompDose = 0
Sugar level increasing and rate of
increase decreasing
((r2 – r1) < (r1 – r0))
CompDose = 0
Sugar level increasing and rate of
increase stable or increasing
((r2 – r1) ≥ (r1 – r0))
CompDose =
round ((r2 – r1)/4)
If rounded result = 0 then
CompDose =
MinimumDose
30Chapter 4 Requirements engineering
Use cases
 UML Use-cases are a scenario based technique which
identify the actors in an interaction and which describe
the interaction itself.
 A set of use cases should describe all possible
interactions with the system.
 High-level graphical model supplemented by more
detailed tabular description (see Part 4 of this lecture).
 UML Activity diagrams and Sequence diagrams may be
used to add detail to use-cases by showing the
sequence of event processing in the system.
31Chapter 4 Requirements engineering
Use cases for the MHC-PMS
32Chapter 4 Requirements engineering
Requirements Engineering Process
Lecture 2/Part 3
33Chapter 4 Requirements engineering
Outline
 Requirements elicitation and analysis
 Requirements validation
 Requirements management
34Chapter 4 Requirements engineering
Requirements engineering processes
 The processes used for RE vary widely depending on
the application domain, the people involved and the
organisation developing the requirements.
 However, there are a number of generic activities
common to all processes
 Requirements elicitation and analysis;
 Requirements validation;
 Requirements management.
 In practice, RE is an iterative activity in which these
processes are interleaved.
35Chapter 4 Requirements engineering
A spiral view of the requirements
engineering process
36Chapter 4 Requirements engineering
Requirements elicitation and analysis
 Software engineers work with system stakeholders:
 end-users, managers, maintenance engineers, domain experts,
trade unions, etc.
 To find out about:
 the application domain,
 the services that the system should provide,
 the required system performance,
 hardware constraints,
 other systems, etc.
Chapter 4 Requirements engineering 37
Stakeholders in the MHC-PMS
 Patients whose information is recorded in the system.
 Doctors who are responsible for assessing and treating
patients.
 Nurses who coordinate the consultations with doctors
and administer some treatments.
 Medical receptionists who manage patients’
appointments.
 IT staff who are responsible for installing and maintaining
the system.
Chapter 4 Requirements engineering 38
Stakeholders in the MHC-PMS
 A medical ethics manager who must ensure that the
system meets current ethical guidelines for patient care.
 Health care managers who obtain management
information from the system.
 Medical records staff who are responsible for ensuring
that system information can be maintained and
preserved, and that record keeping procedures have
been properly implemented.
Chapter 4 Requirements engineering 39
The requirements elicitation and analysis
process
40Chapter 4 Requirements engineering
Process activities
 Requirements discovery
 Interacting with stakeholders to discover their requirements.
 Requirements classification and organisation
 Groups related requirements and organises them into coherent
clusters.
 Prioritisation and negotiation
 Prioritising requirements and resolving requirements conflicts.
 Requirements specification
 Requirements are documented and input into the next round of
the spiral.
Requirements prioritisation
 MoSCoW criteria
 Must have – mandatory requirement fundamental to the system
 Should have – important requirement that may be omitted
 Could have – truly optional requirement
 Want to have – requirement that can wait for later releases
 RUP attributes
 Status – Proposed/Approved/Rejected/Incorporated
 Benefit – Critical/Important/Useful
 Effort – number of person days/functional points/etc.
 Risk – High/Medium/Low
 Stability – High/Medium/Low
 Target Release – future product version
Problems of requirements elicitation
 Stakeholders don’t know what they really want.
 Stakeholders express requirements in their own terms.
 Different stakeholders may have conflicting
requirements.
 Organisational and political factors may influence the
system requirements.
 The requirements change during the analysis process.
New stakeholders may emerge and the business
environment may change.
43Chapter 4 Requirements engineering
Interviewing
 Formal or informal interviews with stakeholders are part
of most RE processes.
 Types of interview
 Closed interviews based on pre-determined list of questions
 Open interviews where various issues are explored with
stakeholders.
 Effective interviewing
 Be open-minded, avoid pre-conceived ideas about the
requirements and are willing to listen to stakeholders.
 Prompt the interviewee to get discussions going using a
springboard question, a requirements proposal, or by working
together on a prototype system.
Chapter 4 Requirements engineering 44
Ethnography
 A social scientist spends a considerable time observing
and analysing how people actually work.
 People do not have to explain or articulate their work.
 Social and organisational factors of importance may be
observed.
 Ethnographic studies have shown that work is usually
richer and more complex than suggested by simple
system models.
45Chapter 4 Requirements engineering
Requirements validation
 Concerned with demonstrating that the requirements
define the system that the customer really wants.
 Requirements error costs are high so validation is very
important
 Fixing a requirements error after delivery may cost up to 100
times the cost of fixing an implementationerror.
46Chapter 4 Requirements engineering
Requirements validation
 Consistency
 Are there any requirements conflicts?
 Completeness
 Are all functions required by the customer included?
 Realism
 Can the requirements be implemented given available budget
and technology
 Verifiability
 Can the requirements be checked?
47Chapter 4 Requirements engineering
Requirements validation techniques
 Requirements reviews
 Systematic manual analysis of the requirements.
 Prototyping
 Using an executable model of the system to check requirements.
 Test-case generation
 Developing tests for requirements to check testability.
48Chapter 4 Requirements engineering
Requirements reviews
 Regular reviews should be held while the requirements
definition is being formulated.
 Both client and contractor staff should be involved in
reviews.
 Reviews may be formal (with completed documents) or
informal. Good communications between developers,
customers and users can resolve problems at an early
stage.
49Chapter 4 Requirements engineering
Review checks
 Besides consistency, completeness, realism and
verifiability, reviews check:
 Comprehensibility
 Is the requirement properly understood?
 Traceability
 Is the origin of the requirement clearly stated?
 Adaptability
 Can the requirement be changed without a large impact on other
requirements?
50Chapter 4 Requirements engineering
Requirements management
 Requirements management is the process of managing
changing requirements during the requirements
engineering process and system development.
 New requirements emerge as a system is being
developed and after it has gone into use.
 You need to keep track of individual requirements and
maintain links between dependent requirements so
that you can assess the impact of requirements
changes. You need to establish a formal process for
making change proposals and linking these to system
requirements.
51Chapter 4 Requirements engineering
Requirements evolution
52Chapter 4 Requirements engineering
Changing requirements
 The business and technical environment of the system
always changes after installation.
 New hardware may be introduced, it may be necessary to
interface the system with other systems, business priorities
may change (with consequent changes in the system support
required), and new legislation and regulations may be
introduced that the system must necessarily abide by.
 The people who pay for a system and the users of that
system are rarely the same people.
 Large systems usually have a diverse user community,
with many users having different requirements and
priorities that may be conflicting.
Chapter 4 Requirements engineering 53
Requirements management planning
 Establishes the level of requirements management detail
that is required.
 Requirements management decisions:
 Requirements identification Each requirement must be uniquely
identified so that it can be cross-referenced with other requirements.
 A change management process This is the set of activities that
assess the impact and cost of changes.
 Traceability policies These policies define the relationships
between requirements, and between the requirements and the
system design that should be recorded.
 Tool support Tools that may be used range from specialist
requirements management systems to spreadsheets and simple
database systems.
Chapter 4 Requirements engineering 54
Requirements change management
 Deciding if a requirements change should be accepted
 Problem analysis and change specification
• During this stage, the problem or the change proposal is analyzed
to check that it is valid. This analysis is fed back to the change
requestor who may respond with a more specific requirements
change proposal, or decide to withdraw the request.
 Change analysisand costing
• The effect of the proposed change is assessed using traceability
information and general knowledge of the system requirements.
Once this analysis is completed, a decision is made whether or not
to proceed with the requirements change.
 Change implementation
• The requirements document and the system design and
implementation are modified. Ideally, the document should be
organized so that changes can be easily implemented.
Chapter 4 Requirements engineering 55
Key points
 You can use a range of techniques for requirements
elicitation including interviews, use-cases discussion
and ethnography.
 Requirements validation is the process of checking the
requirements for validity, consistency, completeness,
realism and verifiability.
 Business, organizational and technical changes
inevitably lead to changes to the requirements for a
software system. Requirements management is the
process of managing and controlling these changes.
Chapter 4 Requirements engineering 56
UML Use Case Diagram
Lecture 2/Part 4
57Chapter 4 Requirements engineering
Outline
 Use Case modelling
 System boundary – subject
 Use cases
 Actors
 Textual Use Case specification
 Advanced Use Case modelling
 Actor generalisation
 Use case generalisation
 «include»
 «extend»
58Chapter 4 Requirements engineering
© Clear View Training 2010 v2.6 59
Use case modelling
 Use case modelling is a form of requirements
engineering
 Use case modelling proceeds as follows:
 Find the system boundary
 Find actors
 Find use cases
• Use case specification
• Scenarios
 It lets us identify the system boundary, who or what uses
the system, and what functions the system should offer
© Clear View Training 2010 v2.6 60
The subject
 Before we can build anything, we need to know:
 Where the boundary of the system lies
 Who or what uses the system
 What functions the system should offer to its
users
 We create a Use Case model containing:
 Subject – the edge of the system
• also known as the system boundary
 Actors – who or what uses the system
 Use Cases – things actors do with the system
 Relationships – between actors and use cases
SystemName
subject
© Clear View Training 2010 v2.6 61
What are actors?
 An actor is anything that interacts directly with the
system
 Actors identify who or what uses the system and so indicate
where the system boundary lies
 Actors are external to the system
 An Actor specifies a role that some external entity adopts
when interacting with the system
Customer
«actor»
Customer
© Clear View Training 2010 v2.6 62
Identifying Actors
 When identifying actors ask:
 Who or what uses the system?
 What roles do they play in the interaction?
 Who installs the system?
 Who starts and shuts down the system?
 Who maintains the system?
 What other systems use this system?
 Who gets and provides information to the system?
 Does anything happen at a fixed time?
Time
© Clear View Training 2010 v2.6 63
What are use cases?
 A use case is something an actor needs the system to
do. It is a “case of use” of the system by a specific actor
 Use cases are always started by an actor
 The primary actor triggers the use case
 Zero or more secondary actors interact with the use case in
some way
 Use cases are always written from the point of view of
the actors
PlaceOrder GetStatusOnOrder
© Clear View Training 2010 v2.6 64
Identifying use cases
 Start with the list of actors that interact with the system
 When identifying use cases ask:
 What functions will a specific actor want from the system?
 Does the system store and retrieve information? If so, which
actors trigger this behaviour?
 What happens when the system changes state (e.g. system start
and stop)?Are any actors notified?
 Are there any external events that affect the system? What
notifies the system about those events?
 Does the system interact with any external system?
 Does the system generate any reports?
© Clear View Training 2010 v2.6 65
The use case diagram
MailOrder System
PlaceOrder
SendCatalogue
CancelOrder
CheckOrderStatusCustomer
ShipProduct
ShippingCompany
Dispatcher
communication
relationship
actor
subjectname
system boundary
MailOrder System use case diagram
use case
© Clear View Training 2010 v2.6 66
Textual use case specification
Use case:PaySalesTax
Primary actors:
Time
Preconditions:
1. It is the end of the businessquarter.
Postconditions:
1.The Tax Authority receivesthe correctamountof Sales Tax.
Main flow:
The use case starts when it is the end of the business quarter.
The system determinesthe amountof Sales Tax owed to the Tax
Authority.
The system sendsan electronic paymentto the Tax Authority.
1.
2.
3.
use case name
the actors involved in the
use case
the system state before
the use case can begin
the actualsteps of the use
case
the system state when the
use case has finished
Alternative flows:
None.
alternative flows
ID: 1use case identifier
Brief description:
Pay Sales Tax to the Tax Authority at the end of the business quarter.
brief description
implicittime actor
Secondary actors:
TaxAuthority
© Clear View Training 2010 v2.6 67
Naming use cases
 Use cases describe something that happens
 They are named using verbs or verb phrases
 Naming standard 1: use cases are named using
UpperCamelCase e.g. PaySalesTax
1 UML 2 does not specify any naming standards.
All naming standards here are based on industry best practice.
© Clear View Training 2010 v2.6 68
Pre and postconditions
 Preconditions and postconditions
are constraints
 Preconditions constrain the state of
the system before the use case can
start
 Postconditions constrain the state
of the system after the use case has
executed
 If there are no preconditions or
postconditions write "None" under
the heading
Preconditions:
1. A valid user has logged on to the
system
Postconditions:
1. The order has been marked
confirmed and is saved by the system
Use case: PlaceOrder
© Clear View Training 2010 v2.6 69
Main flow
 The flow of events lists the steps in a use case
 It always begins by an actor doing something
 A good way to start a flow of events is:
1) The use case starts when an <actor> <function>
 The flow of events should be a sequence of short steps that are:
 Declarative
 Numbered,
 Time ordered
 The main flow is always the happy day or perfect world scenario
 Everything goes as expected and desired, and there are no errors,
deviations and interrupts
 Alternatives can be shown by branching or by listing under Alternative
flows (see later)
<number> The <something> <some action>
© Clear View Training 2010 v2.6 70
Branching within a flow: IF
 Use the keyword IF to
indicate alternatives
within the flow of events
 There must be a
Boolean expression
immediately after IF
 Use indentation and
numbering to indicate
the conditional part of
the flow
 Use ELSE to indicate
what happens if the
condition is false
Use case: ManageBasket
Primary actors:
Customer
Preconditions:
1. The shopping basket contents are visible.
Postconditions:
None.
Main flow:
The use case starts when the Customer selects an item in the
basket.
IF the Customer selects "delete item"
IF the Customer types in a new quantity
1.
2.
3.
The system removes the item from the basket.2.1
The system updates the quantity of the item in the basket.3.1
ID: 2
Brief description:
The Customer changes the quantity of an item in the basket.
Alternative flows:
None.
Secondary actors:
None.
© Clear View Training 2010 v2.6 71
Repetition within a flow: FOR
 We can use the
keyword FOR to
indicate the start of a
repetition within the
flow of events
 The iteration
expression immediately
after the FOR
statement indicates the
number of repetitions of
the indented text
beneath the FOR
statement.
ID: 3
Actors:
Customer
Preconditions:
None.
Main flow:
1. The use case starts when the Customer selects "find product".
2. The system asks the Customer for search criteria.
3. The Customer enters the requested criteria.
4. The system searches for products that match the Customer's criteria.
5. FOR each product found
5.1. The system displays a thumbnail sketch of the product.
5.2. The system displays a summary of the product details.
5.3. The system displays the product price.
Postconditions:
None.
Alternative flows:
NoProductsFound
Use case: FindProduct
Brief description:
The system finds some products based on Customer search criteria and
displays them to the Customer.
© Clear View Training 2010 v2.6 72
Repetition within a flow: WHILE
 We can use the
keyword WHILE to
indicate that something
repeats while some
Boolean condition is
true
ID: 4
Primary actors:
Customer
Preconditions:
None.
Main flow:
1. The use case starts when the Customer selects "show company details".
2. The system displays a web page showing the company details.
3. WHILE the Customer is browsing the company details
4. The system searches for products that match the Customer's criteria.
4.1. The system plays some background music.
4.2. The system displays special offers in a banner ad.
Postconditions:
1. The system has displayed the company details.
2. The system has played some background music.
3. The systems has displayed special offers.
Alternative flows:
None.
Use case: ShowCompanyDetails
Brief description:
The system displays the company details to the Customer.
Secondary actors:
None
© Clear View Training 2010 v2.6 73
Branching: Alternative flows
 We may specify one or more
alternative flows through the flow of
events:
 Alternative flows capture errors,
branches, and interrupts
 Alternative flows never return to
the main flow
 Potentially very many alternative
flows! You need to manage this:
 Pick the most important alternative
flows and document those.
 If there are groups of similar
alternative flows - document one
member of the group as an
exemplar and (if necessary) add
notes to this explaining how the
others differ from it.
main flow
alternative flows
Use case
Only document enough alternative flows to
clarify the requirements!
© Clear View Training 2010 v2.6 74
Referencing alternative flows
 List the names of the
alternative flows at the
end of the use case
 Find alternative flows
by examining each
step in the main flow
and looking for:
 Alternatives
 Exceptions
 Interrupts
Alternative
flows
Main flow:
Use case: CreateNewCustomerAccount
Preconditions:
None.
Brief description:
The system creates a new account for the Customer.
Postconditions:
1. A new account has been created for the Customer.
Alternative flows:
InvalidEmailAddress
InvalidPassword
Cancel
The use case begins when the Customer selects "create
new customer account".
WHILE the Customer details are invalid
The system creates a new account for the Customer.
The system asks the Customer to enter his or her details
comprising email address, password and password
again for confirmation.
The system validates the Customer details.
1.
2.
3.
2.1.
2.2
ID: 5
Primary actors:
Customer
Secondary actors:
None.
© Clear View Training 2010 v2.6 75
An alternative flow example
 The alternative flow may be triggered instead of the main flow - started by an actor
 The alternative flow may be triggered aftera particularstep in the main flow - after
 The alternative flow may be triggered at any time during the main flow - at any time
notice how we
name and number
alternative flows
always indicatehow the
alternative flow begins.
In this case it starts after
step 2.2 in the main flow
Alternative flow:
Alternative flow: CreateNewCustomerAccount:InvalidEmailAddress
Preconditions:
1. The Customer has entered an invalid email address
Primary actors:
Customer
Postconditions:
None.
The alternative flow begins after step 2.2. of the main flow.
The system informs the Customer that he or she entered an
invalid email address.
1.
2.
ID: 5.1
Brief description:
The system informs the Customer that they have entered an invalid
email address.
Secondary actors:
None.
© Clear View Training 2010 v2.6 76
Advanced Use Case modelling
 We have studied basic use case analysis, but there are
relationships that we have still to explore:
 Actor generalisation
 Use case generalisation
 «include» – between use cases
 «extend» – between use cases
© Clear View Training 2010 v2.6 77
Actor generalization - example
 The Customer and the
Sales Agent actors are
very similar
 They both interact with
List products, Order
products,Accept payment
 Additionally, the Sales
Agent interacts with
Calculate commission
 Our diagram is a mess –
can we simplify it?
Sales system
ListProducts
OrderProducts
AcceptPayment
CalculateCommission
Customer
SalesAgent
© Clear View Training 2010 v2.6 78
Actor generalisation
 If two actors communicate
with the same set of use
cases in the same way,
then we can express this as
a generalisation to another
(possibly abstract) actor
 The descendent actors
inherit the roles and
relationships to use cases
held by the ancestor actor
 We can substitute a
descendent actor anywhere
the ancestor actor is
expected. This is the
substitutability principle
Sales system
ListProducts
OrderProducts
AcceptPayment
CalculateCommission
Purchaser
SalesAgentCustomer
ancestor
or parent
descendents orchildren
generalisation
abstractactor
Use actor generalization when it simplifies
the model
© Clear View Training 2010 v2.6 79
Use case generalisation
 The ancestor use case must be a more general case of one or more
descendant use cases
 Child use cases are more specific forms of their parent
 They can inherit, add and override features of their parent
Sales system
FindProduct
FindBook FindCD
Customer
Use case generalization semantics
Use case element Inherit Add Override
Relationship Yes Yes No
Extension point Yes Yes No
Precondition Yes Yes Yes
Postcondition Yes Yes Yes
Step in main flow Yes Yes Yes
Alternative flow Yes Yes Yes
© Clear View Training 2010 v2.6 80
«include»
 The base use case executes
until the point of inclusion:
include(InclusionUseCase)
 Controlpassesto the
inclusion use casewhich
executes
 When the inclusion use case
is finished,controlpasses
backto the base use case
which finishesexecution
 Note:
 Base use cases are not
complete withoutthe
includeduse cases
 Inclusion use cases may be
complete use cases,orthey
may justspecify a fragment
of behaviourforinclusion
elsewhere
Personnel System
FindEmployeeDetails
ChangeEmployeeDetails
DeleteEmployeeDetails
Manager
ViewEmployeeDetails
«include»
«include»
«include»
base use case
inclusion
use caseinclude
relationship
When use cases share common behaviour
we can factor this out into a separate
inclusion use case and «include» it in base
use cases
© Clear View Training 2010 v2.6 81
«include» example
Use case:ChangeEmployeeDetails
Primary actors:
Manager
Preconditions:
1.The Manageris logged on to the system.
Postconditions:
1.The employee details have beenchanged.
Main flow:
include(FindEmployeeDetails).
The system displays the employee details.
The Managerchangesthe employee
details.
…
1.
2.
3.
ID: 1
Brief description:
The Managerchangesthe employee details.
Alternative flows:
None.
Use case:FindEmployeeDetails
Primary actors:
Manager
Preconditions:
1.The Manageris logged on to the system.
Postconditions:
1.The system has found the employeedetails.
Main flow:
The Managerenters the employee'sID.
The system finds the employee details.
1.
2.
ID: 4
Brief description:
The Managerfinds the employee details.
Alternative flows:
None.
Seconday actors:
None
Seconday actors:
None
© Clear View Training 2010 v2.6 82
«extend»
 «extend» is a way of adding
new behaviour into the base
use case by inserting
behaviour from one or more
extension use cases
 The base use case specifies
one or more extension points
in its flow of events
 The extension use case may
contain several insertion
segments
 The «extend» relationship
may specify which of the base
use case extension points it is
extending
Library system
IssueFineBorrowBook
FindBook
Librarian
ReturnBook
«extend»
base use case
extend
relationship extension
use case
The extension use case inserts behaviour into
the base use case.
The base use case provides extension points,
but does not know about the extensions.
© Clear View Training 2010 v2.6 83
Base use case
 There is an extension point overdueBookjustbefore step 4 of the flow of events
 Extension points are notnumbered,as they are not part of the flow
Use case: ReturnBook
Secondary actors:
None.
Preconditions:
1. The Librarian is logged on to the system.
Postconditions:
1. The book has been returned.
Main flow:
The Librarian enters the borrower's ID number.
The system displays the borrower's details including the list of
borrowed books.
The Librarian finds the book to be returned in the list of books.
The Librarian returns the book.
…
1.
2.
3.
4.
ID: 9
Brief description:
The Librarian returns a borrowed book.
Alternative flows:
None.
ReturnBook
extension points
overdueBook
IssueFine
«extend»
(overdueBook)
extension point: overdueBook
extension
point
base use case
extension use case
extension
point name
Primary actors:
Librarian
© Clear View Training 2010 v2.6 84
Extension use case
 Extension use cases have one or more insertion segments which are
behaviour fragments that will be inserted at the specified extension points in
the base use case
Extension Use case: IssueFine
Primary actors:
Librarian
Segment 1 preconditions:
1. The returned book is overdue.
Segment 1 postconditions:
1. The fine has been recorded in the system.
2. The system has printed out the fine.
Segment 1 flow:
The Librarian enters details of the fine into the system.
The system prints out the fine.
1.
2.
ID: 10
Brief description:
Segment 1: The Librarian records and prints out a fine.
ReturnBook
extension points
overdueBook
IssueFine
the single insertion
segment in IssueFine is
inserted at the
overdueBook insertion
point in the ReturnBook
use case
Secondary actors:
None.«extend»
(overdueBook)
© Clear View Training 2010 v2.6 85
Multiple insertion points
 If more than one extension point is
specified in the «extend» relationship
then the extension use case must
have the same number of insertion
segments
Extension Use case: IssueFine
Secondary actors:
None.
Segment 1 preconditions:
1. The returned book is overdue.
Segment 1 postconditions:
1. The fine has been recorded in the system.
2. The system has printed out the fine.
Segment 1 flow:
The Librarian enters details of the fine into the system.
The system prints out the fine.
1.
2.
ID: 10
Brief description:
Segment 1: The Librarian records and prints out a fine.
Segment 2: The Librarian accepts payment for a fine.
ReturnBook
extension points
overdueBook
payFine
IssueFine
the first segment in IssueFine is
inserted at overdueBook and
the second segment at payFine
Segment 2 preconditions:
1. A fine is due from the borrower.
Segment 2 postconditions:
1. The fine is recorded as paid.
2. The system has printed a receipt for the fine.
Segment 2 flow:
The Librarian accepts payment for the fine from the borrower.
The Librarian enters the paid fine in the system.
The system prints out a receipt for the paid fine.
1.
2.
3.
Primary actors:
Librarian«extend»
(overdueBook, payFine)
© Clear View Training 2010 v2.6 86
Conditional extensions
 We can specify conditions on «extend» relationships
 Conditions are Boolean expressions
 The insertion is made if and only if the condition evaluates to true
IssueFine
ReturnBook
extension points
overdueBook
payFine
IssueWarning
condition
«extend»
(overdueBook)
[firstoffence]
«extend»
(overdueBook)
[!firstoffence]
© Clear View Training 2010 v2.6 87
Requirements tracing
 Given that we can capture functional requirements in a
requirements model and in a use case model we need
some way of relating the two
 There is a many-to-many relationship between
requirements and use cases:
 One use case covers many individual functional requirements
 One functional requirement may be realised by many use
cases
 Hopefully we have CASE support for requirements tracing:
 With UML tagged values, we can assign numbered
requirements to use cases
 We can capture use case names in our Requirements
Database
 If there is no CASE support, we can create a Requirements
Traceability matrix
R1
R2
R3
R4
R5
U1 U2 U3 U4
Use cases
Requirements
Requirements
Traceability
Matrix
© Clear View Training 2010 v2.6 88
When to use use case analysis
 Use cases describe system behaviour from the point of
view of one or more actors. They are the best choice
when:
 The system is dominated by functional requirements
 The system has many types of user to which it delivers different
functionality
 The system has many interfaces
 Use cases are designed to capture functional
requirements. They are a poor choice when:
 The system is dominated by non-functional requirements
 The system has few users
 The system has few interfaces
© Clear View Training 2010 v2.6 89
Key points
 We have seen how to capture functional requirements
with use cases
 We have looked at:
 Use cases
 Actors
 Branching with IF
 Repetition with FOR and WHILE
 Alternative flows
© Clear View Training 2010 v2.6 90
Key points
 We have learned about techniques for advanced use
case modelling:
 Actor generalisation
 Use case generalisation
 «include»
 «extend»
 Use advanced features with discretion only where they
simplify the model!