Requirements¶
Hint
An interactive Excel tool to collect, prioritise and trace requirements (by Use Case) is available at empirica. Among others, it can also be used for surveys among staff and to calculate the result.
Any use of the list below must reference empirica GmbH.
Functional¶
Functional requirements capture the intended behaviour of the system or what the system will do. This behaviour may be expressed as services, tasks or functions the system is required to perform.
This category is referenced with the capital “F” or “1”.
R1.1. Output Format (OF)¶
Specifies the following requirements associated with the degree to which the SMARTSPACES service must allow for different output formats. Background: Data recorded needs a format to be visualised which might differ depending on environment and purpose of the selected information.
R1.1.1 Web-portal The service shall be accessible via a web-portal based on menus. R1.1.2 Web-portal - Dashboard The service shall be accessible via a web-portal with a dashboard. R1.1.3 Website The service shall be able to display automatically updated information on a public website (e.g. Local Authority website). R1.1.4 Mobile-App The service shall be accessible via a mobile application. R1.1.5 Social Networks The service shall be able to push selected information automatically and /or upon request to social networks (e.g. facebook, twitter). R1.1.6 Public Screen The service shall be able to display automatically updated information on a public screen. R1.1.7 TV The service shall be able to display automatically updated information on a TV (which can be public). R1.1.8 Email The service shall send automatic emails depending on settings defined by user or admin. R1.1.9 SMS The service shall send automatic sms depending on settings defined by user or admin. R1.1.10 Binary Signal The service shall send a binary signal to devices indicating the status and / or proposed activity specific devices (e.g. LEDs attached to windows indicating with red that window should be shut and green that it should be opened). R1.1.11 PDF The service shall allow for export of reports from at least one application as a PDF. R1.1.12 Poster The service shall be able to automatically produce poster reports with consumption information. R1.1.13 Paper The service shall be able to automatically produce paper-based reports with consumption information that can be sent as a letter. R1.1.14 (Eco)Maps The service shall provide information to a mapping service readable by common GIS standards. R1.1.15 Export-Table format The service shall allow for export of data tables (from one user or more) in a format readable by standard (e.g. csv or xls) software such as Excel. R1.1.16 Export-Database The service shall allow for export of large amounts of data in form of a database of a format that can be imported by most standard applications. R1.1.17 Access-Webservice The service shall allow for on-demand access to data in standardised json/xml format.
R1.2. Visualisation-Data (VID)¶
Specifies the following requirements associated with the degree to which the SMARTSPACES service must visualise resource data recorded. Background: Not all data recorded must necessarily be visualised in any of the output formats listed above, some data might only be used for internal calculations. The list indicates all data sets to be visualised.
R1.2.1 Resource-Electricity The service shall visualise the resource consumption for electricity. R1.2.2 Resource-Heating The service shall visualise the resource consumption for heating. R1.2.3 Resource-Cooling The service shall visualise the resource consumption for cooling. R1.2.4 Resource-Water(warm) The service shall visualise the resource consumption for water (warm). R1.2.5 Resource-Water(cold) The service shall visualise the resource consumption for water (cold). R1.2.6 Resource-Water(grey) The service shall visualise the resource consumption for water (grey). R1.2.7 Resource-Waste The service shall visualise the resource consumption for waste. R1.2.8 Resource-Solar(Heat) The service shall visualise the resource production of heat through solar input. R1.2.9 Resource-Solar(Electricity) The service shall visualise the resource production of electricity through solar input. R1.2.10 Resource-DistrictHeating The service shall visualise the resource consumption from a district heating grid. R1.2.11 Resource-CO2 The service shall visualise the resource production of CO2. R1.2.12 Resource-Gas The service shall visualise the resource consumption of gas. R1.2.13 Resource-Oil The service shall visualise the resource consumption of oil. R1.2.14 Resource-Diesel The service shall visualise the resource consumption of diesel. R1.2.15 Resource-Biofuel The service shall visualise the resource consumption of biofuels. R1.2.16 Currency The service shall visualise the cost of consumption for a given resource in the local currency. R1.2.17 Occupancy-Room The service shall visualise the occupancy of rooms by displaying whether rooms were and/or are occupied. R1.2.18 Occupancy-Individuals The service shall visualise the number of individuals who were and/or are in the building. R1.2.19 Status The service shall visualise the status of a space (e.g. building) or a unit of the building (e.g. boiler) for one or more resources and / or other variables according to a standardised status symbol. R1.2.20 Location The service shall visualise the location of buildings. R1.2.21 Environment-Weather The service shall visualise the outside weather conditions at least on the level of the municipality. R1.2.22 Environment-Temperature The service shall visualise the temperature in a given space. R1.2.23 Environment-Humidity The service shall visualise the humidity in a given space. R1.2.24 Environment-Carbon concentration The service shall visualise the carbon concentration (amount of CO2) in a given space.
R1.4. Benchmarks (BE)¶
Specifies the following requirements associated with the degree to which the SMARTSPACES service must be able to benchmark consumption of resources against a similar set of recorded or forecasted data. Background: The data sets selected to be visualised need to be brought into context and perspective (e.g. comparing the consumption before and after introducing SMARTSPACES over time).
R1.4.1 Time-Year Visualisation shall allow for benchmarking a period of one year against the same previous period (or more periods). R1.4.2 Time-semi-annually Visualisation shall allow for benchmarking a period of six months against the same previous period (or more periods or any other period). R1.4.3 Time-quarterly Visualisation shall allow for benchmarking a period of three months against the same previous period (or more periods or any other period). R1.4.4 Time-monthly Visualisation shall allow for benchmarking a period of one month against the same previous period (or more periods or any other period). R1.4.5 Time-weekly Visualisation shall allow for benchmarking a period of one week against the same previous period (or more periods or any other period). R1.4.6 Time-daily Visualisation shall allow for benchmarking a period of one day against the same previous period (or more periods or any other period). R1.4.7 Time-hourly Visualisation shall allow for benchmarking a period of one hour against the same previous period (or more periods or any other period). R1.4.8 Time-30minutes Visualisation shall allow for benchmarking a period of thirty minutes against the same previous period (or more periods or any other period). R1.4.9 Time-15minutes Visualisation shall allow for benchmarking a period of fifteen minutes against the same previous period (or more periods or any other period). R1.4.10 Time-minute Visualisation shall allow for benchmarking a period of one minute against the same previous period (or more periods or any other period). R1.4.11 Time-FreeSetting Visualisation shall allow for benchmarking a period defined by the user against the same previous period (or more periods or any other period). R1.4.12 Space-Building Visualisation shall allow for benchmarking of one building against any other (or more). R1.4.13 Space-Floor Visualisation shall allow for benchmarking of one floor against any other (or more). R1.4.14 Space-Room Visualisation shall allow for benchmarking of one room against any other (or more). R1.4.15 Space-Zone Visualisation shall allow for benchmarking of one zone against any other (or more). R1.4.16 Space-Surface Visualisation shall allow for benchmarking of one surface against any other (or more). R1.4.17 Staff Visualisation shall allow for benchmarking of one member of staff against any other (or more). R1.4.18 Percentiles - weekly profile Visualisation shall allow for benchmarking a period of one week at half-hourly intervals against weekly profiles calculated from percentiles of half-hourly data from the last given period (e.g. 12 months) and for the same space (e.g. building). R1.4.19 Percentiles - daily totals Visualisation shall allow for benchmarking a period of one day against daily percentiles (for each day of the week) from the last given period (e.g. 12 months) for the same space (e.g. building).
R1.6. Alerts (AL)¶
Specifies the following requirements associated with the degree to which the SMARTSPACES service must be able to automatically send alerts based on the recorded data and settings entered. Background: Certain events trigger higher consumption (short and / or long term). Detecting these events early can help to reduce the effects (e.g. boiler does not reach the most efficient temperature).
R1.6.1 Mutliple Alert Settings The service shall allow for setting multiple alerts with varying conditions. R1.6.2 Multiple User Settings The service shall allow for multiple users setting alerts with varying conditions. R1.6.3 Channel-Portal The service shall allow for sending / displaying the alert on the portal. R1.6.4 Channel-Mail The service shall allow for sending the alert as an email. R1.6.5 Channel-SMS The service shall allow for sending the alert as a SMS. R1.6.6 Channel-Application The service shall allow for sending / displaying the alert on a designated application. R1.6.7 Maximum Threshold The service shall allow for setting a maximum threshold of consumption of a given resource during a given period (e.g. month) above which an alert is sent to the user. R1.6.8 Minimum Threshold The service shall allow for setting a minimum threshold of consumption of a given resource during a given period (e.g. month) below which an alert is sent to the user. R1.6.9 Events-Failure The service shall send alerts for failures detected directly or indirectly (e.g. consumption pattern) of given system. R1.6.10 Events-Peak The service shall send alerts for (unexpected) peak consumption detected directly or indirectly (e.g. consumption pattern) of given system or resource. R1.6.11 Events-Free The service shall send alerts for events defined by the user for a given system or resource.
R1.7. Forecasting (FOR)¶
Specifies the following requirements associated with the degree to which the SMARTSPACES service must be able to forecast consumption based on the recorded data and settings entered. Background: Being able to forecast tomorrows consumption allows to set more efficient consumption profiles (e.g. if the predicted heat consumption for the next day is higher, due to temperature or more rooms occupied, the boiler unit can start earlier and work on a steady temperature instead of being used at maximum capacity as a reaction to cold rooms).
R1.7.1 Consumption-Year The service shall forecast the total consumption of a given resource for the running or the next year based on recorded data. R1.7.2 Consumption-Quarterly The service shall forecast the total consumption of a given resource for the running or the next quarter based on recorded data. R1.7.3 Consumption-Month The service shall forecast the total consumption of a given resource for the running or the next month based on recorded data. R1.7.4 Consumption-Week The service shall forecast the total consumption of a given resource for the running or the next week based on recorded data. R1.7.5 Consumption-Day The service shall forecast the total consumption of a given resource for the running or the next week based on recorded data. R1.7.6 Consumption-Hour The service shall forecast the total consumption of a given resource for the running or the next year based on recorded data. R1.7.7 Minimal Demand The service shall forecast the minimum amount of a given resource demanded for a given period in a given space. R1.7.8 Absence The service shall forecast periods where a given space is not occupied. R1.7.9 Peaks The service shall forecast peaks based on data from the previous period(s) for a given resource. R1.7.10 Renewables The service shall forecast the amount of resource produced by renewable sources.
R1.8. Education Format (EDUF)¶
Specifies the following requirements associated with the formats in which education (e.g. awareness raising, training) material needs to be provided in the SMARTSPACES service. Background: Depending on the target group and environment different education formats will lead to different results (e.g. children are more likely to follow interactive formats than read a leaflet).
R1.8.1 Advice - generic The service shall provide generic advice and tips to improve energy related behaviour. R1.8.2 Advice - dependent The service shall provide advice and tips based on the actual consumption (e.g. of the staff member) to improve energy related behaviour. R1.8.3 Advice - project-based The service shall provide advice on potential energy efficiency projects, based on energy consumption and building surveys R1.8.4 Self assessment tool The service shall provide a self-assessment tool that gives a rating about current behaviour and/or position towards energy related issues. Different to quizzes (see below) the data is stored and the assessment can / has to be retaken to reflect the development over time. R1.8.5 Quiz The service shall provide a quiz with energy related questions and the according responses as well as explanations why certain answers are wrong. R1.8.6 Video The service shall provide video material with energy related issues or the service itself. R1.8.7 Social Games The service shall provide a social game with energy related issues or the service itself. R1.8.8 Forum The service shall provide a platform for users to interact exchanging insight in energy-related topics (which might also be moderated by an energy coach). R1.8.9 Chat The service shall provide a chat tool for users to interact with a designated energy coach and / or energy staff such as building managers. R1.8.10 Banners The service shall provide banners with energy related issues or the service itself (e.g. outside of a building). R1.8.11 Poster The service shall provide posters with energy related issues or the service itself. R1.8.12 Pull-up The service shall provide pull-ups with energy related issues or the service itself. R1.8.13 Email The service shall provide emails (e.g. newsletter) with energy related issues or the service itself. R1.8.14 Letter The service shall provide printed letters with energy related issues or the service itself. R1.8.15 Leaflet The service shall provide leaflets with energy related issues or the service itself. R1.8.16 Energy Coach The service shall provide an energy coach that targets staff with high consumption and responds (e.g. person, chat, mail) to staff with energy related questions. R1.8.17 Events-Staff The service shall provide events informing staff users (e.g. all workers in an office block) about the service and / or energy related topics particularly relevant in the context of SMARTSPACES and / or their building and transportation to work. R1.8.18 Events-Kids The service shall provide events informing kids about the service and / or energy related topics particularly relevant in the context of SMARTSPACES and / or their building and transportation (e.g. to school). R1.8.19 Consultation The service shall allow for polls to be conducted e.g. to engage staff in proposed energy savings measures. R1.8.20 QR-Code The service allow for visiting further input by following a QR-Code (or bar code) using a smart phone or other means.
R1.9. Education Topic (EDUT)¶
Specifies the following requirements associated with the degree to which the SMARTSPACES service must be able to send alerts based on the recorded data and settings entered. Background: Depending on the service at the site different topics should be covered with education material (e.g. energy saving sometimes leads to unintended unhealthy ventilation habits).
R1.9.1 Electricity The service shall provide education material to enable the user to reduce electricity consumption. R1.9.2 Electricity-Peak The service shall provide education material to enable the user to reduce electricity-peak consumption. R1.9.3 Heating The service shall provide education material to enable the user to reduce heat consumption. R1.9.4 Cooling The service shall provide education material to enable the user to reduce cooling consumption. R1.9.5 Water The service shall provide education material to enable the user to reduce water (cold & warm) consumption. R1.9.6 Ventilation The service shall provide education material to enable the user to improve ventilation to avoid health risks and reduce related consumption. R1.9.7 Waste The service shall provide education material to enable the user to reduce production of waste. R1.9.8 Transportation The service shall provide education material to enable the user to commute and / or use transportation in a more energy efficient manner.
R1.10. Control Unit (CONU)¶
Specifies the following requirements associated with the degree to which it is possible to control and / or manage the SMARTSPACES service Background: Based on the environment and / or consumption of a given space a schedule / plan needs to be defined for automatic and / or remote management. For instance, in response to an alert that a given space is not occupied but lights have not been turned off (e.g. offices) the professional could send a signal via sms to do so.
R1.10.1 BMS-Access The service needs direct (through the SMARTSPACES environment) and / or indirect (through the BMS system running parallel) access to one or more building (energy) managements systems (BMS) to take control of any resource or setting being part of SMARTSPACES service. R1.10.2 Control - Web-Portal The service shall allow for controlling and / or managing settings via a web-portal either in real-time and / or according to defined schedules / plans for a given space. R1.10.3 Control- MobileApp The service shall allow for controlling and / or managing settings via a mobile application either in real-time and / or according to defined schedules / plans for a given space. R1.10.4 Control - SMS The service shall allow for controlling and / or managing settings via SMS either in real-time and / or according to defined schedules / plans for a given space. R1.10.5 Control - Unit The service shall allow for controlling and / or managing settings via a mounted unit (e.g. attached to wall near office door) either in real-time and / or according to defined schedules / plans for a given space. R1.10.6 Control - Remote The service shall allow for controlling and / or managing settings via a remote either in real-time and / or according to defined schedules / plans for a given space. R1.10.7 Automatic - Occupancy Schedule The service shall automatically determine optimal settings for one or more given control factors and spaces and periods based on the occupancy entered in a schedule. R1.10.8 Automatic - Occupancy Current The service shall automatically determine optimal settings for one or more given control factors and spaces and periods based on the current occupancy of the same or another space (e.g. persons counted entering hall). R1.10.9 Automatic - Heat demand The service shall automatically determine optimal settings for one or more given control factors and spaces and periods based on the past or current heat consumption (e.g. plan for boilers). R1.10.10 Automatic - Movement The service shall automatically determine optimal settings for one or more given control factors and spaces and periods based on the current movement in the same or other space (e.g. street light control). R1.10.11 Automatic - Air quality The service shall automatically determine optimal settings for one or more given control factors and spaces and periods based on the past or current air quality (e.g. ventilation). R1.10.12 Automatic - Weather The service shall automatically determine optimal settings for one or more given control factors and spaces and periods based on the past or current air weather (e.g. cold night, boiler heats up earlier).
R1.11. Control Factor (CONF)¶
Specifies the following requirements associated with the degree to which the SMARTSPACES service must be able to control and manage effectively the system used for the service. Background: Management services (automatic and / or remote) need access to certain devices installed in the building in order to control the environment. However, certain B(E)MS services do not allow bi-directional communication so that some of the following requirements might be difficult to realise. Nevertheless, the following list collects all settings which could be controlled by SMARTSPACES.
R1.11.1 Temperature-Building The service shall allow for controlling the temperature (cooling and heating) of a given building. R1.11.2 Temperature-Floor The service shall allow for controlling the temperature (cooling and heating) on a given floor. R1.11.3 Temperature-Room The service shall allow for controlling the temperature (cooling and heating) in a given room. R1.11.4 Temperature-Zone The service shall allow for controlling the temperature (cooling and heating) in a given zone. R1.11.5 Humidity-Building The service shall allow for controlling the humidity of a given building. R1.11.6 Humidity-Floor The service shall allow for controlling the humidity on a given floor. R1.11.7 Humidity-Room The service shall allow for controlling the humidity in a given room. R1.11.8 Humidity-Zone The service shall allow for controlling the humidity in a given zone. R1.11.9 Ventilation-Building The service shall allow for controlling the distribution of air of a given building (e.g. by operating fans or opening/closing dampers). R1.11.10 Ventilation-Floor The service shall allow for controlling the distribution of air on a given floor (e.g. by operating fans or opening/closing dampers). R1.11.11 Ventilation-Room The service shall allow for controlling the distribution of air in a given room (e.g. by operating fans or opening/closing dampers). R1.11.12 Ventilation-Zone The service shall allow for controlling the distribution of air in a given zone (e.g. by operating fans or opening/closing dampers). R1.11.13 Lighting-Impact The service shall allow for controlling the lightning of any space based on light coming from the sun either based on measurments and/or a sun light calender. R1.11.14 Lightning-Outside The service shall allow for controlling the lighting outside of a given building (this might include park areas or street lamps). R1.11.15 Lighting-Building The service shall allow for controlling the lighting in a given building. R1.11.16 Lighting-Floor The service shall allow for controlling the lighting on a given floor. R1.11.17 Lighting-Room The service shall allow for controlling the lighting in a given room. R1.11.18 Lighting-Zone The service shall allow for controlling the lighting in a given zone. R1.11.19 Fire Systems-Building The service shall allow for controlling the fire systems in a given building. R1.11.20 Fire Systems-Floor The service shall allow for controlling the fire systems on a given floor. R1.11.21 Fire Systems-Room The service shall allow for controlling the fire systems in a given room. R1.11.22 Fire Systems-Zone The service shall allow for controlling the fire systems in a given zone. R1.11.23 Security-Building The service shall allow for controlling the security systems in a given building. R1.11.24 Security-Floor The service shall allow for controlling the security systems on a given floor. R1.11.25 Security-Room The service shall allow for controlling the security systems in a given room. R1.11.26 Security-Zone The service shall allow for controlling the security systems in a given zone. R1.11.27 Computer equipment-Building The service shall allow for controlling computer equipment (including servers) in a givenbuilding. R1.11.28 Computer equipment-Floor The service shall allow for controlling computer equipment (including servers) in a given floor. R1.11.29 Computer equipment-Room The service shall allow for controlling computer equipment (including servers) in a given room. R1.11.30 Computer equipment-Zone The service shall allow for controlling computer equipment (including servers) in a given zone.
R1.12. Peak (PE)¶
Specifies the following requirements associated with the degree to which the SMARTSPACES service must be able to handle peaks in consumption of a given resource. Background: Peak consumption puts restrains on the grid as well as power plants herewith leading to a higher CO2 production and. Reducing peak consumption requires direct control over consuming devices.
R1.12.1 Prevention The service shall prevent forecasted peaks for a given resource by taking actions which would prevent the peak from occurring (e.g. activating fridges, freezers earlier to build up cold and avoid switching on during peak times). R1.12.2 Detection The service shall detect peaks for a given resource as they happen. R1.12.3 Shaving The service shall shave detected peaks for a given resource by taking actions to reduce the peak (e.g. turning off devices).
R1.13. Renewables (RE)¶
Specifies the following requirements associated with the degree to which the SMARTSPACES service shall record and / or manage renewable resources. Background: As renewable sources are not as predictable as traditional energy sources and are often local they need management and / or appropriate maintenance.
R1.13.1 Use of renewables The service shall be able to inform a user how much resources are produced by renewables and / or when user should ideally consume resources in order to guide consumption toward use of renewables. R1.13.2 Solar-Electricity The service shall record and / or manage the electricity produced by solar plants. R1.13.3 Solar-Heat The service shall record and / or manage the heat produced by solar plants. R1.13.4 Wind The service shall record and / or manage the electricity produced by wind. R1.13.5 DCH The service shall record and / or manage the heat available and / or consumed in a district heating grid. R1.13.6 CHP The service shall record and / or manage the heat and electricity available and / or consumed in a Combined Heat and Power (CHP) unit. R1.13.7 Tri-Generation The service shall record and / or manage the heat, cold and electricity available and / or consumed in a Tri-generation unit. R1.13.8 Hydropower The service shall record and / or manage the electricity produced by hydropower. R1.13.9 Biofuel The service shall record and / or manage the electricity produced by biofuels.
R1.14. Building Administration (BA)¶
Specifies the following requirements associated with the degree to which the SMARTSPACES service shall allow for administering buildings. Background:
R1.14.1 Building Data The service shall enable the user to configure or modify all the data related to Building Auditing (see Section R1.16) R1.14.2 Hardware administration The service shall enable the user to manage/configure and associate all different hardware used to give the SMARTSPACES service in each building R1.14.3 Meters administration The service shall manage/configure the technical parameters of the meters. Also will allow each meter to be associated with the whole building or in a particular zone of the building. R1.14.4 Alerts The service shall enable the user to configure or modify all the data related to Alerts (see section R1.6) R1.14.5 Documentation The service shall enable the user to manage and share documents files in the system R1.14.6 Comments The service shall enable the user to manage and share some comments. These comments will be used to communication between the users inside the system . R1.14.7 Periodic Reports The service shall enable the user to configure the reports format and their periodical generation . R1.14.8 Dashboard configuration The service shall enable the user to configure their personal dashboard
R1.15. Portal Administration (PA)¶
Specifies the following requirements associated with the degree to which the SMARTSPACES service shall allow for administering the portal (e.g. web-site) by professionals or the service provider. Background:
R1.15.1 Buildings The service shall be able to create/modify /erase buildings in the system R1.15.2 Zones The service shall be able to create/modify /erase zones in the buildings R1.15.3 Municipalities The service shall be able to create/modify /erase municipalities in the system R1.15.4 Country The service shall be able to create/modify /erase countries in the system R1.15.5 Users The service shall ebe able to create new access user for each building . Is necessary to give different access levels for each different users. R1.15.6 Dashboard configuration The service shall enable the user to configure different dashboards for different buildings and users. R1.15.7 Documentation The service shall enable the user to manage and share documents files in the system for different buildings and users. R1.15.8 Reports The service shall enable the user to configure the general reports format and the periodical generation of these ones.
R1.16. Building Auditing (BAU)¶
Specifies the following requirements associated with the degree to which the SMARTSPACES service shall allow for administering the portal (e.g. web-site) by professionals or the service provider. Background:
R1.16.1 General information The service shall be able to collect general building information. For example: Name of building, address, contact, typology, etc.. R1.16.2 Areas The service shall be able to include the square meters area for buildings or zones R1.16.3 Nominal heating power The service shall be able to include the nominal heating power for buldings or zones R1.16.4 Nominal cooling power The service shall be able to include the nominal cooling power for buildings or zones R1.16.5 Nominal lighting power The service shall be able to include the nominal lighting power for buildings or zones R1.16.6 People occupancy The service shall be able to include the people occupancy for buildings or zones R1.16.7 Meteorological data The service shall be able to include the meteorological data for each building and to configure the energy calculation with these parameters (used in benchmark) .
Non-functional¶
Non-functional requirements capture properties of a system. These requirements address ‘hidden areas’ of the system that are important to the users even though they might not realise it.
This category is referenced with the capital “NF” or “2”.
R2.2. Auditability (AUD)¶
Specifies the following requirements associated with the degree to which the SMARTSPACES service must support independent auditing of its transactions and finances. Background: A service might also be used to directly be used for billing or other financial transactions. In such a case certain standards have to be met.
R2.2.1 Billing-Validity The service shall ensure that generated output can be used for billing services. R2.2.2 Billing-Creation The service shall generate bills that shall also be used for tax purposes (e.g. VAT). R2.2.3 Billing-FollowUp The service shall follow the status of a bill and whether it has been paid (correctly). R2.2.4 Audit-Report The service shall store all records for at least a year.
R2.3. Configurability (CNF)¶
Specifies the following requirements associated with the degree to which the SMARTSPACES service must exist in multiple simultaneous configurations or variants.
R2.3.1 Internalisation - System The service shall allow for multi language programming. R2.3.2 Internalisation - User The service shall allow for changing the language to the preferred by the user. R2.3.3 Personalisation - User User shall be able to set preferences (e.g. language) which are stored with the user account and / or as cookies.
R2.4. Extensibility (EXT)¶
Specifies the following requirements associated with the degree to which the SMARTSPACES service can be modified to meet changing requirements or goals. Background: Eventually the original set-up will or has to be extended in the future.
R2.4.1 Resource The service shall allow for adding further resource types to the system. R2.4.2 Data Source The service shall allow for adding further data sources to the system. R2.4.3 Building The service shall allow for adding further buildings to the system. R2.4.4 Floor The service shall allow for adding further floors to the system. R2.4.5 Room The service shall allow for adding further rooms to the system. R2.4.6 Zone The service shall allow for adding further zones to the system. R2.4.7 Users-Admin The service shall allow for adding further admin-users to the system. R2.4.8 Users-Staff The service shall allow for adding further staff-users to the system. R2.4.9 Preferences The service shall allow for adding further preference settings to the system.
R2.5. Scalability (SCAL)¶
Specifies the following requirements associated with the degree to which the SMARTSPACES service can be scaled up. Background: Eventually the original service will be scaled up to other sites or environments.
R2.5.1 Functional The service shall be able to allow for new functionality in one or more parts of the service. R2.5.2 Reproduction The service shall be able to be reproduced in a similar setting in form of a new instance (e.g. another municipality). R2.5.3 Extension See R2.4 Extensibility. R2.5.4 Completeness The service shall, by design, be able to cover all public buildings in the municipality of the pilot.
R2.6. Interoperability (IOP)¶
Specifies the following requirements associated with the ease with which the SMARTSPACES service can be integrated with other system (e.g., browsers, legacy applications, and required databases). Background: Web-portals are usually displayed in environments of third parties (e.g. browsers). Depending on the functionality and restrictions of the service and / or the third-party programme the service might not be fully compatible.
R2.6.1 Browser - Chrome10 & above The service shall support the listed browser. R2.6.2 Browser - FireFox4 & above The service shall support the listed browser. R2.6.3 Browser - IE6 The service shall support the listed browser. R2.6.4 Browser - IE7 &above The service shall support the listed browser. R2.6.5 Browser - Opera10 & above The service shall support the listed browser. R2.6.6 Browser - Safari4 & above The service shall support the listed browser. R2.6.7 App - Android The service shall support the listed mobile app platform. R2.6.8 App - iOS The service shall support the listed mobile app platform. R2.6.9 App - Win7 The service shall support the listed mobile app platform.
R2.7. Performance (PER)¶
Specifies the following requirements concerning the minimum number of objects that the SMARTSPACES service can support; time that is permitted for The service to execute specific tasks or to respond. Background: Users could be hindered to use the service due to limitations of the service. Reliable figures need to be identified in order to allow proper service for all users.
R2.7.1 Capacity-Users The service shall support a sufficient number of simultaneous users accessing the service. R2.7.2 Capacity-Data (any) The service shall support a sufficient number of data entries of any kind without loss of data and without restrictions to any user type. R2.7.3 Latency The service’s entry masks and functionalities shall lead to the expected result (e.g. registration, settings for certain graph) without obstructing and hindering the use of the service. R2.7.4 Response Time The service shall be usable without delay (e.g. loading of website) obstructing and hindering the use of the service.
R2.8. Reliability (REL)¶
This subsection specifies the following requirements associated with the reliability (e.g. mean time between failures, number of failures per unit time) of the system.
R2.8.1 Failure - 1 year The mean time between failures (MTBF) shall exceed 12 months. R2.8.2 Failure - 1 quarter The mean time between failures (MTBF) shall exceed 3 months. R2.8.3 Failure - 1 month The mean time between failures (MTBF) shall exceed 1 month. R2.8.4 Failure - 1 week The mean time between failures (MTBF) shall exceed 1 week.
Todo
include remaining categories