A requirement is any technical, organisational or user specific request. Requirements are collected using workshops and questionnaires and should be collected from all user groups as they might have different needs. Requirements are prioritised to identify critical and to organise work. Later in the process, the system can be compared against the list of highly prioritised requirements and if all are covered the tester can be confident that (at least from this view point) the system is fully functional.
The Guide offers a comprehensive list of almost 500 requirements collected from 28 pilot sites traceable by an ID. The necessary set is listed with each Use Case and Process Model so replicating stakeholders know what to look out for.
Each requirement is traceable and numbering is consistent across pilots from SMARTSPACES. Using three digits the notation refers to requirement category, logical group and individual requirement (e.g. R1.2.3 = a functional requirement in visualisation-data group).
Five categories have been identified, namely functional, non-functional, data, conversion units, legal and regulatory requirements and are described in some detail on the fact sheet on the next page.
Requirements are documented with an ID, name, summary and individual priorities for each pilot site. Pilot sites have collected these priorities in focus groups of professional users (e.g. energy managers), staff members (e.g. regular office worker) and visitors (e.g. student) using a sophisticated and flexible Excel tool allowing for traceability of individual requirements to one or more Use Cases (contact firstname.lastname@example.org).
Documentation has been made following the indications of different norms related on definition of the SOAS (Software as a Service) for team and enterprises such as EEE 1471-2000™ Conceptual Framework for Architectural Description and ISO/IEC/IEEE 42010 System and software – Architecture description.
Requirements are divided into five categories:
Categories are further divided into groups collecting related requirements.
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.
To the full list of all Functional requirements.
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.
To the full list of all Non-functional requirements.
Data requirements provide a detailed description of the data model that the system must use to fulfill its functional requirements. Users and developers work jointly in defining the domain data model.
To the full list of all Data requirements.
To the full list of all 500-rcu requirements.
To the full list of all Legal and Regulatory requirements.
List of all Requirements.