Block I: From domain to requirements

Unit 3: From domain modelling to requirements

1
 This unit looks at how modelling can help with the process of
capturing and documenting requirements.
 UML activity diagrams are used to model workflows and
understand business processes in a domain.
 UML use cases are used to record and document chunks of
functionality required by the users of a system, and the
interactions with that system.
 You will explore how activity and use case modelling can be used,
in consultations with the users, to help the developer to identify
which interfaces are needed to complete required activities, and to
build prototypes for rapid feedback

Note that: All SAQs and Exercises in this unit are required.

2
 Section 1: Introduction
 In this unit, we study some well established techniques for capturing and
 documenting user requirements and system behaviour.
 We start by looking at the business domain as the context in which a
software solution may be applied.
 In this module we will discuss enough of the business to understand the
context and the requirements for a system within that context.
 Section 2 introduces the concepts of business rules and business
processes, together with activity diagrams as the technique for modelling
these processes.
 Sections 3 and 4 of this unit introduce use cases as a tool for
requirements.
 Finally, in Section 5, we consider how prototyping can help with
requirements engineering.

3
 Business rules constrain how a business is run.
 There is a clear distinction between the business processes
and the constraints.
 Example, in a car rental company:
- renting a car (business process);
- the car allocated is the lowest mileage car that is available in the
chosen group. (business rule)
 Business rules need to be identified and recorded:
1. to provide quick and easy access whenever there is a change.
2. business rules are the basis of decision making
 Business rules that apply to the whole business should be
represented separately from project specific models.

4
 Section 2: Business rules and business processes

 Business rules need to be correctly represented, and they

should support the business processes and strategy.
 Business rules should be represented independently of
other models, to facilitate analysis.
 They should be represented in a well defined and structured
language.
 Traceability of business rules should be possible from the
business needs to the software solution.
 Any reasonable representation of business rules should
support their verification and validation before any system
is built.

5
 Section 2: Business rules and business processes

 Verification is the set of activities that ensure that the rules

are correctly modeled.
 Verification can be done automatically if the rules are well
specified; the models in development should be checked to
comply with these rules.
 Validation ensures that they are the most appropriate rules
for the business.
 Validation can only be done through review by the
stakeholders; are the rules the ones intended for what the
business wants to achieve?

6
 Section 2: Business rules and business processes

Business Rules representation techniques:

 The language used in expressing business rules should be well defined

and structured, so that verification can be made easier if not automatic
1. Using natural language to make it easy for business people to
understand it.
2. Using UML and OCL;
- OCL is Object Constraint Language, which is a formal language used to represent
constraints in UML.
 UML does not provide an explicit notation for business rules because it
does not:
- facilitate separate recording of the rules (they always appear as part of other models);
- facilitate their analysis, validation and change;
- facilitate their traceability from the business needs to the software solution.

7
 Section 2: Business rules and business processes

 Business processes define what is done in a business, by

whom, in what order, needing which resources, and with
what consequences.
 Business processes are important to:
- get an understanding of what a business does,
- and to gain the domain expertise needed to develop software
solutions in the business context.
 Business processes are represented using UML activity
diagrams.
- An activity diagram shows a process as a set of activities, showing
their sequences, and where activities can be carried out in parallel.
- It can also be extended to show which person is responsible for which
activity.
 An activity could be a task that a person or a computer might perform.

8
 Section 2: Business rules and business processes

Activity diagram can be an aid:

1. Help investigate the workflow of control from one activity to another.

2. Help in understanding the basic behavior of a system, and understand the
business situation.
3. Can be used to model concurrent systems.
4. Can record scenarios of use cases.
5. Can help identify the stages at which each role requires some interaction with
the process. This is of particular benefit when we want to investigate the steps
that people take in order to do their jobs.

 Workflow is defined as a sequence of activities that

produces a result of observable value.

9
Section 2: Business rules and business processes

10
 Section 2: Business rules and business processes

Examples on activity diagrams

Example-1
 Suppose, after a hard day’s work, you decide to make yourself a hot drink. What
