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 use case describes one particular scenario in which the user interacts with the system. A use case is described with a summary and the flow of events. Any precautions taken to respond to mistakes by either the system or the user which do not resemble the base flow of events will be described as well. Each use case has a unique ID and name. Each use case matches exactly one process model.
Use cases and process models were developed in parallel: Input gathered from process models was implemented in the use cases and vice versa. Either presents the full complexity of the scenario across all pilot sites implementing this particular scenario. Hence, certain sites might not cover all steps or implement the flow slightly differently.
Your system does not have to implement the entire complexity to deploy a certain feature. Some steps cover specialised elements and can be “cut out” or come with an “upgrade” later.
The Guide offers a comprehensive list of 49 Use Cases (with Process Models and Requirements) collected from 28 pilot sites traceable by an ID.
The primary goal of Process Models is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor these processes. Thus, BPMN creates a standardised bridge for the gap between the business process design and process implementation.
The technical documentation for the projects SMARTSPACES, BECA and eSESH uses one common framework to describe requirements, use cases etc. Herby the Guide achieves to summarise similarities of systems for residential and non-residential buildings.