air - User contributions [en]

Proj-2012-2013-BuildingManagementSystem

2013-04-11T16:49:38Z

Ruy.DE OLIVEIRA: /* Useful links */

We are 3 RICM4 students from [[Polytech Grenoble]]: Mame Daba DIOUF, Michael COSTA DE CASTRO, Ruy Guilherme SILVA GOMES DE OLIVEIRA and one architect student from [[ENSAG]]: Francine OURIQUES, in partnership with Saint Gobain, Giga Concept and Intel Software Labs.

==Objective==

The objective of this project is to design and prototype a subsystem of temperature control and air quality ([[HVAC]])of a building management system.

Project's SRS: [[Proj-2012-2013-BuildingManagementSystem/SRS]]

==Progress==

==Week 1 : 2013/01/14 - 2013/01/20==
* Choice of the subject.

* Group formation.

* Scientific monitoring.

==Week 2 : 2013/01/21 - 2013/01/27==
* Familiarization with Arduino, training about Arduino

* Meeting at the fab-lab (CaseMate)

* Writing of the Software Requirements Specification ([[SRS]])

==Week 3 : 2013/01/28 - 2013/02/03==
* Writing of [[UML diagrams]]

* Designing house's model

==Week 4 : 2013/02/04 - 2013/02/10==
* Meeting with architect students

* Writing of usecase diagram

==Week 5 : 2013/02/11 - 2013/02/17==
* Meeting with architect students: discussion about the house's model

* Using of Arduino and Java (Firmata/Processing)

==Week 6 : 2013/02/18 - 2013/02/24==

* Writing of UML diagrams

* Testing materials (keypad) with Arduino

==Week 7 : 2013/03/04 - 2013/03/10==

* Testing materials (temperature sensor DS18S20) with Arduino

==Week 8 : 2013/03/11 - 2013/03/17==

* Changing technologies (from JAVA and Processing to Nodejs, MongoDB, ...)

==Week 9 : 2013/03/18 - 2013/03/24==

* Familiarization with Nodejs and MongoDB, installation, tests...

* Writing classes in JavaScript

==Week 10 : 2013/03/25 - 2013/03/31==

* Communication Arduino and Nodejs with some materials (temperature sensor, keypad)

* Recording and storing data from Arduino in MongoDB

==Useful links==
* Presentation: [[Media:BMS_Presentation.pdf | BMS_Presentation.pdf]]

* Report: [[Media:BMS_Report.pdf | BMS_Report.pdf]]

* Poster: [[Media:BMS_Poster.pdf | BMS_Poster.pdf]]

* Source Code: https://github.com/ruyoliveira/BMS

UML diagrams

2013-02-24T21:03:57Z

Ruy.DE OLIVEIRA:

=BMS UML Diagrams=

== UseCase diagram==
[[File:UseCases.png]]

==Package Diagram==
[[File:Proj-2012-2013-BuildingManagementSystem-CDPackage.png]]

==Class Diagram==
===HVAC Package===
[[File:Proj-2012-2013-BuildingManagementSystem-DCPackageHVACControl.png|1000px]]
===BMS Package===
[[File:Proj-2012-2013-BuildingManagementSystem-CDBMSPackage.png|1200px]]

==Object Diagram==
[[File:Proj-2012-2013-BuildingManagementSystem-ODBMS.png|1200px]]

==Deployment Diagram==
[[File:Proj-2012-2013-BuildingManagementSystem-DDBMS.png|1200px]]

UML diagrams

2013-02-24T21:02:26Z

Ruy.DE OLIVEIRA:

=BMS UML Diagrams=

== UseCase diagram==
[[File:UseCases.png]]

==Package Diagram==
[[File:Proj-2012-2013-BuildingManagementSystem-CDPackage.png]]

==Class Diagram==
===HVAC Package===
[[File:Proj-2012-2013-BuildingManagementSystem-DCPackageHVACControl.png|1000px]]
===BMS Package===
[[File:Proj-2012-2013-BuildingManagementSystem-CDBMSPackage.png|1000px]]

==Object Diagram==
[[File:Proj-2012-2013-BuildingManagementSystem-ODBMS.png|1200px]]

==Deployment Diagram==
[[File:Proj-2012-2013-BuildingManagementSystem-DDBMS.png|1200px]]

File:Proj-2012-2013-BuildingManagementSystem-CDPackage.png

2013-02-24T20:57:04Z

