TWIN Project Requirements Specification
TWIN Project Requirements Specification
Version 1.0
January 18, 2016
Table of Contents
1. Executive Summary 3
1.1 Project Overview 3
1.2 Purpose and Scope of this Specification 3
2. Product/Service Description 3
2.1 Product Context 3
2.2 User Characteristics 3
2.3 Assumptions 3
2.4 Constraints 3
2.5 Dependencies 4
3. Requirements 4
3.1 Functional Requirements 5
3.2 User Interface Requirements 5
3.3 Usability 5
3.4 Performance 6
3.4.1 Capacity 6
3.4.2 Availability 6
3.4.3 Latency 6
3.5 Manageability/Maintainability 6
3.5.1 Monitoring 6
3.5.2 Maintenance 6
3.5.3 Operations 6
3.6 System Interface/Integration 7
3.6.1 Network and Hardware Interfaces 7
3.6.2 Systems Interfaces 7
3.7 Security 8
3.7.1 Protection 8
3.7.2 Authorization and Authentication 8
3.8 Data Management 8
3.9 Standards Compliance 8
3.10 Portability 8
4. User Scenarios/Use Cases 9
5. Deleted or Deferred Requirements 9
6. Requirements Confirmation/Stakeholder sign-off 10
APPENDIX 11
Appendix A. Definitions, Acronyms, and Abbreviations 11
Appendix B. References 11
Appendix C. Requirements Traceability Matrix 11
Appendix D. Organizing the Requirements 13
1. Executive Summary
1.1 Project Overview
During this project a LED wall should be built to implement an Europe information system. The LED wall should be controllable by pupils at the four schools from Germany, Hungary, Italy and Poland taking part in the project. The displayed content should give information about the participating schools and the pupil’s home towns and their school lives.
1.2 Purpose and Scope of this Specification
The purpose of this specification is to define the hardware requirements for the LED wall. This specification is the basis for implementing the hardware during the first project phase.
The items within the scope of this requirement specification are described in the following:
In scope
This document addresses requirements related to phase 1 of the TWIN Project:
· Building a LED wall which is able to display certain digital contents.
· Controlling issues of the LED wall as far as hardware issues are concerned.
· Display quality issues.
· Mechanical issues (e.g. housing, transportability, …)
· Power requirements.
Out of Scope
The following items are out of scope in phase 1 of the TWIN Project:
· Software / programming issues.
· Connectivity to peripherals (smartphones, Bluetooth, wifi,…)
2. Product/Service Description
In this section, describe the general factors that affect the product and its requirements.
2.1 Product Context
The LED wall should be able to interface several wireless communication ports, e. g. Bluetooth or wifi. In addition to this the LED should be mounted in a room large enough to reach the optimal viewing distance. Apart from that all other context related product requirements will be defined of the software requirement specifications.
2.2 User Characteristics
The following users are expected to control the LED wall:
· Students / pupils will select and share information on the LED wall by using their smartphones
· Teachers and experienced students / pupils will update and service the contents.
2.3 Assumptions
The cost of LED wall fits in the budget and LED modules of a certain quality are available.
2.4 Constraints
· The size of the LED wall is limited by the mounting room.
· As the LED wall will be placed in a public building specific guidelines have to be obeyed (for example fire protection issues)
2.5 Dependencies
· The LED wall hardware has to be identical at all participating schools.
· The viewing distance is limited to 2-3 m.
3. Requirements
Priority Definitions
The following definitions are intended as a guideline to prioritize requirements.
· Priority 1 – The requirement is a “must have” as outlined by policy/law
· Priority 2 – The requirement is needed for improved processing, and the fulfillment of the requirement will create immediate benefits
· Priority 3 – The requirement is a “nice to have” which may include new functionality
3.1 Functional Requirements
Req# / Requirement / Priority /TWIN_01 / The LED wall should provide a resolution high enough to meet an optimal viewing distance of 2-3 m. / 1
TWIN_02 / The LED wall should be controlled by a microcontroller or a PC. / 1
TWIN_03 / The framerate of the LED wall should be sufficient for displaying videos. / 1
TWIN_04 / The size of the LED wall should be about 2m x 1.5m. / 1
TWIN_05 / The LED wall should be able to display typical widescreen formats. / 1
TWIN_06 / The LED wall should consists of full color LEDs / 1
TWIN_07 / The brightness of the LED wall should be sufficient for indoor use. / 1
TWIN_08 / The housing of the LED wall should be in compliance with the legal fire protection requirements. / 1
3.2 User Interface Requirements
The User Interface Requirements are part of the software requirement specifications and out of the scope of these requirements.
3.3 Usability
The Usability is part of the software requirement specifications and out of the scope of these requirements.
3.4 Performance
The Performance is part of the software requirement specifications and out of the scope of these requirements.
3.4.1 Capacity
The Capacity is part of the software requirement specifications and out of the scope of these requirements.
3.4.2 Availability
· Hours of operation: 8 hours per day, five days a week
· Level of availability required: no safety issues, therefore restoration of availability within one week
· Impact of downtime on users and business operations: None.
· Reliability: acceptable mean time between failures (MTBF): 8 days.
3.4.3 Latency
The maximum acceptable time for a service request is one week.
3.5 Manageability/Maintainability
3.5.1 Monitoring
The LED wall should be protected by a virus scanner / fire wall to prevent any unauthorized manipulation.
3.5.2 Maintenance
The Maintenance is part of the software requirement specifications and out of the scope of these requirements.
3.5.3 Operations
The Operations are part of the software requirement specifications and out of the scope of these requirements.
3.6 System Interface/Integration
3.6.1 Network and Hardware Interfaces
The used hardware interfaces highly depend on the software requirement specifications and therefore are out of the scope of these requirements.
3.6.2 Systems Interfaces
The System Interfaces are part of the software requirement specifications and out of the scope of these requirements.
3.7 Security
3.7.1 Protection
The LED wall should be protected by a virus scanner / fire wall to prevent any unauthorized manipulation.
3.7.2 Authorization and Authentication
Authorization and Authentication issues will be discussed in the software requirement specifications.
3.8 Data Management
Data Management issues will be discussed in the software requirement specifications.
3.9 Standards Compliance
The housing of the LED wall should be in compliance with the legal fire protection requirements.
3.10 Portability
In some schools a portable version of the LED wall is necessary: The portability only concerns mechanical movements of the LED wall. The LED wall will not be moved during operation.
4. User Scenarios/Use Cases
The content displayed on the LED wall should give information about the participating schools and the pupil’s home towns and their school lives. The information should be selected by using a smartphone.
5. Deleted or Deferred Requirements
Req# / Requirement / Status / PriorityTWIN_09 / The LED wall should provide a live video chat functionality / Deferred to phase 2 (software development phase) / 3
6. Requirements Confirmation/Stakeholder sign-off
Meeting Date / Attendees (name and role) / Comments11/16/2015-11/20/2015
January 18, 2016 Page 7 of 7