do you do to achieve that goal? What are the actions and how do you organise
them?
 We start with a process called make hot drink. At the centre of this task is boiling
water in a kettle.
 Usually, there are two steps.
1 Fill the kettle with water.
2 Boil the water.
 There are also some decisions to be made, such as the choice of beverage. We
will consider instant coffee (as a particular scenario) to begin with. Finally, you
need a cup to drink from.

 Figure 1 in the next slide shows an activity diagram that models the process of making a hot drink of
instant coffee with milk. It shows one way of preparing a cup of coffee. ‘… Pour boiled water into a cup
containing coffee. Add milk. Drink coffee.’

11
Section 2: Business rules and business processes

Figure 1: Activity diagram for making a cup of coffee

12
 Section 2: Business rules and business processes

 Elements and symbols of activity diagram in Figure-1

 The basic elements of an activity diagram are activities and transitions. The
completion of an activity triggers an outgoing transition. Similarly, once the
incoming transition has been triggered an activity may commence.
 In an activity diagram, activities are shown as rounded boxes; transitions are
shown as lines with arrows.
 There are two predefined activities, start and stop, which is represented as filled
circles, a diagram may include more than one stop node if it makes it clearer.
 The Figure shows two synchronisation bars, denoted by thick horizontal lines.
 The upper one denotes a fork and the lower one a join. The upper bar allows for
separate activities to be carried out in parallel, so between the two
synchronisation bars the two separate strands can be performed concurrently.
 In UML, a note (with annotation) is shown as a rectangle with the top right-hand
corner folded down.
 A dashed line is used to attach the note to the model element to which it refers.

13
 Section 2: Business rules and business processes

Example 2: Redraw the activity diagram of preparing a cup coffee so that it allows to
check if cup is clean continue the process, if not wash the cup

Figure 2 Using decision diamonds

14
 Section 2: Business rules and business processes

 Elements and symbols of activity diagram in Figure-2

 In Figure 2, the flow between activities is constrained with a Boolean test, known
as a guard, which is represented inside a pair of square brackets.
 Each of the transitions leaving the first decision diamond has a guard to
determine which path should be taken under a given condition.
 One outgoing transition should always be taken – this means that exactly one of
the relevant guards must always evaluate to true.
 A diamond shape is also used as a merge node, which brings together
alternative mutually exclusive flows, as shown in Figure 2.
 A merge node will be reached only by one of the alternative flows and has a
single outgoing flow.
 An activity has only one transition into and out of it.
 This is enforced by ‘decision’ and ‘merge’ nodes for alternative outgoing and
incoming transitions, and by synchronisation bars for concurrent outgoing (fork)
and incoming (join) transitions.

15
 Section 2: Business rules and business processes

Example 3: Redraw the activity diagram of figure 1 to allow the choice between coffee
with milk and coffee without milk.

Figure 3 Using decision diamonds

16
 Section 2: Business rules and business processes

Example 4: Draw an
activity diagram to
illustrate the preparation
of a pot of tea, which
replaces the activities
relating to coffee shown
in Figure 1. The new
diagram should allow the
choice of both milk and
sugar when the tea is
poured.

Figure 4 Using decision diamonds

17
 Section 2: Business rules and business processes

Example-5

Consider the lending process from a library :

"A typical lending library keeps a stock of books for the use of its members. Each
member can look on the library shelves to select a copy to borrow. then take out a
number of books, up to a certain limit. After a given period of time, the library
expects members to return the books that they have on loan.

When borrowing books, a member is expected to wait in queue, then to hand their
chosen books to the librarian, who records each new loan before issuing the books
to the member. After that the librarian will prepare for next member in the queue.
When a book is on loan to a member, it is associated with that member: possession
of the book passes from the library to the member for a defined period. The normal
loan period for each book is two weeks. If the member fails to bring the book back
on or before the due date, the library imposes a fine."

18
 Section 2: Business rules and business processes

Example-5 (contd.)

