联系我们： 手动添加方式: 微信>添加朋友>企业微信联系人>13262280223 或者 QQ: 1483266981

1 of 10
COMP201: Software Engineering I
Assignment 1.1 (2023/2024)
(100% mark for Assignment 1.1 is 15% of COMP201 grade)
Deadline for Assignment 1.1: 14
th of November 2023, 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
25/9/2023
Deadline Day & Date & Time 14
th of November 2023 at 17:00 (5
PM)
Submission Mode Electronic submission on Canvas (pdf)
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
requirements of the intended users
3. Be able to apply these principles in
practice
2 of 10
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
usecase 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
3 of 10
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.
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.
4 of 10
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
system access codes per card, one for fire and one for burglary protection
operation. So the swipes their card, then enters the code, if they enter the
burglary code then can configure the burglar alarm if they enter the fire code
they will be can configure the fire alarm function.
When accessing the system, for configuration if the user enters an incorrect
code wrong 3 times, they are locked out of the system and a tamper alarm
sounds (from the console speaker) and their card is disabled.
5 of 10
Fire alarm operation
The fire alarm is always active 24 hours a day. The fire alarm system will be
triggered in the following circumstances:
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 swiped.
6 of 10
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
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.
7 of 10
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.
8 of 10
Card readers
There are two sets of card readers. Readers for on the security system
panel allowing users to authenticate themselves for configuration. Readers
on doors to allow access to high security areas.
9 of 10
10 of 10
Marking Criteria
Part A++ to A
70%+
B
60-69%
C
50-59
D
40-49
E+
35-39
E- to G <35 1 Correct notation used througho ut, wellchosen set of use cases and all case descripti ons present. Good set of use cases but some descripti ons missing or minor case missing or some minor notation problem Poor set of use cases or significant problems with notation. Level of detail not sufficient for problem Some critical use cases missing or use case descriptio ns missing. Shows some correct requirem ents analysis of the problem. No clear evidence that the requirements have been understood at all or no clear attempt at use case diagram or descriptions. 2 All nonfunction elements identified and verificati on explaine d. Good answers but confusio n between function al and nonfunction al requirem ents. Missing one or two nonfunctional requireme nts. Missing up to three requirem ent descriptio ns. Only 2 or 3 correct requirem ents present or incorrectl y defined. Requirements don’t make sense.