Ruy.DE OLIVEIRA:

UML diagrams

2013-02-24T20:56:54Z

Ruy.DE OLIVEIRA:

=BMS UML Diagrams=

== UseCase diagram==
[[File:UseCases.png]]

==Package Diagram==
[[File:Proj-2012-2013-BuildingManagementSystem-CDPackage.png]]

==Class Diagram==
===HVAC Package===
[[File:Proj-2012-2013-BuildingManagementSystem-DCPackageHVACControl.png]]

===BMS Package===
[[File:Proj-2012-2013-BuildingManagementSystem-CDBMSPackage.png]]

==Object Diagram==
[[File:Proj-2012-2013-BuildingManagementSystem-ODBMS.png]]

==Deployment Diagram==
[[File:Proj-2012-2013-BuildingManagementSystem-DDBMS.png]]

File:Proj-2012-2013-BuildingManagementSystem-DDBMS.png

2013-02-24T20:50:16Z

Ruy.DE OLIVEIRA:

UML diagrams

2013-02-24T20:49:57Z

Ruy.DE OLIVEIRA:

=BMS UML Diagrams=

== UseCase diagram==
[[File:UseCases.png]]

==Class Diagram==
===HVAC Package===
[[File:Proj-2012-2013-BuildingManagementSystem-DCPackageHVACControl.png]]

===BMS Package===
[[File:Proj-2012-2013-BuildingManagementSystem-CDBMSPackage.png]]

==Object Diagram==
[[File:Proj-2012-2013-BuildingManagementSystem-ODBMS.png]]

==Deployment Diagram==
[[File:Proj-2012-2013-BuildingManagementSystem-DDBMS.png]]

File:Proj-2012-2013-BuildingManagementSystem-ODBMS.png

2013-02-24T20:47:37Z

Ruy.DE OLIVEIRA:

UML diagrams

2013-02-24T20:45:06Z

Ruy.DE OLIVEIRA:

File:Proj-2012-2013-BuildingManagementSystem-CDBMSPackage.png

2013-02-24T20:41:54Z

Ruy.DE OLIVEIRA:

UML diagrams

2013-02-24T20:41:41Z

Ruy.DE OLIVEIRA:

File:Proj-2012-2013-BuildingManagementSystem-DCPackageHVACControl.png

2013-02-24T20:37:15Z

Ruy.DE OLIVEIRA:

UML diagrams

2013-02-24T20:35:12Z

Ruy.DE OLIVEIRA:

=BMS UML Diagrams=

== UseCase diagram==
[[File:UseCases.png]]

==Class Diagram==
===HVAC Control Package===
[[File:Proj-2012-2013-BuildingManagementSystem-DCPackageHVACControl.png]]

UML diagrams

2013-02-24T20:31:25Z

Ruy.DE OLIVEIRA:

=BMS UML Diagrams=

== UseCase diagram==
[[File:UseCases.png]]

SRS

2013-02-17T22:43:52Z

Ruy.DE OLIVEIRA:

The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard.

{|class="wikitable alternance"
|+ Document History
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| 2013/01/21
| Mame Daba Diouf
| TBC
| TBC
| TBC

|}

=1. Introduction=
==1.1 Purpose of the requirements document==

This document includes the descriptions of the software services and constraints that should be respected during its development.

It is intended to client engineers and managers, software developers, software users and contractors so that it allows them to understand and validate what the software will do.

==1.2 Scope of the product==

The name of the product is BMS.

BMS:

* Will control temperature, ventilation, lighting in a building, report residents’ preferences
* Will NOT include security monitor.

==1.3 Definitions, acronyms and abbreviations==

* BMS = Building Mangaement System
* HVAC = Heating Ventilation Air Conditionning

==1.4 References==

IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998

==1.5 Overview of the remainder of the document==

The rest of the document contains, along these lines :

- The overall descriptions

- The specific requirements and

- Supporting information

=2. General description=
==2.1 Product perspective==
==2.2 Product functions==

The major functions that the BMS will perform are :
* HVAC software programs
* Panel with LCD display
* Weekly time program (optional)
* Panel with internal temperature/pollution sensor (optional)

[[File:1.png]]

Here is an example of an usage of the BMS:

[[File:2.png]]

Action Flow:

1- The panel displays the current temperature

2- The user enters with the new temperature, 20 for example

3-The system sends the temperature to the sensor

4- The system saves the temperature in the server