A. What are the business process and business rules in the above
system.
 Business processes: find book on a shelf; wait in the queue; issue a
book, and return a book.
 Business rules:
- There is a limit to the number of books a member can take out.
- A loan is for a period that is normally two weeks.
- Late returns incur a fine.

B. Draw an activity diagram for issuing a copy of a book

19
 Section 2: Business rules and business processes

Activity diagram for issuing a copy of a book (using two swimlanes separated by a vertical line)

Figure 5 Issuing a copy of book

20
 Section 2: Business rules and business processes

 Swinlanes

 Swimlanes group activities associated with different roles.

 The swimlanes show the role that is responsible for each activity.
 Activity diagrams represent the sequence of activities.
 When you are modelling a workflow that involves more than one role, it is
possible to identify which role is responsible for a particular activity.
 An activity diagram can help identify the stages at which each role
requires some interaction with the process.

 In Figure-5 The left-hand swimlane contains the activities that a library

member performs when borrowing a book, while the right-hand swimlane
shows the library’s selfservice system workflow for the same process
(‘issue copy of book’).

21
 Section 2: Business rules and business processes

Example 6: Assume you have the below activity diagram of returning a copy of a book to library.
List the sequence of activities with showing roles of people.

One possible solution is:

A. The member brings the
book back into the
library.
B. The member will join the
queue till the librarian
record the returned
book,
C. as soon as the librarian
finish the process, the
member leave the
queue.
D. The librarian will put the
book aside and prepare
for next member in the
queue.
Figure 6 Returning a copy of book

22
 Section 2: Business rules and business processes

Example 7:

Use figure 5 and 6 to produce a single activity diagram that models the
borrowing and returning of books, based on the following assumptions:

 You do not need to consider fines for overdue books.

 The librarian places returned books onto a trolley (which will be used to
carry the books back to the library’s shelves at certain times during the
day – an activity which need not be included at this stage).
 There is just one queue to deal with members.

23
Section 2: Business rules and business processes

Example 7 Solution

24
Section 2: Business rules and business processes
Activity diagrams Symbols (contd.)

25
 Section 2: Business rules and business processes

 Summary of section

 Business processes define the activities that take place, their ordering
and the roles required to carry them out.
 Business processes can be represented by activity diagrams.
 Activity diagrams are a way of understanding the workflows within the
business domain.
 They allow you to record the things that users do or want to do.
 From a simple problem description, you can show the flow of control
between the activities that are carried out by different roles.

26
 Section 3: Simple use case models

 This section introduces a means of defining what a proposed system

should do from a user’s perspective.
 This can provide the basis for a contract between the customer and the
developer
 Your aim is to construct a software system that will meet the needs of its
users. Hence you must identify ‘who does what’.
 To do this, you explore the problem description, any domain models and
the initial set of user requirements to determine the people involved, the
work that they do and the events that trigger some work to be done.
 You are likely to identify a variety of people, some of whom may be
playing a number of different roles and may be associated with different
business events.
 You should ask yourself who the actual users will be and what tasks
they must perform with the aid of your software system.

27
 Section 3: Simple use case models

Use case and its description

 Each use case description should contain the following parts in minimum:
- Use case identifier and name
- Initiator: name of the actor who initiates the process
- Precondition: a condition that must hold before this use case can be
carried out..
- Postcondition: a condition that must hold after the use case has been
completed.
- Main success Scenario: a single sequence of steps that describe the
main success scenario. You can number the steps. A scenario is an
instance of a use case.
- Goal: a short description of the goal of the use case;
 Exceptions to the normal behavior for a use case are common, especially
where actors decide to cancel a use case without completing it.

28
 Section 3: Simple use case models

The main elements in use case diagram:

The actors, represented by stick figures;

The use cases, represented by ovals, and are used

to represent tasks.;

The relationships between actors and use cases,

represented by lines.

Note symbol: is used to clarify an aspect or a task,

it can be used with any UML diagram.

A dashed line is used to attach the note to the

model element to which it refers.

