COMP201: Software Engineering I

Assignment 1, Part 1 (2017/2018)

(100% mark for Assignment 1 is 10% of COMP201 grade)
Deadline for Assignment 1, (Part 1 and 2): 30th of October 2017, 17:00
Please submit your report via the department submission link
https://sam.csc.liv.ac.uk/COMP/Submissions.pl

The first part should take approximately two weeks and the second part will take a
further two weeks. There will be another assignment after this one worth a further
10% of the COMP201 grade.

OBJECTIVE

This assignment is mainly about “Requirements engineering” and will consist of

various stages to produce parts of a requirements document for a given scenario
based on a “proposed home security and safety system” detailed on page 2.

Assignment number 1 of 2
Weighting 10%
Assignment Circulated date provided to class 30/9/2016

Deadline Day & Date & Time
Submission Mode
Learning outcome assessed
Submission necessary in order
to satisfy Module requirements
Purpose of assessment
30th of October 2017, 17:00
Electronic
1. Realise the problems in
designing and building
significant computer systems
2. Understand the need to design
systems that fully meet the
requirements of the intended
users
3. Be able to apply these principles
in practice
No
To assess the students ability to analyse,
generate and document user
requirements

Marking criteria See end of document

Late Submission Penalty Standard UoL Policy

1 of 6
The two tasks refer to the scenario outlined on page 4 (you should read the scenario
first carefully). You may make some reasonable assumptions about how the system
should work (without inventing new functionality). Also note that there is no “right
answer” to modelling a system, different solutions can be equally good!

It may be helpful to refer to the course textbooks “Software Engineering”, Addison-

Wesley, by I. Sommerville and “Using UML”, Addison-Wesley, by P. Stevens.

Task 1 (40%)
(10% for use-case diagram 30% for use-case descriptions)
All tasks for this assignment refer to the given scenario “proposed home security
and safety system” (overleaf on page 2).

Produce a UML use-case model (i.e., BOTH a use-case diagram and use-case
descriptions) and identify as many actors as you can in your model that are within the
scope of the system. For the use-case diagram part of the model, you may use any
method to draw it, including a hand-drawn diagram or ArgoUML software (available
on the departmental computers (Click start and then type Argouml into the search
box) or for free download via the internet) for example. The demonstrators will be
able to help you with using this program. There is also app.genmymodel.com this is
easy, free and online (for public projects), so very good if you are not in the lab.

For the model diagram if you find it difficult keeping it looking good on 1 diagram,
feel free to split it into multiple diagrams. This is encouraged if it has become difficult
to read. Keep all text easy to read and all fonts at least 14pt.

For use cases follow the recommendations given in the lecture notes.

Use case descriptions

For each use case include a use case description, this should follow the
use case description form layout as shown in the notes.

2 of 6
Task 2 (10%):
Identify five non-functional and verifiable requirements of the “proposed home
security and safety system” below, using the description of the scenario (you can
make some assumptions about the system not detailed in the requirement description).

For the requirements propose a mechanism and appropriate criteria for making them
verifiable. So all the requirements you list need to have a technique to objectively test
them.

3 of 6
 Proposed home safety and security
Your company has been commissioned to design a home safety and security system.

This system is designed to protect to the householder against:

Fire Break in Flood

The system will act as a fire alarm, a flood alarm and a burglar alarm all integrated into 1
package. To enable this to happen the system will connect to:

Smoke sensors (fire) Heat sensors (fire)

Door, window and movement sensors (to detect break in)
Water sensors (flood)

The system has a key pad and a simple alphanumeric display.

Figure 1 Keypad and alpha display

The system is fitted with a wireless network card which allows it to connect to the internet
and be controlled by the user via a smart phone application or web interface. The system
has an alarm with 3 different tones, depending on the type of alarm (firm, break in or
flood). The user has a code which they type into the machine to stop the alarm or change
settings. Each sensor input needs configuring as a smoke, heat, door, window, movement
or water sensor but the system should also work with smart sensors which send a code
which indicates what type of sensor is attached when the system sends a set up message.
Every sensors can be enabled or disabled from the main console, it is also possible to set
times of the day when different burglar sensors (door/window) can be enabled or disabled.
The burglar alarm function can be armed or disarmed automatically depending on the time
of day. The fire and flood alarm function cannot be disabled.
Smoke detectors will sound a “smoke” alarm if they detect smoke but a fire will only be
confirmed and alarmed by the system if they indicate smoke 3 times in 1 minute.
The heat detectors will sound an alarm and indicate a fire as soon as they detect excess
heat. If the door, window or movement sensors activate the user has a user configurable
amount of time to reset the system before the burglar alarm is sounded. All functions of the
system can be configured via the smart phone application or web interface. The remote
interface has a username and password. For the fire alarm, if the fire alarm has not been
reset after 15 minutes the system can be configured to call the fire brigade. For the burglar
alarm if the system has not been reset the system can be configured to call the police
service.
4 of 6
 Smoke
Smoke
Water sensor sensor
sensor

Window
sensor
System
System Heat
sensor

Door
Movement
Window sensor
sensor

5 of 6
Marking Criteria

Part A++ to A B C D E+ E- to G <35

70%+ 60-69% 50-59 40-49 35-39
1 Correct Good set of Poor set of use Some critical Shows some No clear evidence that the
notation used use cases but cases or use cases correct requirements have been
throughout, some significant missing or use requirements understood at all or no
well chosen descriptions problems with case analysis of the clear attempt at use case
set of use missing or notation. descriptions problem. diagram or descriptions.
cases and all minor case Level of detail missing.
case missing or not sufficient
descriptions some minor for problem
present. notation
problems
2 All non Good Missing one or Missing up to Only 2 or 3 Requirements don’t make
functional answers but more non- three correct sense.
elements confusion functional requirement requirement
identified and between requirements. descriptions. present or
verification functional incorrectly
explained. and non- categorised.
functional
requirements.

6 of 6