Assignment Scenario: DivingClub

Analysis of Requirements and UCD (CSI_4_RAU)

4101503
Tutor: Kamal Thapa
LSBU | 04-05-2022
Introduction
The following work is based on the given assignment scenario DivingClub and is divided into two
parts in accordance with the given instructions. The first part contains is centred around UML
modelling and covers analysis of stakeholders, users, activities, and a domain class diagram. The
second part consists of a wireframe of system and a description of how the core usability principles
have been taken into consideration.

1
Table of contents
INTRODUCTION...............................................................................................................................................1
PART ONE – UML MODELLING.........................................................................................................................3
STAKEHOLDER IDENTIFICATION TABLE ...........................................................................................................................3
ONION DIAGRAM .....................................................................................................................................................6
Onion diagram supportive narrative...............................................................................................................6
USER STORIES ..........................................................................................................................................................7
Visitors of the web application .......................................................................................................................7
Registered users ..............................................................................................................................................8
Instructors .......................................................................................................................................................8
Club leader ......................................................................................................................................................8
Manager .........................................................................................................................................................8
Club owner ......................................................................................................................................................8
USE CASE DIAGRAM ..................................................................................................................................................9
Use case diagram – Supportive narrative .......................................................................................................9
USE CASE DESCRIPTIONS ..........................................................................................................................................11
ACTIVITY DIAGRAMS ...............................................................................................................................................13
Supportive narrative .....................................................................................................................................14
DOMAIN CLASS DIAGRAM.........................................................................................................................................15
Supportive narrative .....................................................................................................................................15
PART TWO – USER CENTRED DESIGN .............................................................................................................16
CONSISTENCY ........................................................................................................................................................16
MAPPING .............................................................................................................................................................16
FEEDBACK .............................................................................................................................................................16
EFFICIENCY............................................................................................................................................................16
NAVIGATION .........................................................................................................................................................16
VISIBILITY .............................................................................................................................................................17
LEARNABILITY ........................................................................................................................................................17
BIBLIOGRAPHY ..............................................................................................................................................18

2
Part one – UML modelling
The first part is based on the Universal Modelling Language (UML) and models used in UML. The UML
diagrams have been created using Visual Paradigm and are based on the given scenario, which in this
case is DivingClub.

Stakeholder identification table

The stakeholders in the stakeholder identification table, see table 1, has been derived from the
scenario DivingClub and are the following:

• Visitors of the web application

• Registered users
• Instructors
• The club leader
• The manager
• The club owner

3
 Stakeholder Interests/positive
Stakeholder role/responsibility Importance Influence impacts Concerns
Visitors are
interested in a
functioning web
High, visitors application. It is
are using the highly important for
product visitors that the The product
directly and application is does not
can provide functioning. If not, have a
knowledge visitors will choose negative
regarding another diving club. impact on
Uses the product functional Low, visitors The web visitors. No
directly with the requirements do not take application is worries or
Visitors of purpose of gather and business part in important for the concerns
the web information about requirements decision visitors to become related to
application the diving club. of the system. making. registered users. the product.
The product
may have a
High, negative
registered impact on
users are the
using the Registered users registered
product are interested in a users they
directly and functioning web find it more
can provide application. It is complicated
knowledge highly important for to use for
about Low, registered users booking of
Uses the product functional registered that the application trips than
directly with the requirements users do not is functioning. If other ways
purpose of booking and business participate in not, they will not go of booking
Registered a trip arranged by requirements decision through with their (e.g. phone
users the diving club. of the system. making. booking. call, email).
High,
instructors are
using the
product The product
directly and Low, does not
can provide instructors do have a
knowledge not participate Instructors are negative
about directly in interested in a impact on
Uses the web functional decision functioning web instructors.
application directly requirements making but are application so that No worries
with the purpose of and business able to they can upload or concerns
uploading and requirements influence and update their related to
Instructors editing their profile. of the system. those who do. profiles. the product.
High, the club Medium, the
leader are club leader is
using the part of the The club leader is
product middle level interested in The product
Uses the web directly and management uploading may impact
application directly can provide and therefore information about the club
with the purpose of knowledge participate in the club and the leader
providing about some decision trips so that tourists negatively
information about functional making. The choose to book a since it adds
the club and the requirements club leader is trip at the diving to the total
Club leader trips. and business also in close club. workload.