29
 Section 3: Simple use case models

Use case diagram can help in the following software development

aspects:
 Capturing and eliciting requirements;

 Representing requirements;

 Planning iterations of development;

 Validating software systems.

Use case diagram can be an aid on:

 Defining the scope of a system, as they represent the interaction of a
system with its environment.
 Helping with project planning and quality assurance.

 Acting as a discussion tool between developer and user, and offer a

common language for agreeing on the functions of the software system.

30
 Section 3: Simple use case models

 Use case analysis is related to an activity called user-centred design,

which is part of the discipline of human–computer interaction (HCI).
 User-centred design differs from other approaches to design because it
focuses on people, their work, their environment, and how technology can
be best designed and deployed to support them.
 User-centred design and use cases are more concerned with external
functionality than with how internal components of a software system
interact.
 One use case represents one of the possible ways a system can be
used.
 The use cases for a software system are a record of the intended user-
visible behaviour of the system.
 The contents of the use case represent some task – or coherent unit of
functionality, as UML defines it – which the software system is meant to
perform.

31
 Section 3: Simple use case models

Use case models: Examples

Example 1: a simple use case diagram for the main tasks in a hotel system: make
reservation, check-in, and check-out, where the reservation can be done by the receptionist
or a guest (by phone / Web).

Figure : A use case diagram for a hotel chain

32
 Section 3: Simple use case models

System Boundary
 The system boundary
determines the scope of the
system.
 It distinguishes between internal
and external components.
 The external components are
actors and the internal
components are the use cases.
 In UML it is optional to use system
boundary notation.
 A solid box drawn around the use
cases with the actors located
outside it represents the system
boundary.
 We use system boundary notation Figure : A use case diagram for a hotel chain, showing the
when the system is complex and system boundary
includes several subsystems.

33
 Section 3: Simple use case models

Use case and its description

 A scenario is describes a sequence of interactions between the system
and some actors.
 In Each use case there is a set of possible scenarios. Where the main
scenario is the successful scenario where nothing goes wrong and the use
case is achieved.
For example: there are two scenarios for making reservation in a hotel:
 Main success scenario

 The guest wants to reserve a double room at the Hotel for 14 July. A
double room is available for that date, and the reservation is done.
 Unsuccessful scenario

 The guest wants to reserve a single room at the Hotel for the first week of
August. There is no single room that is free for seven days in August, but
there is one room available for four days and another one for the following
three days. The system presents that option to the guest, who rejects it.

34
 Section 3: Simple use case models

Example 9: What pre and post condition you can obtain from the below
description of check in process?
Upon arrival, each guest provides the reservation number for his or her
reservation to the hotel’s receptionist, who enters it into the software system.
The software system reveals the details of that reservation so that each guest
can confirm them. The software system allocates an appropriate room to that
guest and opens a bill for the duration of the stay. The receptionist issues a
key for the room.

Solution
 Precondition: There must be a reservation for the guest, and there must be
at least one room available (of the desired type), and the guest must be able
to pay for the room.
 Post-condition: The guest will have been allocated to a room for the period
identified in the reservation, the room will have been identified as being in use
for a specific period, a bill will have been opened for the duration of the stay,
and a key will have been issued.

35
 Section 3: Simple use case models

 The requirements of a
use case can be
captured through
either:
1. a written statement;
2. more formally, the use
of pre- and post-
conditions.
 A textual description of
the “make reservation”
use case in the hotel
domain is shown in the
table 1

36
 Section 3: Simple use case models
Use case and a Scenario

 For each use case there is a set of possible scenarios.

 A scenario is an instance of a use case. A scenario describes a sequence of interactions
between the system and some actors.
 Here are two examples of scenarios.
◦ A member of a lending library wishes to borrow a book, and is allowed to do that as long
as they have no outstanding loans.
◦ Another member wishes to borrow a book, but has exceeded the quota for the number of
books that can be borrowed.
◦ In each scenario the member wishes to borrow a book, but both the circumstances and
outcomes of events are different in each instance.
 A use case includes a complex set of requirements that the system must meet in order to
