COMP201代写、代写Java/C++程序设计

日期：2022-11-09 09:03

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.

7 of 6

8 of 6

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, well chosen

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 non function

elements

identified

and

verificati

on

explaine

d.

Good

answers

but

confusio

n

between

function

al and

non function

al

requirem

ents.

Missing

one or two

non functional

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.