4
 requirements contact with
of the system. the instructors
The club and therefore
leader have
benefits form knowledge of
the web their needs.
application
since it helps
tourists to find
the diving
club.
Medium, the
manager uses
the web
application
directly but
only provide
information
about how The product
reports are does not
presented, have a
what negative
information is impact on
needed from The manager is the
Uses the web the registered High, the interested in a manager. No
application directly users and how manager is functioning product worries or
to view reports and processed part of the top- so that they can concerns
payments from the payments are level view reports and related to
Manager tourists. presented. management. payments. the product.
The product
does not
Medium, the have a
club owner negative
provides The club owner is impact on
No not use the web information interested in a the club
application directly. about functioning product owner. No
May use the web business High, the club so that they can worries or
application to requirements owner is part gather statistics concerns
gather statistics and of the top-level about the trips and related to
Club owner about the trips. constraints. management. strategically plan. the product.

5
Onion diagram
The onion diagram, see figure 1, is used for visualising the degree of which the stakeholders are
impacted and impacts the system.

Figure 1 showing the Stakeholder Onion Diagram. The stakeholders in the systems are the ones who uses the product. The
containing system includes the stakeholders that benefits from the system. Finally, tThe wider environment consists of
stakeholders that do not use the system directly but affects it, for example by financial stakeholders.

Onion diagram supportive narrative

Stakeholders are the ones who are affected by the system both negatively and positively1. Based on
the given scenario, the following stakeholders are identified: instructors, visitors of the web
application, registered users, the club leader, the manager, and the club owner. Own assumptions
based on the given information extends the stakeholders to a diving qualification body, a tourist
agency and the public. These assumptions are based on the statement that the instructors are
qualified and therefore that the dive instructor qualification body affects how the instructors present
themselves on the web application. Moreover, the diving club arranges trips for tourists which leads

1
Sears, A, & Jacko, JA (eds), 2009.

6
to the assumption that a tourist agency is a stakeholder as well. It is also assumed that the public is
affected by the system since it may promote diving.

The onion diagram is organised in layers starting from the product itself followed by the system, the
containing system, and the wider environment. Each layer in the onion diagram holds the inner layer.
The stakeholders in the system are the operators of the system and interfacing system. In the
containing system are the beneficiaries of the system which includes the higher management that
are not using the system directly. The wider environment holds stakeholders that are not in contact
with the system and negative stakeholders that are affected by the system in a negative way as well
as financial beneficiaries2.

The system consists of instructors, visitors of the web application, the registered users, and the club
leader. The reason for this, as stated, is that the system consists of stakeholders that interact directly
with the system. The manager and the club owner are in the containing system since the manager is
a functional beneficiary, meaning that the manager draws benefits from the fact that the system
exists without interacting directly with it. In the wider environment are the stakeholders that benefit
financially from the system; however the club owner belongs to the containing system. The reason
for the club owner being in the containing system and not in the wider environment is that the club
owner uses the system for viewing financial reports. Moreover, the wider environment holds
stakeholders such as the tourist agency, the diving qualification body and the public since it is
assumed that the tourist agency is affected by the system since it has the potential to draw tourists
to the area of the diving club. The assumptions that the diving qualification body and the general
public are affected are based on the fact that instructors need qualification that is viewed on the web
application, hence affecting the diving qualification body. Finally, the general public benefits from
the system since anyone can become a user of the website and book a diving trip.

User stories
The user stories are written in full format:

User story: I as a [role] want [function] so that [business value].

Acceptance criteria: Given [beginning] when [action] then [outcome]3.

Due to the length of the full format user stories, some have been left out.

The user stories are based on the CRUD and INVEST criterion. CRUD stands for Create, Read, Update,
Delete and specifies that for each data type there should be a user story for each letter in the
abbreviation. INVEST stand for Independent, Negotiable, Valuable, Estimable, Small and Testable and
specifies how a user story should be written.