cope with every eventuality.
 The main success scenario shows the steps normally followed to achieve the stated goal of
the use case.
 But there can be other scenarios for the same use case, each one having different outcomes
depending upon circumstances.

37
 Section 3: Simple use case models

Representing requirements with use case diagrams

 Use cases help with requirements capture through the identification of

actors and tasks in the system.
 For each actor, the set of use cases establishes what that actor requires
from the software system.
 The association between an actor and a use case is about
communication.
 Detailed software requirements can be associated with each step in a
use case scenario. There may be more than one requirement for each
step.

38
 Section 3: Simple use case models

Use cases as a planning aid

 One of the difficulties that developers face is planning delivery times.

 Often a customer can put pressure on the developer to meet a particular deadline.
 It is part of the developer’s job to elicit from the users the use cases that have the
highest priority and to indicate what functionality in the software system can be
met under such constraints.
 The use case descriptions help the developer to:
◦ understand the complexity of each use case
◦ determine which actors interact with each use case and to what extent
◦ establish which use cases carry the most risk
◦ estimate how long each use case is likely to take to implement.
 Understanding these aspects of the system can help developers plan the order in
which the use cases should be developed, and provide an appropriate time frame.
 Several criteria – such as risk, coverage and criticality – can be used to help
establish priorities of use cases.

39
 Section 3: Simple use case models

Use cases and architecture

 Use cases, as standalone chunks of system specification, dictate the sorts of
functionality that need to be provided by the system and constitute an aid for
identifying interfaces in an architecture.
 Use cases can also be grouped in terms of similar functionality, therefore
influencing the architecture of the system.
 Scenarios can be used to check how an architecture meets non-functional
requirements, in particular those that can be affected by the architecture, such as
security and safety requirements.
Use cases and testing
 One way to validate a system is to use the walk-through technique, checking the
functionality related to each use case in turn.
 The walkthrough technique can also be used to elicit system tests where each use
case is required to deal with a number of scenarios – a process known as
verification.
 For each software requirement generated from a step of a scenario, the fit
criterion helps to devise the test.

40
 Section 3: Simple use case models

Use cases and agile development

 Agile development is about ways of working that will support teams in delivering
software on time and that satisfies the customer.
 There are many tips on how use cases can be used in an agile approach
(Cockburn 2002, Cockburn 2003, Leffingwell, 2010), such as:
 write use cases as needed instead of writing all use cases upfront
 write just enough content rather than complete descriptions
 write use cases that are useful for communication, not heavy ones that are
difficult to understand and change.
 To take a more agile approach to development with use cases it is important to
have in mind a set of agile modelling practices such as those proposed by Scott
Ambler (2002). These include:
 following an iterative an incremental approach
 using models that are effective in teamwork and communication
 modelling with simplicity in mind
 thinking on how you are going to test what you model.

41
 Section 3: Simple use case models

Summary of the Section

 In this section, you saw how use case diagrams help you define what a proposed system
should do from a user’s perspective. Use case can also provide a basis for a contract
between the customer and the developer because:
 use case models are used to drive the work to be done in software development
 from a simple problem description, it is possible to draw a use case model that can be
understood by people who are unfamiliar with UML
 each use case should lead to a result that brings some observable value to at least one of
its actors
 the requirements of a use case can be captured through either a written statement or, more
formally, the use of pre- and postconditions
 detailed software requirements can be generated from each step of a scenario of a use case
 scenarios, which are particular sequences of possible actions within a given use case, can
be walked through to determine the extent to which customer’s expectations will be met
 ‘walkthroughs’ of scenarios help with the validation of the architecture of a system
 use cases can be used in an agile approach.

42
 Section 4: More details on use case models

 In the first stage you draw a simple use case, then when you
gain extra details you can refine it.
 UML provides a notation to use generalisation between
actors.
 When two actors share the same behaviour (interacting with
the same use cases) and one of them has some extra
behaviour, then the common behaviour can be associated
with a generalised actor and the more specific behaviour with
the specialised actor.
 For example, in the hotel system both the receptionist and
