COMP201: Software Engineering I - Assignment 1.1: Requirements Engineering
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: 14th 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 Weighting
|
Assignment Circulated date provided to class |
25/9/2023 |
|
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 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
Actors Name Description
Pre-conditions Event flow
Includes Extensions Triggers
Id if use case, example
UC1
List of relevant Actors
Short name for use case
Description of purpose of use case
What must be true to allow use case to happen
Line by line detailed events for the use case
Any use cases which make up this use case
Any optional use cases that are part of initial case
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 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.
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) Allfirealarmbellsaresoundedandlightsareflashedthroughoutthe 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.
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.
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.
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.