5-The panel displays the new temperature.

==2.3 User characteristics==

The users (User and SuperUser) are expected to be able to use keypads in order to identify themselves and LCD panel controls.

The SuperUser is expected to be the master of the system and will be more powerful than the User.

==2.4 General constraints==

The use of the BMS is directly linked to the activities which are done by the occupiers of the building.

The system will not include security monitor such as burglar's prevention but it will allow users to go inside the building by identifying themselves with the right codes.

==2.5 Assumptions and dependencies==
=3.Specific requirements, covering functional, non-functional and interface requirements=
* document external interfaces,
* describe system functionality and performance
* specify logical database requirements,
* design constraints,
* emergent system properties and quality characteristics.

==3.1 Requirement X.Y.Z (in Structured Natural Language)==

[[File:UseCasesDiagram.png]]

'''Function''':

The system allows the user to:

*Control the temperature;

*Control the luminosity;

*Control the quality of the air;

*Store the preferences user;

*Count the number of people in the house.

'''Description''':

'''Inputs''':

*The user data;

*The data from sensors:

-Sensor of temperature;

-Sensor of luminosity;

-Sensor of quality of the air.

'''Source''':

*Sensor of temperature;

*Sensor of luminosity;

*Sensor of quality of the air;

*User.

'''Outputs''':

*Visualization of data on the screen of the tablet.

* LED access indicator in the home.

'''Destination''':

'''Action''':
* Natural language sentences (with MUST, MAY, SHALL)
* Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
* Mathematical Notations
* Tabular notations for several (condition --> action) tuples

'''Non functional requirements''':

'''Pre-condition''':

'''Post-condition''':

'''Side-effects''':

=4. Product evolution=
*Builded a mini house model, where will be implanted the BMS.

=5. Appendices=
=6. Index=

SRS

2013-02-17T22:28:36Z

Ruy.DE OLIVEIRA:

The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard.

{|class="wikitable alternance"
|+ Document History
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| 2013/01/21
| Mame Daba Diouf
| TBC
| TBC
| TBC

|}

=1. Introduction=
==1.1 Purpose of the requirements document==

This document includes the descriptions of the software services and constraints that should be respected during its development.

It is intended to client engineers and managers, software developers, software users and contractors so that it allows them to understand and validate what the software will do.

==1.2 Scope of the product==

The name of the product is BMS.

BMS:

* Will control temperature, ventilation, lighting in a building, report residents’ preferences
* Will NOT include security monitor.

==1.3 Definitions, acronyms and abbreviations==

* BMS = Building Mangaement System
* HVAC = Heating Ventilation Air Conditionning

==1.4 References==

IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998

==1.5 Overview of the remainder of the document==

The rest of the document contains, along these lines :

- The overall descriptions

- The specific requirements and

- Supporting information

=2. General description=
==2.1 Product perspective==
==2.2 Product functions==

The major functions that the BMS will perform are :
* HVAC software programs
* Panel with LCD display
* Weekly time program (optional)
* Panel with internal temperature/pollution sensor (optional)

[[File:1.png]]

Here is an example of an usage of the BMS:

[[File:2.png]]

Action Flow:

1- The panel displays the current temperature

2- The user enters with the new temperature, 20 for example

3-The system sends the temperature to the sensor

4- The system saves the temperature in the server

5-The panel displays the new temperature.

==2.3 User characteristics==

The users (User and SuperUser) are expected to be able to use keypads in order to identify themselves and LCD panel controls.

The SuperUser is expected to be the master of the system and will be more powerful than the User.

==2.4 General constraints==

The use of the BMS is directly linked to the activities which are done by the occupiers of the building.

The system will not include security monitor such as burglar's prevention but it will allow users to go inside the building by identifying themselves with the right codes.

==2.5 Assumptions and dependencies==
=3.Specific requirements, covering functional, non-functional and interface requirements=
* document external interfaces,
* describe system functionality and performance
* specify logical database requirements,
* design constraints,
* emergent system properties and quality characteristics.

==3.1 Requirement X.Y.Z (in Structured Natural Language)==

[[File:UseCasesDiagram.png]]

'''Function''':

The system allows the user

*Control the temperature;

*Control the luminosity;

*Control the quality of the air;

*Store the preferences user;

*Count the number of people in the house.

'''Description''':

'''Inputs''':

*The user data;

*The data from sensors:

-Sensor of temperature;

-Sensor of luminosity;