the guest are allowed to make reservation.
◦ Guest can make reservation through online system;
◦ the receptionist can do reservation on behalf of guest when a guest do
reservation through phone or a fax.

43
 Section 4: More details on use case models

 So the use case could be modified as below:

 We introduce a new actor called
Reserver associated with the make
reservation use case.
 The actors Guest and Receptionist
specializes Reserver.
 Guest can do the same things that a
Reserver can, but may do other things
too.
 By using the open-headed arrow from
Guest to Reserver, you are saying that
a Guest can do the same things that a
Reserver can, but may do something
else that a Reserver does not.
Reserver is a generalised actor and
Guest a specialised one.

Figure : Relating the roles that actors play

44
 Section 4: More details on use case models

Relationship between use cases

 Use cases can be related to one another. There are two very common and
important forms of relationship between use cases: inclusion and extension.
 Inclusion: This is when two or more use cases have a common area of
functionality that can be factored out as a distinct use case.
 The new use case can be used by each of the original use cases, so avoiding
duplication.
 Extension: This is when a use case has a main success scenario but also
alternative scenarios which demand a variation on the original use case –
different or additional actions.
 Each variation can be separated out as a use case that is distinct from but
related to the original use case.
 An extension is conditional while an inclusion is not.
 In UML we use «include» and «extend» stereotypes for representing inclusion
and extension.

45
 Section 4: More details on use case models

 UML is extensible.
◦ It is possible to add to its basic language.
 One way this can be done is by adding stereotypes.
 A stereotype is a way of attaching extra classifications to a model.
 They can be used to specialize a UML element of any kind.
◦ For example, a class can be given the stereotype «abstract».
 A UML stereotype name is always enclosed between double angle
brackets «...», called guillemets.
 For instance, we could add a stereotype «tm354» but we would need to
agree on its meaning.
 Stereotypes can be user-defined.
◦ We can add our own, but we need to agree on its meaning.
 stereotype that are widely used are defined in UML such as «include»
and «extend».

46
 Section 4: More details on use case models

Sharing behaviour between use cases

 In the process of eliciting and specifying requirements, you

may find a certain amount of common behaviour in two or
more of your use cases.
 You can record the shared behaviour in a new use case and
connect it to the use cases that it came from with a dashed
arrow (indicating a dependency relationship) pointing from
the original use case to the new one.
 Hence the dependency arrow is labelled with the «include»
stereotype.

47
 Section 4: More details on use case models

Sharing behavior between use cases - «include»

Example 9: Members of a lending library can borrow a certain number of books and, for any book
borrowed, ask the librarian to extend the loan period. Before the librarian can issue a copy of a book to a
member, there must be a check to make sure that there are no existing reservations for the book by other
members. The same check needs to be carried out when a member presents a book to the librarian for
renewal. This is unconditional behavior (must be performed whenever a loan is extended or a book is
issued).

Figure : Shared behaviour in a lending library

48
 Section 4: More details on use case models

Alternatives to the main success scenario

 The «extend» stereotype indicates a conditional extension to the original

use case, known as alternative behaviour.
 This is used to illustrate a case where there are two or more significantly
different scenarios, so that the main case and the additional subsidiary
cases are clearly differentiated.
 The main purpose of this classification is to separate out a special case.
 You should add a condition to each extension – with either a note or an
extension point – to specify when the variant behaviour will be included.
- This could be done with either a note or an extension point.
 The new use case (Alternative one) depends on the original. This is
conditional behavior.
 The new use case (the source) is connected to the original (the target)
with a dashed arrow pointing to the original and labelled with the
stereotype «extend».

49
 Section 4: More details on use case models

Alternatives to the main success scenario «extend»

 Example 10: A typical lending library will set an upper limit on the number of books that its members can
borrow at any one time. A librarian will not be allowed to issue a copy of a book if that limit would be
exceeded.
 The next figure shows a fragment of a use case diagram that identifies a new use case, refuse loan, as it
