Secure Home System

This exercise will give you experience of requirements engineering and design for a software intensive system. The coursework is in two parts; the first part focuses on requirements and the second part on design. Both parts are based on the Secure Home System (SHS) described below.

Consider a security system called a SHS. SHS consists of embedded software to drive the system hardware and to communicate with an external, home monitoring service. The hardware comprises of a keypad and LCD display for interacting with the user, a siren, an entry sensor, a motion sensor and a smoke sensor

During installation, the keypad is used to configure the system. Each sensor is assigned a unique number, type and location. A 4-digit PIN is input into the system for arming and disarming SHS. The home address and a telephone number for dialling the home monitoring service are also input into the system at configuration.

When a sensor event is detected by the system, it turns on the siren. After a delay time that is specified by the homeowner during configuration, the system dials the specified number of the home monitoring service, and provides information about the home address, the nature and location of the sensor event. The number is re-dialled every 20 seconds until a connection is obtained.

You may make your own assumptions about the system (e.g., price of the system, number of sensors, etc.), but they should not conflict with the above description and should be specified clearly in your answer.

Tasks

Part One – Use cases and Requirements

There are a number of stakeholders interested in the development and smooth running of healthcare smart homes:

• Home Owner representative (HO) who represents the owners of houses with the SHS installed. HO must best represent the home owner’s desires and concerns.
• Police (P) representative who wants to ensure that Police Home Security advices are being abided by.
• Technologist (T): a system developer who knows about home security technologies and how much they cost etc. T’s role is to suggest possible technologies and keep the team grounded in reality.

Draw a use case diagram for the SHS. Your diagram should include 5 use cases at least and show any relationships between the use cases.

Choose THREE of your use cases and, for EACH of these, give a detailed description of the sequence of steps in the use case. Describe the use case. Be sure to include alternative or exceptional behaviour where appropriate.

For EACH stakeholder, write down THREE requirements for the SHS, in the form of SHALL statements. For each requirement, state whether it is a functional or non-functional requirement. Each set of requirements should be written from the perspective of the chosen stakeholder. As discussed in the lectures, your requirements should (a) avoid including design details; (b) avoid vague requirements such as “the system should be secure”. You may wish to carry out internet research to give you some inspiration about each stakeholder’s perspective.

Part Two – Architectural Design and Object-oriented Modeling

Identify the main sub-systems that make up the SHS. Your sub-system decomposition should be limited to two levels

Giving reasons for your choice, suggest the best architectural style for the SHS. Use the “ball and socket” notation to indicate the interfaces between the sub-systems. For each interface show at least one operation. You do not need to indicate the data types.

Construct UML class diagrams showing the objects that make up SHS, their attributes, operations and relationships (including cardinalities).