Visitors of the web application

As a visitor I want to read about the club so that I can decide if I am interested in booking a trip
through the club. Given that information is available when I read it then I have learnt about the
diving club.

As a visitor I want to read about the trips that the club offers so that I can decide if I am interested in
booking one. Given that information is available when I read it then I have learnt about the diving
club.

2
Alexander, Ian, F
3
Aha!. User story templates and examples, 2022.

7
As a visitor I want to read about the diving instructors so that I can decide if I trust them enough to
book a trip with the club. Given that information is available when I read it then I have learnt about
the diving club.

Registered users
As a registered user I want to pay online for the trips that I book so that I can go diving. Given that
there is possible to pay online when I make my booking then I have made a payment for my booking.

As a registered user I want to place an order so that I can go diving. Given that there are trips
available when I look for a trip then I can book it.

As a registered user I want to edit my order so that the order is correct. Given that my order has
been saved when I go through with it then I can edit it.

As a registered user I want to delete my order so that I do not pay for a trip that I will not
attend. Given that my order has been saved when I go through with it then I can edit it.

Instructors
As an instructor I want to create a profile so that visitors and users can read about me and my
competence. Given that I have access to my profile when I want to edit my information, then it is
correct.

As an instructor I want to view my profile so that I know that the information stated is correct. Given
that I have access to my profile when I want to edit my information, then it is correct.

As an instructor I want to update my profile so that the information stated is up to date. Given that I
have access to my profile when I want to edit my information, then it is correct.

As an instructor I want to remove my profile so that outdated information is not available on the web
application. Given that I have access to my profile then I can edit my information

Club leader
As a club leader I want to upload general information so that visitors become interested in the
club. Given that I can make changes to the website then I can upload information when I log in, then I
have provided the correct information.

As a club leader I want to view general information so that the information is correct. Given that I
can make changes to the website then I can upload information when I log in, then I have provided
the correct information.

Manager
As a manager I want to view reports related to the booked trips so that I can see if there are any
issues with the trips. Given that reports are available for me when I log in, then I can read them.

As a manager I want to view the applications from users so that I can see if the users have paid for
their booked trips. Given that there is a record of payments available for me when I log in, then I can
read them.

Club owner
As a club owner I want to view statistics of which trips are the most popular so that I can strategically
plan future trips. Given that statistics are available for me when I log in, then I can read them.

As a club owner I want to view the financial report so that I am aware of the financial situation. Given
that reports are available for me when I log in, then I can read them.

8
Use case diagram

Figure 2

Use case diagram – Supportive narrative

In order to describe the requirements and behaviour of the web application for the Diving club a use
case diagram is constructed. The diagram is a visualisation of the expected behaviour of the system
and is based on the previously stated user stories4.

The actors in the system are represented by stick figures and the use cases as ellipses. The
relationships are represented by connecting lines and arrows, in accordance with UML. The actors
interact with the system but are not a part of the system and are therefore placed outside of it. The
use cases are important tasks defined by the actors and are used for expressing functional
requirements. The use cases can however not be decomposed since they are not features of the
system but describe the systems’ behaviour5.

In the case of the Diving Club scenario, actors of the system include visitors, registered users,
instructors, the club leader, the manager and the club owner. Based on the user stories the use
cases of visitors are to read information about the club and create an account.

Visitors want to read about the club so that they can decide whether or not they want to create an
account and become registered users. The use cases are separate since a visitor may create an
account without first reading about the club and may decide not to create an account after reading
about the club. The use case create account has the extending use cases get help on creating account
and edit account since the two latter use cases define an optional behaviour and depend on create
account. The use case read information about the club includes view trips and view instructors’
profiles since visitors want to gather information about the club, the trips that the club organises and
the qualifications about the instructors.

4
Shen, W., Liu, S. (2003)
5
Bittner, K., Spence, I. (2003)