is only performed when the member would have too many books.
 Note that: the refuse loan is a conditional behavior which is only performed when the member would
have too many books.
 The note symbol is used to record the event that trigger the subsidiary use case.

Figure : Making log on the main use case

50
 Section 4: More details on use case models

Extending the use case description

 Table 3 shows how the original description

of the make reservation use case contained
in Table 1 has been changed to take into
account the extension to deal with instances
where the hotel has no free room available
for the requested period, and the
introduction of a new actor called Reserver.
 Each step in the main success scenario acts
as a potential extension point, from which
the relationship to a new use case can be
defined. Here, step 3 is the extension point
that leads to the additional steps described
in 3.a.1 and 3.a.2.
 As the extension point at step 5 shows,
some work can be avoided if the guest of
the reservation has stayed somewhere in
the hotel chain before. Where such choices
arise, your main success scenario should
reflect the more dominant or typical flow.

51
 Section 4: More details on use case models

To extend or include?
 We could show the log on use case as a component of every use case
that is associated with an actor.
 Note that: there is no implication of ordering: time ordering is not shown in
use case diagrams.

Figure : Including the log on use case in the hotel domain

52
 Section 4: More details on use case models

Avoiding over-complex use case diagrams

 The general approach to managing complexity is to partition a problem

into subproblems, and use abstraction to reduce the detail and extract
what is most significant to the problem.
 Reduce the complexity of your use case diagram by:
◦ redrawing it at a higher level of abstraction
◦ splitting it up into smaller modules.
 In the case of the hotel chain, we might partition our solution into three
subproblems, usually called packages (a way of grouping cases):
◦ reservations
◦ checking guests in and out of their rooms
◦ system access.
 Each package may then be assigned to a separate developer for
implementation, the project team must then deal with the dependencies
between the three packages as they work towards a solution..

53
 Section 4: More details on use case models

Problems with use cases

 One problem is that the focus may end up being top-down and function
oriented, resulting in an inflexible and difficult-to-maintain system.
 Focusing on use cases may cause the developer to sacrifice the object
oriented nature of the system, thus losing any advantage that UML offers.
 Another danger lies in mistaking design for requirements, where a design
decision is mistaken for a constraint.
 Focusing on the requirements in a use case may cause the developer to
view the system too operationally, where a sequence of events is
assumed to be the only answer.
 Developers need to distinguish between requirements and preferred
designs.
 Use cases need to be used in a way that is understandable to the
customer but also useful to the developer.

54
 Section 4: More details on use case models

Summary of Section

 In this section, you have seen that use case models play a key role in the
development of a software system, especially when the user is placed at the
centre of a development process.
 Use cases help you record the proposed requirements for a software system and
add detail to their relationships as follows.
 The «extend» relationship between a new use case and an original use case
shows how the system should deal with conditional behaviour.
 The «include» relationship shows how a subsidiary use case can provide some
common functionality to two or more use cases at a higher level of abstraction.
 The «include» relationship between use cases shows how the system can
employ a pre-existing component.
 Hence use cases provide a starting point for project and quality management.

55
 Section 5: Getting users involved

 Finding requirements involves identifying, recording and documenting the things that the
intended users do as part of their interaction with a system.
 Usually a developer will produce textual descriptions of the potential scenarios and attach
them to the relevant use cases.
 The domain of the developer’s expertise is software development, whereas the users
are experts in their own domain.
 Even with the support of experts in the users’ domain, the most significant mistakes are
usually made during requirements analysis.
 The cost of rectifying such errors increases the later they are detected in the development
process.
 Thus identifying use cases and then testing them helps to detect or avoid the kinds of error
that might arise:
 by missing a requirement
 by not understanding a requirement
 through ambiguity.
 Agile developers stress a close involvement with the customer, accept that requirements
will be identified throughout development and that they will change.

56
 Section 5: Getting users involved

Prototyping for and with the user

 One of the ways to improve the analysis and identification of