-Sensor of quality of the air.

'''Source''':

*Sensor of temperature;

*Sensor of luminosity;

*Sensor of quality of the air;

*User.

'''Outputs''':

*Visualization of data on the screen of the tablet.

* LED access indicator in the home.

'''Destination''':

'''Action''':
* Natural language sentences (with MUST, MAY, SHALL)
* Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
* Mathematical Notations
* Tabular notations for several (condition --> action) tuples

'''Non functional requirements''':

'''Pre-condition''':

'''Post-condition''':

'''Side-effects''':

=4. Product evolution=

=5. Appendices=
=6. Index=

SRS

2013-02-17T22:22:59Z

Ruy.DE OLIVEIRA:

The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard.

{|class="wikitable alternance"
|+ Document History
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| 2013/01/21
| Mame Daba Diouf
| TBC
| TBC
| TBC

|}

=1. Introduction=
==1.1 Purpose of the requirements document==

This document includes the descriptions of the software services and constraints that should be respected during its development.

It is intended to client engineers and managers, software developers, software users and contractors so that it allows them to understand and validate what the software will do.

==1.2 Scope of the product==

The name of the product is BMS.

BMS:

* Will control temperature, ventilation, lighting in a building, report residents’ preferences
* Will NOT include security monitor.

==1.3 Definitions, acronyms and abbreviations==

* BMS = Building Mangaement System
* HVAC = Heating Ventilation Air Conditionning

==1.4 References==

IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998

==1.5 Overview of the remainder of the document==

The rest of the document contains, along these lines :

- The overall descriptions

- The specific requirements and

- Supporting information

=2. General description=
==2.1 Product perspective==
==2.2 Product functions==

The major functions that the BMS will perform are :
* HVAC software programs
* Panel with LCD display
* Weekly time program (optional)
* Panel with internal temperature/pollution sensor (optional)

[[File:1.png]]

Here is an example of an usage of the BMS:

[[File:2.png]]

Action Flow:

1- The panel displays the current temperature

2- The user enters with the new temperature, 20 for example

3-The system sends the temperature to the sensor

4- The system saves the temperature in the server

5-The panel displays the new temperature.

==2.3 User characteristics==

The users (User and SuperUser) are expected to be able to use keypads in order to identify themselves and LCD panel controls.

The SuperUser is expected to be the master of the system and will be more powerful than the User.

==2.4 General constraints==

The use of the BMS is directly linked to the activities which are done by the occupiers of the building.

The system will not include security monitor such as burglar's prevention but it will allow users to go inside the building by identifying themselves with the right codes.

==2.5 Assumptions and dependencies==
=3.Specific requirements, covering functional, non-functional and interface requirements=
* document external interfaces,
* describe system functionality and performance
* specify logical database requirements,
* design constraints,
* emergent system properties and quality characteristics.

==3.1 Requirement X.Y.Z (in Structured Natural Language)==

[[File:UseCasesDiagram.png]]

'''Function''':

The system allows the user

*Control the temperature;

*Control the luminosity;

*Control the quality of the air;

*Store the preferences user;

*Count the number of people in the house.

'''Description''':

'''Inputs''':

*The user data;

*The data from sensors:

-Sensor of temperature;

-Sensor the luminosity;

-Sensor the quality of the air.

'''Source''':
The user;
The several sensors.

'''Outputs''':
Visualization of data on the screen of the tablet.
LED access indicator in the home.

'''Destination''':

'''Action''':
* Natural language sentences (with MUST, MAY, SHALL)
* Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
* Mathematical Notations
* Tabular notations for several (condition --> action) tuples

'''Non functional requirements''':

'''Pre-condition''':

'''Post-condition''':

'''Side-effects''':

=4. Product evolution=

=5. Appendices=
=6. Index=

SRS

2013-02-17T22:21:42Z

Ruy.DE OLIVEIRA:

The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard.

{|class="wikitable alternance"
|+ Document History
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| 2013/01/21
| Mame Daba Diouf
| TBC
| TBC
| TBC

|}

=1. Introduction=
==1.1 Purpose of the requirements document==

This document includes the descriptions of the software services and constraints that should be respected during its development.

It is intended to client engineers and managers, software developers, software users and contractors so that it allows them to understand and validate what the software will do.

==1.2 Scope of the product==

The name of the product is BMS.

BMS:

* Will control temperature, ventilation, lighting in a building, report residents’ preferences
* Will NOT include security monitor.

