|
Requirements specification
Revision A - 14 MARCH 1996
|
| | Name | Position | E-mail address |
|---|
| Author: | Requirements team | | |
| Responsible: | Johan Sassner | Team Manager | pt93js@pt.hk-r.se |
| To: | Hans Ottosson
Anders Angelhag | Customer
Customer | hans.ottosson@sydkraft.se
anders.angelhag@telecom.sydkraft.se |
| Cc: | SAIDA
Fredrik Ygge
Peter Molin | Project
Technical Advisor
Head of Department | saida@pt.hk-r.se
fredrik.ygge@ide.hk-r.se
peter.molin@ide.hk-r.se |
| Revision | Approver(s) | Insp. level | Insp. date |
|---|
| reva | Martin Fredriksson | shallow | 1996-02-21 |
1 Introduction
1.1 Purpose
The power market is evolving in such a way that power suppliers will be competing much more intensely for customers. In order to be competitive as a power supplier you have to be able to offer both present and potential customers extra services. Sydkraft has appreciated this situation and is currently researching different ways to achieve this.
The potential services do not only include selling cheaper power at certain periods, but also possibilities to supervise and monitor the power consumption. Customers will get the possibility to buy power at a lower price if they, for instance, can accept having their heater turned off during consumption peaks. Ultimately this will lead to reduced expenses for Sydkraft and their customers.
Sydkraft also wants to let their customers control and supervise their domestic appliances externally, e.g. via Internet with the use of tools like WWW browsers and E-mail. Of course, Sydkraft is also interested in controlling and supervising their power grid in a more flexible and inexpensive way.
SAIDA will aim at helping Sydkraft implementing these features.
1.2 System overview
Figure [1-1] describes the realationship between the system and its intended users. Usage can be said to be either from the appliction side or from the management/control side.
System overview
In figure [1-2] the CCN is described in some more details. Everything included in the grey area and the interfaces out from the CCN, shall be the result when the project is completed.
The CCN in detail
2 Interface requirements
2.1 Utility Interface (UTI)
2.1.1 Top level requirements
Functional requirements
F1 Service applications shall be able to export device data to standard applications. [F2,F3]
F2 Device data shall be both readable and writeable. [A3,A4]
Attribute requirements
A1 The UIF shall be highly available. [F4,A2.A5]
2.1.2 Bottom level requirements
Functional requirements
F3 Standard applications shall be able to use/update device data without the need of additional programming.
F4 Device data shall not be lost while other processes occupies the CCN.
Attribute requirements
The UIF shall...
A2 ... be able to manage user accesses concurrently.
A3 ... read device data quickly.
A4 ... write device data quickly.
A5 ... respond quickly to requests.
| AttrNr | Scale | Worst |
|---|
| A1 | Availability (hours a day) | 23 hours |
| A2 | Request throughput (percent of users getting the requested data per hour) | 80% |
| A3 | Transfer rate in the CCN (bytes per second) | 1 Kb/s |
| A4 | Transfer rate in the CCN (bytes per second) | 1 Kb/s |
| A5 | Response time (seconds) | 5 s |
2.2 Global Communication Interface (GCI)
2.2.1 Top level requirements
Functional requirements
F5 Device data shall be accessible via WWW. [A6,A7]
F6 It shall be possible for the CCN to receive e-mail from both a node (if the node is capable of sending an e-mail) and from the global system. [A9]
F7 The CCN shall be able to send e-mail to both a node (if a node is capable to receive an e-mail) and to the global system. [A10]
F8 It shall be possible to monitor a nodes behaviour via e-mail by request or subscribing.
2.2.2 Bottom level requirements
Attribute requirements
A6 Several users shall be able to access device data via WWW concurrently. [A8]
A7 Device data shall be available via WWW.
A8 The CCN shall respond quickly to a user request via WWW.
A9 The CCN shall be able to handle several incoming e-mails concurrently from several nodes.
A10 The CCN shall be able to send big e-mails to a node.
| AttrNr | Scale | Worst |
|---|
| A6 | Request throughput (percent of requested data per hour successfully carried out) | 80% |
| A7 | Availability (hours a day) | 23 hours |
| A8 | Response time in the CCN (seconds) | 5 s |
| A9 | Concurrency (number of concurrently incoming e-mails managed by the CCN) | 10 |
| A10 | Size of e-mail (bytes) | 3 Kb |
2.3 LAN Developer's Interface (LDI)
2.3.1 Top level requirements
Functional requirements
It shall be possible to...
F9 ... manage NeuronC programs in a node from remote. [F13,F14,F15,F16,A11]
F10 ... control NeuronC programs in a node from remote. [F17,F18,F19,A11]
F11 ... configure the LAN structure dynamically. [F20,F21,F22,A11]
F12 ... monitor all messages sent over the network.
2.3.2 Bottom level requirements
Functional requirements
It shall be possible to...
F13 ... receive NeuronC programs on the CCN.
F14 ... compile NeuronC programs on the CCN.
F15 ... install NeuronC programs in a node.
F16 ... remove NeuronC programs in a node.
F17 ... start NeuronC programs in a node. [A12]
F18 ... stop NeuronC programs in a node. [A13]
F19 ... debug a NeuronC program in a node.
F20 ... add a new node to the LAN.
F21 ... remove a node from the LAN.
F22 ... bind addresses in the LAN.
Attribute requirements
A11 ... access the LDI concurrently.
A12 The CCN shall respond quickly to start requests.
A13 The CCN shall respond quickly to stop requests.
| AttrNr | Scale | Worst |
|---|
| A11 | Concurrency (users at a time) | 2 |
| A12 | The delay introduced by the CCN (seconds) | 10 s |
| A13 | The delay introduced by the CCN (seconds) | 5 s |
2.4 Service Applications Interface (SAI)
2.4.1 Top level requirements
Functional requirements
It shall be possible...
F23 ... for a user to do the same operations remotely as he/she can do locally, except operations requiring physical interaction, e.g. disk changing. [A18]
F24 ... to manage the service applications in the CCN through the service interface. [F27,F28,F29]
F25 ... to control the service applications in the CCN through the service interface. [F30,F31,F32]
F26 Service applications shall be able to run concurrently.
Attribute requirements
A14 The SAI shall be available. [A17]
2.4.2 Bottom level requirements
Functional requirements
It shall be possible...
F27 ... to download service applications to the CCN.
F28 ... to install service applications in the CCN. [A16]
F29 ... to remove service applications from the CCN.
F30 ... to start the service applications in the CCN.
F31 ... to stop the service applications in the CCN.
F32 ... to debug the service applications in the CCN.
Attribute requirements
A15 ... to exchange service applications in the CCN.
A16 ... to install service applications to the CCN quickly.
A17 ... to use the SAI concurrently.
A18 The SAI shall respond quickly to commands.
| AttrNr | Scale | Worst |
|---|
| A14 | Availability (hours a day) | 23 hours |
| A15 | Time to change the application (minutes) | 60 min |
| A16 | The delay introduced by the CCN (seconds) | 60 s |
| A17 | Request throughput (percent of users getting the requested service per hour) | 80% |
| A18 | Response time (seconds) | 10 s |
3 Application requirements
3.1 Service Applications (SEA)
3.1.1 Top level requirements
Functional requirements
F33 An application service shall be able to export alarm signals to the global system. [A19]
3.1.2 Bottom level requirements
Attribute requirements
A19 The CCN shall export the alarm signal.
| AttrNr | Scale | Worst |
|---|
| A19 | The delay introduced by the CCN (seconds) | 60 s |
4 APPENDIX A
4.1 Terminology
4.1.1 Local Area Network (LAN)
The LAN consists of nodes, connected in a network, which in this project is the Lonworks architecture with Neuron chips.
4.1.2 Concentrator Communication Node (CCN)
The CCN connects the LAN to the rest of the world. Service applications run in the CCN and provides functionality for e.g. collecting data.
4.1.3 Node
A node is a chip which monitors and controls a domestic appliance. It communicates with the CCN and other nodes via the LAN.
4.1.4 Service Application (SEA)
A service application runs in the CCN and communicates through the Utility Interface, LAN Developers' Interface, Global Communication Interface and Service Application Interface. It offers services like e-mailing, collecting data from a node, monitoring network traffic etc.
4.1.5 Standard Application (STA)
A standard application is a program that can use device data via the CCN, e.g. Lotus 1-2-3, Quattro Pro and MS Excel.
4.1.6 World Wide Web (WWW)
WWW provides means to graphically display information over Internet using the HTML hypertext format.
4.1.7 E-mail
E-mail provides means to send messages over a network.
4.1.8 Global system
The external clients of the Utility Interface, LAN Developers' Interface, Global Communication Interface and Service Application Interface..
4.1.9 Device data (DD)
Device data represents the current state of a nodes collected data, e.g. the temperature of a heater.
4.1.10 Utility Interface (UTI)
The interface towards the services provided by the CCN (service applications) and is used by Sydkraft's employees e.g. business administrators.
4.1.11 Global Communication Interface (GCI)
An interface which provides possibilities for the customer to monitor and control different electronic devices through e.g. WWW and e-mail.
4.1.12 LAN Developer's Interface (LDI)
An interface used by the node application developers.
4.1.13 Service Application Interface (SAI)
An interface used by the service application- and system developer.
4.1.14 Attribute terminology
4.1.14.1 AttrNr
A unique identifier.
4.1.14.2 Scale
A defined range of values within which the fulfilment of a requirement can be said to be at a discrete value.
4.1.14.3 Worst
The worst acceptable level of the attribute.
5 APPENDIX B
5.1 References
[Gilb 88] Gilb, T., "Principles of software engineering management" - 2.ed - Addison-Wesley Publishing Company, 1988.
[Ygge 96] Ygge, F., "PheasantPro Project Description, Version 1.0", - v1.0 - University of Karlskrona/Ronneby, 1996.
[QMG 96] Quality Management Group, "Requirements specification procedure", - pa2 - University of Karlskrona/Ronneby, 1996.
[SAIDA 96] The SAIDA project, "Why-Analysis", University of Karlskrona/Ronneby, 1996.
- Requirements specification
-
- 1 - Introduction
-
- 1.1 - Purpose
-
- 1.2 - System overview
-
- 2 - Interface requirements
-
- 2.1 - Utility Interface (UTI)
-
- 2.1.1 - Top level requirements
-
- Functional requirements
-
- Attribute requirements
-
- 2.1.2 - Bottom level requirements
-
- Functional requirements
-
- Attribute requirements
-
- 2.2 - Global Communication Interface (GCI)
-
- 2.2.1 - Top level requirements
-
- Functional requirements
-
- 2.2.2 - Bottom level requirements
-
- Attribute requirements
-
- 2.3 - LAN Developer's Interface (LDI)
-
- 2.3.1 - Top level requirements
-
- Functional requirements
-
- 2.3.2 - Bottom level requirements
-
- Functional requirements
-
- Attribute requirements
-
- 2.4 - Service Applications Interface (SAI)
-
- 2.4.1 - Top level requirements
-
- Functional requirements
-
- Attribute requirements
-
- 2.4.2 - Bottom level requirements
-
- Functional requirements
-
- Attribute requirements
-
- 3 - Application requirements
-
- 3.1 - Service Applications (SEA)
-
- 3.1.1 - Top level requirements
-
- 3.1.2 - Bottom level requirements
-
- Attribute requirements
-
- 4 - APPENDIX A
-
- 4.1 - Terminology
-
- 4.1.1 - Local Area Network (LAN)
-
- 4.1.2 - Concentrator Communication Node (CCN)
-
- 4.1.3 - Node
-
- 4.1.4 - Service Application (SEA)
-
- 4.1.5 - Standard Application (STA)
-
- 4.1.6 - World Wide Web (WWW)
-
- 4.1.7 - E-mail
-
- 4.1.8 - Global system
-
- 4.1.9 - Device data (DD)
-
- 4.1.10 - Utility Interface (UTI)
-
- 4.1.11 - Global Communication Interface (GCI)
-
- 4.1.12 - LAN Developer's Interface (LDI)
-
- 4.1.13 - Service Application Interface (SAI)
-
- 4.1.14 - Attribute terminology
-
- 4.1.14.1 - AttrNr
-
- 4.1.14.2 - Scale
-
- 4.1.14.3 - Worst
-
- 5 - APPENDIX B
-
- 5.1 - References
-
Info
Team
WebCam
Documents
Schedule
CustomerOnly
© 1996, The SAIDA Project