COMP201: Software Engineering I
Assignment 1.1 (2022/2023)
(100% mark for Assignment 1.1 is 15% of COMP201 grade)
Deadline for Assignment 1.1: 10th of November 2022, 17:00
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 building security system”
detailed on page 2.
Assignment number 1 of 2
Weighting 15 %
Assignment Circulated date provided
to class
26/9/2022
Deadline Day & Date & Time 10th of November 2022 at 17:00 (5
PM)
Submission Mode Electronic submission
Canvas
1. Realise the problems in
designing and building
significant computer systems
2. Understand the need to design
systems that fully meet the
Learning outcome assessed
2 of 6
requirements of the intended
users
3. Be able to apply these
principles in practice
Submission necessary in order
to satisfy Module requirements
No
Purpose of assessment
Marking criteria
To assess the students’ ability to
analyse, generate and document
user requirements
See end of document
Late Submission Penalty Standard UoL Policy
Instructions
All tasks refer to the scenario outlined on page 4 so, before you begin,
read the scenario carefully.
You may make some reasonable assumptions about how the
system should work (without inventing new functionality).
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 (80%)
(20% for use-case diagram, 60% for use-case descriptions)
All tasks for this assignment refer to the given scenario “proposed building
security 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 download free via the internet). The demonstrators will be able to help
you with using this program. There is also app.genmymodel.com which is
easy to use and free online (for public projects), so it is convenient if you are
not in the lab.
For the model diagram, if you find that using one diagram is not sufficient or
becomes overly complex, feel free to produce multiple diagrams. This is
encouraged if the diagram has become difficult to read. Keep all text easy to
read and all fonts at least 14pt.
3 of 6
4 of 6
Please use the following template for your use case descriptions:
ID Id if use case, example
UC1
Actors List of relevant Actors
Name Short name for use case
Description Description of purpose of
use case
Pre-conditions What must be true to
allow use case to happen
Event flow Line by line detailed
events for the use case
Post-condition Any changes to the
systems internal state due
to use case executing
Includes Any use cases which
make up this use case
Extensions Any optional use cases
that are part of initial case
Triggers What might trigger use
case
Task 2 (20%)
Identify and list 10 non-functional requirements of the “proposed building
security system” below, using the description of the scenario (you can make
some assumptions about the system not detailed in the requirement
description).
Each requirement must have an appropriate criterion so it can be verified. So,
it needs to be possible to objectively test each requirement in your list.
Proposed building security control system
Your company has been commissioned to design a building control system
for a bank which will be used to protect buildings against robbery, theft and
fire. The system will be a series of sensors, buttons and outputs as follows:
Window sensors: will be activated if a window is opened
Door sensors: will be activated if a door is opened
Floor sensor: will be activated if a floor area is stepped on
Smoke sensors which detect smoke
Heat sensors which detect if the temperature exceeds a certain value
Fire alarm buttons
Panic alarm buttons
Fire door release solenoids
Fire alarm bell
Burglar alarm speaker
Card readers
Flashing lights
Console speaker
General operation
Any user of the system must access the system with both a swipe card and
access code. Each card has its own access codes configured. There are
two access codes per card, one for fire and one for burglary protection
operation. When accessing the system, if the user enters their code wrong 3
times, they are locked out, a tamper alarm sounds (from the console
speaker) and their card is disabled.
Fire alarm operation
The fire alarm is always active 24 hours a day. The fire alarm system will be
triggered in the following circumstances:
5 of 6
1) If any of the heat sensors detect a temperature great than TC
(Temperature Critical) where TC is calibrated by recommendations
from the fire brigade.
2) If any of the smoke detectors detect smoke for a time greater than
‘Time Critical’ (a value also calibrated by recommendations from the
fire brigade).
3) If a fire alarm button is pressed
If a fire is triggered the following actions happen:
1) The fire brigade is summoned automatically via an automatic calling
system
2) All fire alarm bells are sounded and lights are flashed throughout the
building
Resetting fire alarm
To stop the fire alarm, a fire disable code has to be input on the system
console as well as a valid card presented.
Burglar alarm operation
The burglar alarm is activated at specific times. On and off activation times
can be added for each day of the week, Monday to Sunday. There is also
the option to put the system into the activated state for a fixed number of
days, this is to allow for holidays where the alarm will be active all the time
(24 hours a day).
The burglar alarm will be triggered in the following circumstances:
1) If a door is opened (detected via door sensor) and the system is
active
6 of 6
2) If a window (detected via window sensor) is opened and the system
is active
3) If floor sensor is detected and the system is active
4) If a panic button is pressed and the system is active or inactive
Any sensor (door, floor or window sensor) can be designated as always on.
These sensors will trigger the alarm immediately even if the system is not
active. This is because some doors, windows or the floor need protection 24
hours/day. Entry to these areas is controlled by swipe cards near the doors
and floors which deactivate the alarm for a short length of time so the card
swipe is used to both unlock the door and deactivate the alarm.
To allow entry and exit through the building a number of the doors can be
assigned as designated entry points. These doors are to allow entry to the
building by authorised staff. If these doors are opened when the system is
activated, the console issues an audio warning and a countdown begins. If
the burglar alarm system is not disabled before the countdown timer
reaches zero then the alarm will be triggered.
If the burglar alarm is triggered, a warning sound and flashing lights are
activated also the police are sent a message. To de-activate the alarm or
disable the alarm, a code has to be entered into the alarm console as well
as a valid card presented. The alarm code has to be used to allow the
operator to configure the burglar alarm.