==1.3 Definitions, acronyms and abbreviations==

* BMS = Building Mangaement System
* HVAC = Heating Ventilation Air Conditionning

==1.4 References==

IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998

==1.5 Overview of the remainder of the document==

The rest of the document contains, along these lines :

- The overall descriptions

- The specific requirements and

- Supporting information

=2. General description=
==2.1 Product perspective==
==2.2 Product functions==

The major functions that the BMS will perform are :
* HVAC software programs
* Panel with LCD display
* Weekly time program (optional)
* Panel with internal temperature/pollution sensor (optional)

[[File:1.png]]

Here is an example of an usage of the BMS:

[[File:2.png]]

Action Flow:

1- The panel displays the current temperature

2- The user enters with the new temperature, 20 for example

3-The system sends the temperature to the sensor

4- The system saves the temperature in the server

5-The panel displays the new temperature.

==2.3 User characteristics==

The users (User and SuperUser) are expected to be able to use keypads in order to identify themselves and LCD panel controls.

The SuperUser is expected to be the master of the system and will be more powerful than the User.

==2.4 General constraints==

The use of the BMS is directly linked to the activities which are done by the occupiers of the building.

The system will not include security monitor such as burglar's prevention but it will allow users to go inside the building by identifying themselves with the right codes.

==2.5 Assumptions and dependencies==
=3.Specific requirements, covering functional, non-functional and interface requirements=
* document external interfaces,
* describe system functionality and performance
* specify logical database requirements,
* design constraints,
* emergent system properties and quality characteristics.

==3.1 Requirement X.Y.Z (in Structured Natural Language)==

[[File:UseCasesDiagram.png]]

'''Function''':
The system allows the user
*Control the temperature;
*Control the luminosity;
*Control the quality of the air;
*Store the preferences user;
*Count the number of people in the house.

'''Description''':

'''Inputs''':
*The user data;
*The data from sensors:
-Sensor of temperature;
-Sensor the luminosity;
-Sensor the quality of the air.

'''Source''':
The user;
The several sensors.

'''Outputs''':
Visualization of data on the screen of the tablet.
LED access indicator in the home.

'''Destination''':

'''Action''':
* Natural language sentences (with MUST, MAY, SHALL)
* Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
* Mathematical Notations
* Tabular notations for several (condition --> action) tuples

'''Non functional requirements''':

'''Pre-condition''':

'''Post-condition''':

'''Side-effects''':

=4. Product evolution=

=5. Appendices=
=6. Index=

SRS

2013-02-17T22:15:02Z

Ruy.DE OLIVEIRA:

The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard.

{|class="wikitable alternance"
|+ Document History
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| 2013/01/21
| Mame Daba Diouf
| TBC
| TBC
| TBC

|}

=1. Introduction=
==1.1 Purpose of the requirements document==

This document includes the descriptions of the software services and constraints that should be respected during its development.

It is intended to client engineers and managers, software developers, software users and contractors so that it allows them to understand and validate what the software will do.

==1.2 Scope of the product==

The name of the product is BMS.

BMS:

* Will control temperature, ventilation, lighting in a building, report residents’ preferences
* Will NOT include security monitor.

==1.3 Definitions, acronyms and abbreviations==

* BMS = Building Mangaement System
* HVAC = Heating Ventilation Air Conditionning

==1.4 References==

IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998

==1.5 Overview of the remainder of the document==

The rest of the document contains, along these lines :

- The overall descriptions

- The specific requirements and

- Supporting information

=2. General description=
==2.1 Product perspective==
==2.2 Product functions==

The major functions that the BMS will perform are :
* HVAC software programs
* Panel with LCD display
* Weekly time program (optional)
* Panel with internal temperature/pollution sensor (optional)

[[File:1.png]]

Here is an example of an usage of the BMS:

[[File:2.png]]

Action Flow:

1- The panel displays the current temperature

2- The user enters with the new temperature, 20 for example

3-The system sends the temperature to the sensor

4- The system saves the temperature in the server

5-The panel displays the new temperature.

==2.3 User characteristics==

The users (User and SuperUser) are expected to be able to use keypads in order to identify themselves and LCD panel controls.

The SuperUser is expected to be the master of the system and will be more powerful than the User.

==2.4 General constraints==

The use of the BMS is directly linked to the activities which are done by the occupiers of the building.