requirements is for the developers to produce a prototype.
 A prototype could be a paper based model, or a simplified software
system that is a subset of the eventual product.
 It can take several forms:
 a mock-up of the human–computer interface for a specific group of
users
 a working version of a subset of the functions required from the
eventual product
 an existing piece of software that has some relevance to the users’
needs and may be considered for further improvement for use in the
eventual product.

57
 Section 5: Getting users involved

Prototyping for and with the user

 The developers would normally start the prototyping process because

they have detected or identified a particular problem in their requirements
analysis.

 The intended users should test it.

◦ For example, if you developed a series of interfaces as part of a
prototype for the borrowing and returning of books, the library members
would be the testers.
Why?
◦ They know their own needs for their day-to-day role, and
◦ they have the most to gain from a successful implementation

58
 Section 5: Getting users involved

Note that:
 The main goal is to make sure that the prototype meets
the needs of its intended users.
 Next, the developer needs to document what has been
achieved.
◦ This will provide the information on the final software system for
all those people involved in its development.
 Finally, the people who should be involved in the
development of the prototype are the ‘real’ users.

59
 Section 5: Getting users involved

 The following activity diagram illustrates the general process of prototyping.

 There are two important guidelines that should be followed:
 the developer and the user must know what the particular prototype is to be used for
and they need to agree on a goal that must be achieved. This will include an agreed schedule for
building the prototype.

 the prototype should be evaluated against its goal.

Figure: Activity diagram for the prototyping process

60
 Section 5: Getting users involved

Linking activities to user interfaces

 Before prototyping, the developer needs identify the appropriate interfaces

from the users’ requirements and determine where and when they will be
needed.

 One way to achieve this goal is to use an activity diagram.



 To the users, the interface is the software system: an unacceptable

interface can lead to failure.

 The user interface is the link between what the users want and what the
developers produce in response

61
 Section 5: Getting users involved

 Consider the activity diagram in Figure illustrating the enrol new

member use case for the lending library

Figure: An activity diagram for the enrol member use case

62
 Section 5: Getting users involved

 The activity diagram shows the interactions involved in enrolling a new member and the
activities carried out.
 A nonmember of the library interacts with a librarian.
 The non-member requests to be enrolled and provides information when requested by the
librarian.
 The librarian then uses the system to record the enrolment information.
 Therefore the librarian needs an interface with the software system for recording the
information.
 This interface will be needed when a non-member request to enrol is dealt with by a librarian.
 This transaction is complete when the library system:

 checks the information entered

 generates a membership number
 creates a new member record with the information entered and the membership number
 informs the librarian of the membership number

 Thus the user interface for the use case enrol new member must be available to the librarian
when dealing with the enrolment request.

63
 Section 5: Getting users involved

 The table below illustrates associating interfaces with user activities.

 the developer can record the association between activities and interfaces, as shown in
Table 4.

 The main benefit of recording user (or any other) interfaces in an activity diagram is
traceability.
 To the users, the interface is the software system: an unacceptable interface can lead to
failure.
 The user interface is the link between what the users want and what the developer
produces in response.
 Also, the developer can identify the relative importance of each user interface for the
project plan, particularly when resources are needed for a prototype.

64
 Section 5: Getting users involved

Summary of section

 In this section, you have seen that activity modelling can help identify
when the user would need to use an interface to the proposed software
system.
 You can use activity diagrams for any of the scenarios of a use case
where some interaction with an actor is expected.
 Prototyping the user interface brings developers and users into close
contact with each other.
 By working together it is possible to minimise any misunderstanding that
might lead to false expectations on either side.

65
 Unit Summary
On completion of this unit you should be able to:

 discuss the connection between users’ activities and the interface to a

software system
 use techniques such as activity diagrams that allow you to understand
a business domain and model the context of a proposed software
system
 use modelling techniques such as use cases to help with the elicitation
and detailed representation of requirements
 apply use cases confidently and discuss their use throughout software
development
 carry out a detailed analysis of users’ activities.

66