9
The use cases connected to the registered users is place order, which is an extend use case with the
extending use case edit order since some registered users may want to edit their placed orders when
booking trips. Furthermore, edit orders is an extend use case for the extending use case cancel order,
the reason is once again that some users may want to cancel their booked trips with the diving club.
Place order also includes submitting a health check since this is required by the users when they book
a trip.

The instructors have the use cases create profile and edit profile. Both of the use cases are connected
to view profile but in different ways. When an instructor edits their profile, they must view it,
meaning that edit profile includes view profile. On the other hand, when an instructor creates their
profile, they may want to view the profile. It is however not mandatory to view the profile when
creating it, hence the extend relationship.

The club leader wants to upload information, with the extending use case edit information since the
club leader may want to edit the uploaded information or choose to keep it the way they uploaded
it. The club leader also has the use case create trip which include view trip since the club leader
needs to know what trips already exist. Create trip has the extending use case edit trip since the club
leader may want to edit the created trips. Create trip also has the extending use case read reviews
since the club leader may want to read the opinions from the tourists (registered users) when
creating a new trip.

The manager wants to read reviews, access booking reports and view user applications. Finally, the
club owner wants to access statistics for trips and view financial reports. The manager and the club
owner interact less with the system compared to the other actors. The reason for this is that the
manager and the club owner belong to the containing system and the wider environment
respectively in the onion diagram. The manager and the club owner therefore have fewer use cases
in the diving club web application.

10
Use case descriptions
Use case name: Place order

Scenario: Place an order for a diving trip.

Triggering event: A user wants to book a diving trip online.

Brief description: A registered user books a diving trip by placing an order for the trip online.

Actors: Registered user.

Related use cases: Read information about the club, pay online.

Stakeholders: Instructors, manager, club leader, club owner.

Preconditions: Account system must be available.

Booking system must be available.

Information about trips and instructors must be available.

Health check must be approved.

Trips must be created and available for booking.

Further information about trip must be completed and available.

Postconditions: Payment must be registered.

Booking must be confirmed.

Flow of activities: Actor System

1. User selects trip for booking.
2. User pays for trip.
Exception 1.1 No availability for trip.
conditions: 2.1 Payment is not accepted.
1.1 System checks availability for trip.
1.2 System prompts for payment.
2.1 System confirms payment.
2.2 System associate user with trip.
2.3 System saves user trip and user
profile.
2.4 System confirms booking of trip.
2.5 System gives user access to further
information about trip.

Figure 2 showing the use case description of "place order".

11
 Use case name: Create user account.

Scenario: Create a user account online.

Triggering event: A visitor wants to become a registered user by creating an account.

Brief description: A visitor creates an online account by providing personal information,

submitting a health check and provide details for a credit or debit card.

Actors: Visitor

Related use cases: Read information about the club, might be evoked by place order.

Stakeholders: Instructors, manager, club leader, club owner.

Preconditions: Account system must be available, authorisation service for credit or debit card
must be available.

Postconditions: Registered user account must be created and saved.

Health check submission must be submitted.

Credit or debit card must be authorised.

Health check, credit/debit card, personal details must be associated with the
user account.

Flow of activities: Visitor System

1. Visitor adds personal details 1.1. System creates new user.

to create account.
2. Visitor enters credit or debit
card details.
3. Visitors submits health
check.
1.2 System prompts for credit or debit
card details.
2.1 System associates card details to
user account.
1.2 System saves account.
2.3 System prompts for health check.
3.1 System associate health check to
user account.
3.2 System saves account.
3.3 System confirms creation of
account.

Exception 1.1 Incomplete submission of personal details.

conditions: 2.2 Unauthorised credit/debit card details.
3.1 No/incomplete submission of health check.
Figure 3 showing the use case description of "create user account".

12
Activity diagrams

Figure 4 showing the activity diagram for place order.

13
Figure 5 showing the activity diagram for the use case description “Create user account”.

Supportive narrative
The activity diagrams are based on the use case descriptions, see figure 2 and 3. The first activity
diagram (figure 4) belongs to the use case description Place order (figure 2) and shows the flow of
activities when a customer places an order. The customer first must select a trip, the system checks
the availability and if the trip is available, it prompts for a payment from the user. The user then pays
for the trip and the system confirms the payment and associates the user to the trip. The system
then saves the trip and the user profile since both needs to be updated with details about the trip.
The system sends a confirmation to the user and finally grants access to details about the trip.