The system will not include security monitor such as burglar's prevention but it will allow users to go inside the building by identifying themselves with the right codes.

==2.5 Assumptions and dependencies==
=3.Specific requirements, covering functional, non-functional and interface requirements=
* document external interfaces,
* describe system functionality and performance
* specify logical database requirements,
* design constraints,
* emergent system properties and quality characteristics.

==3.1 Requirement X.Y.Z (in Structured Natural Language)==

[[File:UseCasesDiagram.png]]

'''Function''':
The system allows the user
*Control the temperature;
*Control the luminosity;
*Control the quality of the air;
*Store the preferences user;
*Count the number of people in the house.

'''Description''':

'''Inputs''':
The data the user;

The data of the sensors:
• Sensor of temperature;
• Sensor the luminosity;
• Sensor the quality of the air.

'''Source''':
The user;
The several sensors.

'''Outputs''':
Visualization of data on the screen of the tablet.
LED access indicator in the home.

'''Destination''':

'''Action''':
* Natural language sentences (with MUST, MAY, SHALL)
* Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
* Mathematical Notations
* Tabular notations for several (condition --> action) tuples

'''Non functional requirements''':

'''Pre-condition''':

'''Post-condition''':

'''Side-effects''':

=4. Product evolution=

=5. Appendices=
=6. Index=

SRS

2013-02-17T22:12:15Z

Ruy.DE OLIVEIRA:

The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard.

{|class="wikitable alternance"
|+ Document History
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| 2013/01/21
| Mame Daba Diouf
| TBC
| TBC
| TBC

|}

=1. Introduction=
==1.1 Purpose of the requirements document==

This document includes the descriptions of the software services and constraints that should be respected during its development.

It is intended to client engineers and managers, software developers, software users and contractors so that it allows them to understand and validate what the software will do.

==1.2 Scope of the product==

The name of the product is BMS.

BMS:

* Will control temperature, ventilation, lighting in a building, report residents’ preferences
* Will NOT include security monitor.

==1.3 Definitions, acronyms and abbreviations==

* BMS = Building Mangaement System
* HVAC = Heating Ventilation Air Conditionning

==1.4 References==

IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998

==1.5 Overview of the remainder of the document==

The rest of the document contains, along these lines :

- The overall descriptions

- The specific requirements and

- Supporting information

=2. General description=
==2.1 Product perspective==
==2.2 Product functions==

The major functions that the BMS will perform are :
* HVAC software programs
* Panel with LCD display
* Weekly time program (optional)
* Panel with internal temperature/pollution sensor (optional)

[[File:1.png]]

Here is an example of an usage of the BMS:

[[File:2.png]]

Action Flow:

1- The panel displays the current temperature

2- The user enters with the new temperature, 20 for example

3-The system sends the temperature to the sensor

4- The system saves the temperature in the server

5-The panel displays the new temperature.

==2.3 User characteristics==

The users (User and SuperUser) are expected to be able to use keypads in order to identify themselves and LCD panel controls.

The SuperUser is expected to be the master of the system and will be more powerful than the User.

==2.4 General constraints==

The use of the BMS is directly linked to the activities which are done by the occupiers of the building.

The system will not include security monitor such as burglar's prevention but it will allow users to go inside the building by identifying themselves with the right codes.

==2.5 Assumptions and dependencies==
=3.Specific requirements, covering functional, non-functional and interface requirements=
* document external interfaces,
* describe system functionality and performance
* specify logical database requirements,
* design constraints,
* emergent system properties and quality characteristics.

==3.1 Requirement X.Y.Z (in Structured Natural Language)==

[[File:UseCasesDiagram.png]]

'''Function''':
The system allows the user to control:
*The temperature;
*The luminosity;
*The quality of the air.

To store the preferences user.

Count the number of people in the house.

'''Description''':

'''Inputs''':
The data the user;

The data of the sensors:
• Sensor of temperature;
• Sensor the luminosity;
• Sensor the quality of the air.

'''Source''':
The user;
The several sensors.

'''Outputs''':
Visualization of data on the screen of the tablet.
LED access indicator in the home.

'''Destination''':

'''Action''':
* Natural language sentences (with MUST, MAY, SHALL)
* Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
* Mathematical Notations
* Tabular notations for several (condition --> action) tuples

'''Non functional requirements''':

'''Pre-condition''':

'''Post-condition''':

'''Side-effects''':

=4. Product evolution=

=5. Appendices=
=6. Index=