Fire and Security Alarm Monitoring System

Fire and Security Alarm Monitoring System
Part 1
IDs:20600682, 20601019, 20524582, 20439386 Module:Software Engineering 1
Module code:CO301
Course:BSc(Hons) Computing and Internet Technology Faculty:Technology
1.ELEMENT 1 – Requirement Definition and (partial) Specification (4)
1.1.Requirement Document (4)
1.1.1.Project Purpose (4)
1.1.2.Document Conventions (4)
1.1.3.Intended Audience (4)
1.1.4.Project Background (4)
1.1.5.Project Glossary (5)
1.1.6.Scope and Context Diagram (6)
er Requirement Definition (7)
1.1.8.Partial System Requirements Specification (11)
1.2.Critical Evaluation (13)
2.ELEMENT 2 – An outline Architectural Design using the CORE Modelling technique (14)
2.1.Overview of CORE Methodology (14)
2.2.Requirement Document (14)
2.2.1.System Architecture (Stage 3 of CORE) (14)
2.2.2.System Models (Stage6 of CORE) (14)
2.3.Critical Evaluation (14)
3.ELEMENT 3 – Prototype based upon the proposed System User Interface (15)
3.1.Overview of Rapid Software Development (15)
3.1.1.Objectives (15)
3.1.2.Prototype functionality (15)
3.1.3.Development Process (15)
3.1.4.Evaluation – usefulness and problems (15)
3.2.Requirement Document (15)
3.2.1.Subsection of User Requirement Definition (15)
3.2.2.Agreed System User Interface (15)
3.3.Critical Evaluation (15)
4.ELEMENT 4 – Requirement Validation and Management strategy (16)
4.1.Overview of Requirement Validation (16)
4.2.Requirement Validation techniques and Requirements Review Process (16)
4.3.Requirement Management Planning (16)
4.3.1.Requirement Identification (16)
4.3.2. A change Management Process (16)
4.3.3.Traceability Policies (16)
4.4.Critical Evaluation (16)
5.References (17)
Appendices (18)
Appendix A (18)
Appendix B (18)
Appendix C (19)
Appendix D (19)
Appendix E (19)
Appendix F (19)
Appendix G (19)
Appendix H (19)
Appendix I – Diary (20)
1.ELEMENT 1 – Requirement Definition and (partial)
Specification
1.1.Requirement Document
1.1.1.Project Purpose
The primary goal of this document is to provide a complete and accurate list of requirements for a Fire and Security Alarm Monitoring System. Upon
completion, the document will act as a binding contract between developers
and users and will provide a common point of reference for system developers.
1.1.
2.Document Conventions
Although this document is intended as a set of Requirements, not a design,
some technical information has been included with the requirements
description.
1.1.3.Intended Audience
The primary audience of this document includes, but is not limited to, project
leaders, the designers and developers of the system and the end user.
(Reference 1)
1.1.4.Project Background
Team International is primarily a software developing company specialising in fire and security alarm monitoring system (‘FASAM’).
Team International applied for and has been awarded the contract to supply
and implement a FASAM for Everett & Co.
The building in question is a new building, so there is no previous FASAM
system installed.
The building in question consists of 2 floors, each floor consisting of 12
offices.
The building will be grouped into ZONES. Zones will consist of x-amount of offices. Please refer to appendix A for an example.
Each zone shall be fitted with a security / fire doors which the FASAM will
have control over in regards to locking and unlocking depending on the threat.
Team International has decided, after gathering the requirements, that an
automated system with a manual over-ride option, which will be connected to
a central control room, will best suit the needs of Everett & Co.
1.1.5.Project Glossary
(Below is an alphabetical list of technical words / terms used in this document, bearing in mind that this list is not the full list of technical terms.)
Analyzing requirements
∙Determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory and then resolving these issues.
Context diagram
∙ A data flow diagram of the scope of an organizational system that shows the system boundaries, external entities that interact with the system and the major information
flows between the entities and the system.
Eliciting requirements
∙The task of communicating with customers and users to determine what their requirements are.
Functions
∙The tasks or actions that software is intended to perform.
Interface
∙The graphical or textual form of interaction between user and software. Through the interface the user may give commands to the software which are then translated into
instructions that the computer can interpret.
Prototype
∙ A full-scale working model used to test a design concept by making actual observations and necessary adjustments.
∙ A trial version, or model, of a product being developed.
Recording requirements
∙Requirements may be documented in various forms, such as natural-language documents, use cases, user stories, or process specifications.
Requirement
∙Characteristics that identify the accomplishment levels needed to achieve specific objectives for a given set of conditions.
Scope
∙An itemized accounting and definition of the agreed upon project deliverable in terms of functionality as well as data.
Sensors
∙An electronic device used to measure a physical quantity such as temperature, pressure or loudness and convert it into an electronic signal.
Specification
∙ A document that prescribes, in a complete, precise, verifiable manner, the requirements, design, behaviour, or characteristics of a system or system component.
∙The written specification of the Software.
Validation
∙The process by which the preparing activity tests a technical directive for accuracy and adequacy.
∙The process of evaluating software at the end of the development process to ensure compliance with software requirements.
1.1.6.Scope and Context Diagram
Processes involved in the project scope
The development of this system will include the gathering of the requirements, outline the architecture design using CORE modelling, creating a prototype based upon the proposed user interface and the requirements validation which will all help to contribute to the initial development of a FASAM for Everett & Co.
Below is a breakdown of the four stages mentioned above in regard to their input and output.
Gathering of the requirements:
The input for this shall come from interviews with the client. The knowledge gained from the input will help create the Requirements document.
Outline the architecture:
The input for this shall come from the requirements document. The knowledge gained from the document will contribute to help producing systems architecture and a systems model.
Creating a prototype:
The input for this shall come from the requirements document. The outcome of this will be a working prototype of the system.
Requirements validation:
The input for this section comes from the three previously mentioned stages. The outcome will be a produced validation document highlighting the pros and cons of each stage and how accurate each stage is.
Limits and constraints of the project scope
Obviously with Team International being primarily a software producing company, there is a lack of knowledge in regards to certain hardware elements. That is why this project will not cover the configuration of sensors due to the fact that when Team International purchases the sensors from the supplier, the suppliers implement the required configuration settings for the sensors. In regards to the sensors, all Team International does is install the sensors and connect them to the main user interface system.
This process shall only cover the developing of a fire and security threat monitoring system.
Please see appendix B for context diagram showing the system boundaries and external entities.
er Requirement Definition
Intended Audience
The primary audience of this document section includes, but is not limited to, project leaders of the system and the end user.
The user requirements definition is aimed solely at the client. It provides a simple way to showcase what the gathered user requirements for the system agreed upon are.
Introduction
In this section of the document the reader will find information regarding the hardware for the FASAM, operating modes, testing, functions and non-functions and threat confirmation for the system in question.
Hardware
Below is a brief list of the essential hardware included in this system.
∙user control system (user interface)
∙directional lighting
∙sensors
∙sprinklers
∙door locking mechanisms
∙speakers
The type of sensors for this system shall consist of heat sensors, motion sensors, smoke sensors and glass shattering sensors. All sensors are configured with a set determined threshold level. A threat is detected once the sensors threshold level has been achieved. Confirmation is achieved by either a combination of two sensors detecting a threat or by a sensor detecting a threat for a set sustainable amount of time. (Is discussed further on page 10)
Operating Modes
Start-up mode:
This is when the system is turned on. The system will run various test to determine that the system is fully operational and fault free. Once all the start-up procedures are completed successfully the system will run in activated mode.
Activated mode:
The system is in a state of constant automatic monitoring and threat detecting. If a threat is detected then the system will switch to operate in threat mode. Threat mode:
The system identifies a threat and follows a set procedure. The system also takes into account that if a security threat has been detected it must make sure there is no current fire threat happening in the same zone. If a fire threat has been detected in the same zone, the security threat is cancelled until the fire threat has been completed.
Update mode:
The system is still running in activated mode while the update is in motion, but when the update is ready to be installed, the system is de-activated until the new software update has been installed, thus enabling the system again. Reset mode:
The system gets reset back into start-up mode.
Testing of system (also known as system self diagnostics test )
Testing plays an important role in the system life-cycle. Without testing, faults that reside in the system may not be discovered until it’s all too late. Testing shall be carried out once every week.
The testing procedure shall carry out a system diagnostic tests on the sensors and procedures. The system shall run the test automatically. The user of the system will have the option to manually initiate the test procedure if required. Once the test procedure begins, then system scans all sensors to make sure they are operating in a correct manner. If an error occurs during the test procedure the system will inform the user of where the malfunction occurs and what type of malfunction it is.
User requirements Definition:
Product Perspective
(Below is an overview of the whole system)
The FASAM provides:
∙ A fire and security threat monitoring and detection system using sensors:
∙Complete fire monitoring system.
∙Complete security monitoring system.
∙Automatic emergency services calling.
∙System diagnostics function
∙System remote software updates function
∙System reset function
Functions of the FASAM
(Below is the recognised functions of the system, they have been divided into two separate categories to help make it easier to understand what each section will contain.)
Fire monitoring and detection section functionality:
∙Provide a means to monitor for possible fire threats
∙Provide a means to detect a fire threat
∙Provide a means to confirm a fire threat
∙Provide a means to isolate the threat zone
∙Provide a means to give the staff time to leave the threat zone
∙Provide a means to shutdown the electricity in identified threat zone ∙Provide a means to sound the fire alarm
∙Provide a means to illuminate directional indicators in the identified threat zone
∙Provide a means to unlock all locked doors in identified threat zone
∙Provide a means to initialise the sprinkler system in identified threat zone
∙Provide a means to contact appropriate emergency services
Security monitoring and detection section functionality:
∙Provide a means to monitor for possible security breach
∙Provide a means to detect a security breach
∙Provide a means to confirm a security breach
∙Provide a means to isolate the security breach
∙Provide a means to automatically lock the doors in the identified security breach zone
∙Provide a means to sound the security alarm
∙Provide a means to contact appropriate emergency services
Product Non-Functions
The system must be reliable:
∙The system must not contain any conflicts regarding the procedures and must respond within the given set time frame.
The system must be accessible:
∙Due to the nature of the system, it must be easy located.
The system must be durable:
∙The system must withstand fire and water. Eg the sensors should not go faulty due to exposure to the heat of a fire.
The system must be easy to use:
∙The system must be easy to use, keeping in mind a non trained user might have to operate the system at any given time.
∙The system should be usable after 15 minutes of training of a new user. The system must be maintainable:
∙The system must be easy to test, update and maintain. System testing will take place once per week.
The system must be secure:
∙The system must not be accessible by non operators, so a security code or security card should be implemented into the system.
The system must be safe:
∙The user shall not be able to configure, check sensors and test the system while in alarm mode.
Threat Confirmation
Once a threat has been detected confirmation is achieved by various means. Confirmation is achieved if either two sensors in the same zone detect a threat or if for example a heat sensors threshold is reached for a set period of time, then a threat is deemed to be real. This form of confirmation is for when the system is in automatic mode (generally 24hrs a day).
The user of the system may confirm a threat and thus start the threat procedure manually.
1.1.8.Partial System Requirements Specification
(This is a ‘partial’ specification due to the time constraints for this project) (The pseudo code used for this is not based around any one particular coding language)
FASAM class for threat procedure:
Fire threat procedure:
Security threat procedure:
Heat sensor class for monitoring for a fire threat:
Motion sensor class for monitoring for a security breach:
System diagnostics test:
1.2.Critical Evaluation
The notation used in the requirements definition is a form of natural language. To be more precise, it is structure natural language. The reason for using such a notation is purely down to the fact that the client will very often have no technical knowledge of the tools and procedures used when developing / implementing such a project. Natural language is a good way to showcase the functions and non-functions of the system to an audience with very little technical knowledge.
Other notations could be in forms of diagrams or other illustrations. The problem I came across when researching
The main concern when using natural language as a notation is the lack of clarity making it difficult to read and the fact that functions and non-function requirements tend to be mixed-up. In this project, natural language along with some diagrams, where used to best represent the gathered requirements of the client and show them in an easy to read, non-technical manner.
The notation used in the requirements specification is a form of PDL. Pseudo code was used to help represent the functions of the system in a more technical manner and is aimed at the developer of the system. The reason for using PDL based methods is to avoid the detail of programming language and limit the ambiguity.
Further reading into formal methods can be found at (reference 2)
In summary, it is best to use natural language when dealing with the customers because most customers will have no technical knowledge. Is it best to use structured notation when dealing with the developers of the system because of the un-ambiguity.
In regards to the requirements gathering techniques, three main techniques had to be undertaken to gather all the requirements. The three techniques are better known as Eliciting requirements, Analyzing requirements and Recording requirements (please refer to the glossary for descriptions). If this phase is not carried out thoroughly the end result may not be what the client wanted the system to be. Various techniques can be used to gather the requirements of the customer. In this project the requirements had already been decided upon but further interviews had to be carried out to best help understand certain statements due to ambiguity.
Other methods of requirements gathering include Joint Requirements Development Sessions (a.k.a., Requirement Workshops) and the reason for doing this is purely because when interviewing one stakeholder
For further reading into why it is so important to gather the requirements in a correct manner please visit (reference 3)
For example in statement 2) found on page 1 of the assignment handout it states that “they should not be activated if there are people in the same room”. Now that could imply that the
system should not start until all rooms in identified threat zone are empty. But after further research it was discovered that the system could start the procedures after a set amount of time even if the zones were not empty.
In summary I can’t state enough how important this phase of the product development life-cycle is. Get this stage correct and the final product should meet all the clients’ requirements. Get this stage wrong and you could end up with a product the client won’t want meaning a waste of time and money.
Another facture to mention in this evaluation is the fact that after doing some further research into the requirement documents field, most companies would have their own document templates. It is also important to remember that in the real world there would be little to non interaction between the various stages in the life-cycle.
2.ELEMENT 2 – An outline Architectural Design using the CORE Modelling technique
2.1.Overview of CORE Methodology
2.2.Requirement Document
2.2.1.System Architecture (Stage 3 of CORE)
2.2.2.System Models (Stage6 of CORE)
2.3.Critical Evaluation
3.ELEMENT 3 – Prototype based upon the proposed System
User Interface
3.1.Overview of Rapid Software Development
3.1.1.Objectives
3.1.2.Prototype functionality
3.1.3.Development Process
3.1.
4.Evaluation – usefulness and problems
3.2.Requirement Document
3.2.1.Subsection of User Requirement Definition
3.2.2.Agreed System User Interface
3.3.Critical Evaluation
4.ELEMENT 4 – Requirement Validation and Management
strategy
4.1.Overview of Requirement Validation
4.2.Requirement Validation techniques and Requirements Review
Process
4.3.Requirement Management Planning
4.3.1.Requirement Identification
4.3.2. A change Management Process
4.3.3.Traceability Policies
4.4.Critical Evaluation
5.References
Reference 1
http://64.233.183.104/search?q=cache:0RynF5BfqBEJ:/evla/techdocs/c omputer/workdocs/Corr_bkend_Req_Soft.pdf+system+requirements+specification&h l=en&ct=clnk&cd=7&gl=uk&client=firefox-a(21 Oct. 07) time = 23:51
Reference 2
/ (06 Nov. 07) time = 15:58
Reference 3
/article/requirements-gathering(06 Nov. 07) time = 16:08
Appendices
Appendix A
Below is an example of this. Keep in mind that this is not the actual zone layout representation but just an example to illustrate how the zones will work.
Appendix B
Below is a graphical representation of the systems external entities and how they relate with the system.
Appendix C Appendix D Appendix E Appendix F Appendix G Appendix H
Appendix I – Diary
Meeting 1
Held on: 12/10/2007
Time: 12:00-12:30
Present at the meeting: James, Simone, Farah
Agenda
1.Temporary allocation of tasks:
∙ELEMENT 1 temporarily allocated to James
∙ELEMENT 2 allocated to Farah
∙ELEMENT 3 allocated to Simone
∙ELEMENT 4 temporarily allocated to Wezley
Agreed work to be done before next meeting
1.James is to start looking into User Requirement Definition and System
Requirement Specification
Next meeting on: 15/10/2007 (during Software Engineering lecture)
Meeting 2
Held on:15/10/2007
Time: 12:00-12:15
Present at meeting: All
Agenda
1.Definite allocation of Task
∙ELEMENT 1 allocated to Wezley
∙ELEMENT 2 allocated to Farah
∙ELEMENT 3 allocated to Simone
∙ELEMENT 4 allocated to James
Review of work
Wezley has produced a provisional draft of the first 4 points of Element 1 including Context Diagram and User Requirements Specification
Work to be carried out before next meeting
∙Farah is to start Element 2 preparing 2 or 3 diagrams
∙Simone is to start Element 3 and produce drafts of the user interface
Next meeting arranged for: 17/10/2007
Time: 13:00
Meeting 3
Held on: 17/10/2007
Time: 13:00
Present at meeting: All
Agenda
1.Discussion about system requirements including:
∙Automatic / Manual Modes
∙Manual mode What can be done in manual mode?
(Possible solution is to allow the Automatic mode to start the procedures while the controller can monitor the situation from the control panel and alert the
emergency services. If the control panel is unmanned, the system would
automatically call the emergency services. In manual mode it is possible to
carry out a system check, configuration (e.g. thresholds values) etc.)
Agreed on
∙If Manual mode is entered, Automatic mode would continue with the procedures. However, the emergency services must be called by the
controller
∙The threat must be confirmed and all procedures start after confirmation
∙The system must respond within 1 second from alert, with confirmation and start of the procedures (revision needed)
∙Sensors are part of the system and therefore a function
Revision of work
1.Revision of Prototype functionality (Element 3)
2.Revision of Context diagrams and User Requirement Definition (Element 1)
3.Revision of draft on system models (Element 2)
4.Presentation of first draft prototype
5.Work to be carried out before next meeting
∙Redefinition of User and System Requirements specification
∙Extend functionality of prototype
∙Produce few more diagrams of the system model
Next meeting arranged for: 25/10/2007
Meeting 4
Held on: 25/10/2007
Time: 13:00
Present at meeting: All
Agenda
1.Discussion about system requirements:
2.Prototype evaluation
Agreed on
∙The system is mainly automatic. User’s activities are limited to monitoring and configuration
∙Sensors check can be both automatic and manual
∙System test can be both automatic and manual
∙Emergency services can be called both automatically and manually
3.Work to be carried out before next meeting
∙Each member is to complete each element of the assignment
Next meeting arranged for: 5/11/2007
Meeting 5
Held on: 5/11/2007
Time: 13:00
Present at meeting: All
Agenda
1.Produce the report including all elements into one document。