The second activity diagram (figure 5) belongs to the use case description Create user account (figure
3) and shows the flow of activities when a user creates an account. The user starts with adding their
personal details, whereupon the system creates a new user with those details. The system then asks
for card details for future payments and when the user adds those details, the system checks if the
details are correct. If the details are incorrect, the system sends a message to the user about the
invalid card details and the user enters them again whereupon the system checks the details. Hence,
a loop is created. If the card details are valid, the system associates them to the newly created
account. The account is saved and the system asks for a health check. The user then has two choices,
either to upload the health check directly, or to do it at a different time. The system saves the user
profile and sends a message to the user that the profile was successfully created.

14
Domain class diagram

Figure 5 showing the domain class diagram extracted form the scenario DivingClub.

Supportive narrative
As seen in figure 4, user is a superclass with the subclasses Instructor and Tourist, meaning that
Instructor and Tourist inherits the attributes in User. The reason for the superclass being in the
system is to make it more efficient, the attributes in user are the attributes that instructor and tourist
have in common.

The class Tourist has the aggregated class Payment since the transaction that the tourist has made
for a trip still exists even if the tourist user profile is deleted. Contrary to the relation between Tourist
and Payment, there is a composition between Tourist and Health_Check since the health check is
deleted if the tourist user profile is deleted. The same goes for User and Booking. Furthermore,
Booking is introduced to the diagram to break the many-to-many relation between user and trip.
Since many users may book many trips, the Booking class is introduced so that the bookings that the
user makes for trips are stored in a separate diagram. This avoids the issue of multiple values being
stored in the same cell in the diagram. The relation between Booking and User is composition since
the booking is deleted if the user profile is deleted. Trips can however exist independently of
booking, this allows for creation of trips that do not yet have any bookings. The relation between
Booking and Trip is therefore an aggregation. The same goes for Payment. Additional_Information
that contains the information that tourists can view after creating a profile can however not exist
without Trip, hence the composition relation.

Relations

• One user may have several bookings, each booking belongs to a user.
• One trip may have many bookings, but also zero since a trip can be created before there are
any bookings for the trip.
• One instructor is assigned to each trip, but a trip can also be created before an instructor has
been assigned to it.

15
 • Each payment belongs to one trip but a trip does not necessarily have a payment since a trip
can be created before anyone has paid for it.
• One tourist may have zero or one health check since the profile can be created before the
tourist uploads the health check.

Part two – User Centred Design

The core usability aspects include consistency, visibility, mapping, feedback, learability,
efficiency, memorability, effectiveness, navigation, and satisfaction.
Following is a description of how the wireframe of the diving club website has been
conducted according to the core usability aspects.
The wireframe was created using Figma and the work can be found when following this link:
https://www.figma.com/file/Y5F1yaOYQ9Cx1oZYZPAt5V/Dive-Club?node-id=0%3A1

Consistency
Consistency of the system has been addressed by using the same colours scheme for each
page of the website. All of the buttons that the user can click in to go through with the task
are the same colour with the same colour text (white text on blue background). The top menu
is fixed, with the difference that a user that is signed in has the option “my account” instead
of “sign in”. The header is also fixed in the sense that when the user scrolls down, the header
is always visible. The titles are all the same font, size, and colour, the same goes for the
under titles and the body text.

Mapping
The symbols used in the system are intuitive and universal, an example of this is the default
profile picture and the arrows directing the user to the next or previous month in the timetable
over upcoming trips. The intended interpretation of the system and the actual interpretation
that a hypothetical user may have of the system is however to be determined. Only through
such determination can it be concluded that the system follows the mapping criteria of UCM.

Feedback
The user is answered with a response from the system when performing an action. In the
wireframe, users receive feedback when clicking a button. The button changes its
appearance when clicked. Moreover, when a user places an order (books a trip) the system
gives a confirmation to the user by sending a message that the payment has been
successful. The concept of closure is thus fulfilled.

Efficiency
A user who wants to book a trip needs to perform four clicks before the trip is booked. This
can be considered a small number of clicks and the task is hence efficient. The ease of a
user to follow the steps in the tasks of the system is high since there is guidance for each
step in the form of a large marine button on a white background.

Navigation
The navigation criteria are dependent on the use of design standard or convention. A design
approach is considered as standard when more than 80% of all websites use the same

16
design principles. For a design approach to be considered as a convention 50–79% of all
websites must use the design principle6.
According to Crestodina, the following design approaches can be standards or conventions:

• Logo in top left corner

• Main navigation in header
• Dropdown menus
• Contact in the top right
• Value proposition on the page
• Search in the header

Following the standards leads to easier interaction between the user and the system and
less frustration6. In the system designed for the diving club, the standards and conventions
are followed.
Furthermore, breadcrumbs are used to help the user remember what page they visited
previously to get to the one they are currently at. The menu is placed in the header and not
visualised as the hamburger navigation menu. The reason for this is that the hamburger
navigation menu is not considered to be convention, according to Crestodina, which the
menu in the header is, and that some users find the hamburger menu to be confusing. No
more than seven items are used in the header menu to not distract the user and the header
is the same for all pages of the web application to enable sticky navigation. Finally, all
clickable buttons have the same design for consistency.

Visibility
Visibility can be as a core value can be incorporated into the system by directing the users’
focus towards the actions that the user wants to do7In the system for the diving club, this has
been done by using contrasting colours for buttons that the user can click to perform an
action. More specifically a marine button on a white background, making the button stand
out. By adjusting the size of objects, the visibility is adjusted as well, larger objects such as
the button for signing in as a user is larger compared to the button for a user to reset
password. The reason for this is that it is more likely that a user wants to sign in than reset
their password. Visual feedback is also used in the system, the system gives the user a
message when the payment for booking a trip is completed. It is clear to the user what
actions are available since they are shown as large marine buttons and in the menu of the
header, this to improve the visibility. When performing a task, such as booking a trip or
editing the profile, the distracting details have been minimised.

Learnability
To reduce the cognitive load of the user and increase the learnability of the system the user
is given cues to help navigation in the system. An example of such a cue is the guiding text
on the page for the timetable that request the user to click on a date to select that date.

6
Crestodina, A. 2021
7
Lowdermilk, T. 2013.

17
Bibliography
1. Sears, A, & Jacko, JA (eds) 2009, Human-Computer Interaction : Development
Process, Taylor & Francis Group, Baton Rouge. Available from: ProQuest Ebook
Central. [14 March 2022].
2. Alexander, Ian F, A Better Fit – Characterising the Stakeholders. Available from:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.99.9664&rep=rep1&type=p
df [14 March 2022].
3. Aha!, (2022), User stories templated and examples. Available from:
https://www.aha.io/roadmapping/guide/requirements-management/what-is-a-good-
feature-or-user-story-template
4. Shen, W., Liu, S. (2003). Formalization, Testing and Execution of a Use Case
Diagram. In: Dong, J.S., Woodcock, J. (eds) Formal Methods and Software
Engineering. ICFEM 2003. Lecture Notes in Computer Science, vol 2885. Springer,
Berlin, Heidelberg. Available from: https://doi.org/10.1007/978-3-540-39893-6_6
5. Bittner, K., Spence, I. (2003). Use case modeling. Addison-Wesley Professional.
ISBN 0201709139, 9780201709131.
6. Crestodina, A. 2021. Web Design Standards vs. Website Best Practices: Our Review
of 500 Sites [NEW RESEARCH]. Orbit Media Studios. Online. Available:
https://www.orbitmedia.com/blog/web-design-standards/
7. Lowdermilk, T. 2013. User-Centered Design: A Developer's Guide to Building User-
Friendly Applications. O'Reilly Media, Inc.
https://books.google.co.uk/books?id=nklr2hZ_wsYC&dq=visibility+user-
centered+design&hl=sv&lr=

18