TEMPLATE & GUIDELINE
Stakeholder Requirements Document / Ref: / version:0.01 / date: xx/xx/20xx / page 1 / 19
STAKEHOLDER REQUIREMENTs DOCUMENT
TEMPLATE & Guidelines
This document has to be reformatted to comply with Company documentation standards
Reference: xxxxxxxx
Version: 0.01
This document is the property of Company-name.
LOGO / Stakeholder Requirements DocumentTEMPLATE & GUIDELINE
Stakeholder Requirements Document / Ref: / version:0.01 / date: xx/xx/20xx / page 1 / 19
LOG
Version / Date / Modifications
0.01 / xx/xx/20xx / Creation of the document
Preliminary
This document is a form to use and fill in order to produce the document related to a specific system in the scope of a development project.
The "Stakeholder Requirements Document" (StkRD) presents the outcomes generated by the performance of the Stakeholder Needs and Requirements Definition Process.
Recommendation for the presentation of Stakeholder Requirements
Use preferably tables such as:
Id. / Stakeholder Requirement / Comment / Stakeholder source / Flexibility / PrioritySY.xx / Text / Text
Where:
· Id. is the identifier:
¨ 1st letter = S for Stakeholder Requirement
¨ 2nd letter for type; examples:
§ (S) Service, (I) Interface, (D) Dependability, (H) Human factors, (P) Performance, (R) Resource, (C) Constraint, …
¨ xx = chronological number in the type
· Stakeholder Requirement: this is the text defining the stakeholder requirement
· Comment: provide additional explanations
· Stakeholder source: the origin of the requirement – who expressed it.
· Flexibility level; examples:
¨ Mandatory = M
¨ Strongly wish = S
¨ Normal = N
¨ Optional = O
· Priority; examples: 1, 2, 3 (inform the developer about the priority of implementation)
CONTENT
1 Introduction 5
1.1 Presentation of the document 5
1.2 Documents 5
1.2.1 Reference documents 5
1.2.2 Applicable documents 5
1.3 Terminology: definitions and abbreviations 6
2 Presentation of the system 7
2.1 Intended use of the system 7
2.2 Stakeholders 7
2.3 Context of use of the system 7
2.3.1 Overview of the context and relationships 7
2.3.2 Functional architecture of the context 8
2.3.3 Physical architecture of the context 8
3 Stakeholder requirements 9
3.1 Operational Modes and Operational Scenarios 9
3.1.1 Operational Modes 9
3.1.2 Operational Scenarios 9
3.2 Expected Services 9
3.3 Expected effectiveness or performances 10
3.4 Interfaces 10
3.4.1 Functional interfaces 10
3.4.2 Physical interfaces 10
3.5 Operational Conditions 11
3.5.1 Dependability and robustness 11
3.5.2 Environmental conditions 14
3.5.3 Resources or used means and produced means 14
3.5.4 Maintenance or Logistic Support 14
3.5.5 Ergonomics and Human Factors 15
3.5.6 Transportation and Storage 15
3.5.7 Documentation 15
3.6 Constraints 16
3.6.1 Physical constraints 16
3.6.2 Implementation constraints 16
3.6.3 Extension constraints 16
3.6.4 Transfer for use constraints 17
3.6.5 Disposal constraints 17
3.6.6 Constraint of cost and delivery of the product/service 17
3.6.7 Manufacturing constraints 18
3.6.8 Regulation constraints 18
3.6.9 Standardisation constraints 18
3.7 Validation requirements 19
FIGURES and Tables
1 Introduction
1.1 Presentation of the document
Present here briefly the content of the document and the system XX.
Typical introduction could be: The Stakeholder Requirements Document presents the requirements expressed by every concerned stakeholder and applicable to the system XX.
Etc.
1.2 Documents
The documents referred here shall be defined precisely: complete title, reference and version.
They have to be placed at the disposal of the readers, either directly in annexes, or by the means of an appropriate documentation management.
1.2.1 Reference documents
Provide the list of documents having been used writing this document: expression of needs and expectations from the customers and other stakeholders, System Design Document - SysDD of the upper-system level, reports, minutes of meeting, etc.
Reference / Document Title /1.2.2 Applicable documents
Provide the list of documents entirely or partially applicable: standards, templates, descriptions of procedure, others.
Reference / Document Title /1.3 Terminology: definitions and abbreviations
Provide the list of terms and their definition used in this document absent from the usual dictionaries or used with a different significance from their usual significance.
Each definition can be supplemented by the abbreviation used in the document.
Term / Definition /2 Presentation of the system
2.1 Intended use of the system
This section indicates the purpose, the intended use (or mission) and the main objectives of the system:
· Purpose: Why does the system exist? What is the usage and relevance of the system in its context of use?
· Intended use (mission): What it does? Which transformation does it perform to achieve its purpose?
· Objectives: Which are the main performances (quantified) that the system must satisfy so that the purpose is achieved? How many inputs does it transform? How speed?
There is one purpose and one global mission for a given system. On the other hand there may be several objectives.
High-level description of these objectives could be supplemented with details in section 3.3.
2.2 Stakeholders
List the stakeholders.
The stakeholders are the various parties who have or will have a relationship to the system, throughout its life cycle.
All the states or stages of the system life must be analyzed to identify the whole of the stakeholders: design, tests, manufacturing, transfer for use, transportation, operation, aggression, maintenance, modifications, disposal, etc.
This list makes possible to establish the source of the needs, expectations and requirements with the aim of traceability.
2.3 Context of use of the system
2.3.1 Overview of the context and relationships
This section locates the concerned system in its context of use.
It identifies specifically:
· the upper-system (context) with its functions and its system elements (components)
· the enabling systems which have a relation with the concerned system
It is recommended to present the context of use in the form of diagrams of context, or entity/relationships diagrams that show the system elements (components) of the context and the relationships between these components and the system-of-interest or the concerned system.
2.3.2 Functional architecture of the context
This section indicates the main function of every component of the context and the main input-output flows exchanged between the components of the context and the system of interest or of the concerned system.
It is recommended to present the functional architecture of the context in the form of diagrams that show clearly functions / activities and input-output flows / object nodes.
2.3.3 Physical architecture of the context
This section indicates the physical system elements (components) of the context and the main physical interfaces (links/connectors) that connect the components of the context to the system of interest or the concerned system. The input-output flows are normally carried by the physical interfaces (links / connectors).
It is recommended to present the physical architecture of the context in the form of diagrams that show clearly the physical system elements (components or blocks) and the physical interfaces (links / connectors).
The physical system elements / components / blocks of the context can be described in this section as necessary. The description of the interfaces is located in the section "Interfaces".
Id. / Component/block of the context / Description /3 Stakeholder requirements
3.1 Operational Modes and Operational Scenarios
This document provides the view of the customer, the end users and other stakeholders. Do not introduce at this step the particular modes or states resulting from the system architecture. Here, the system is seen as a black box that reacts to the requests of the users or of the components of the context of use.
3.1.1 Operational Modes
Define each Operational Mode (on/off, standby, run, maintenance, etc.) and describe what the system is expected to do in each mode, what are the trigger events that initiate the transition from one mode to another. Use state-transition diagram, state-machine diagram, etc., for highlighting the transitions.
An Operational Mode contains one or more Operational Scenarios.
Id. / Operational Mode / Comment / Scenarios /3.1.2 Operational Scenarios
Describe each Operational Scenario (sequence, concurrence of actions) of the system and the exchanges with the components of the context, including the actions of the users. Use diagrams, easily accessible to non-specialists, such as eFFBD, simplified activity diagram of SysML, etc.
- Operational Scenario 1: TBD
3.2 Expected Services
The expected services are the main operational activities or highest level of functions that the system of interest has to achieve. The services are extracted from the Operational Scenarios described in section 3.1.2 and/or deduced from the context diagrams (section 2.3.1).
Id. / Stakeholder Requirement / Comment / Stakeholder source /3.3 Expected effectiveness or performances
Describe the measures of effectiveness (performances) expected by the system to satisfy the expected service. These data are quantified, as much as possible, or at least qualitative. They are the result of the analysis of Operational Scenarios and not from feedback of a selected architectural solution of the system.
Id. / Stakeholder Requirement / Comment / Stakeholder source /3.4 Interfaces
3.4.1 Functional interfaces
Describe the functional interfaces (input-output flows) between the system and the components of its context of use.
Note: The man-machine interfaces are described in the section concerning ergonomics.
Id. / Stakeholder Requirement / Comment / Stakeholder source /3.4.2 Physical interfaces
Describe the physical interfaces that connect the system to the components of its context of use.
These physical interfaces may be: electrical cables, connectors, pipes, data format, protocols, procedures, etc.
Id. / Stakeholder Requirement / Comment / Stakeholder source /3.5 Operational Conditions
3.5.1 Dependability and robustness
The dependability of a system is the property that makes possible to its users to place a justified confidence in the service that it returns to them.
3.5.1.1 Safety
Safety is the aptitude of the system to avoid that failures appear involving damage for people or materials. Safetyrelates to the protection of the system and its users (not only end user but all the public susceptible to be in contact with the system during all its life).
Functional safety relates to the integrity of operations and performances of the system even in case of failure.
Id. / Stakeholder Requirement / Comment / Stakeholder source /3.5.1.2 Availability
Availability is the ability of the system to achieve, without failure, a requested function at any time, under given environmental, maintenance and usage conditions.
The availability can be characterized by the percentage of time of right operation; in other terms the ratio of the average time of availability, on the sum of the average time of availability, plus the average time of unavailability.
Id. / Stakeholder Requirement / Comment / Stakeholder source /3.5.1.3 Survivability
Survivability is the aptitude of the system to achieve its mission including occurrence of internal failures, external threats or evolutions of its environment, taking into account the expected degraded states.
Id. / Stakeholder Requirement / Comment / Stakeholder source /3.5.1.4 Reliability
Reliability is the ability of the system to achieve a requested function, without failure, during a given period of time, under given environmental and usage conditions.
Note: A priori only safety, availability and survivability are in the domain of the stakeholder requirements. Reliability and maintainability are in the domain of System Requirements. Testability is in the design of the solution domain. But this depends on the level of system one deals with. If the system is not repairable, reliability replaces availability.
Id. / Stakeholder Requirement / Comment / Stakeholder source /3.5.1.5 Maintainability
Maintainability is the ability of the system for being maintained (preventive maintenance) or to be restored (curative or corrective maintenance) in normal operational mode/state under given environmental and usage conditions, applying the prescribed maintenance conditions.
Maintainability covers not only the necessary effort to repair or correct a component, but also to locate and identify its failed components.
The needs for maintainability define the objectives to be reached out concerning maintenance; for example: downtime for preventive maintenance actions, speed of repairing, etc. The objectives of maintainability are deduced from the operational and maintenance scenarios analysis.
Id. / Stakeholder Requirement / Comment / Stakeholder source /3.5.1.6 Information availability
The information availability is the aptitude of the system to prevent a denial of access to a resource or information.
Id. / Stakeholder Requirement / Comment / Stakeholder source /3.5.1.7 Information integrity
The information integrity concerns preventive actions against non-authorized modification of the information. It guarantees that the system and the information are modified only by intentional and legitimate actions. When information is exchanged, integrity includes authentication, that is to say guarantee of the origin and the addressee.
Id. / Stakeholder Requirement / Comment / Stakeholder source /3.5.1.8 Information Confidentiality
The information confidentiality concerns preventive actions against non-authorized disclosure of information. It corresponds to the reserved characteristic of information which access is limited to persons authorized to know it for service purposes.
Id. / Stakeholder Requirement / Comment / Stakeholder source /3.5.2 Environmental conditions
Describe the physical environmental conditions to which the system is submitted. Non exhaustive examples: climate, temperature, light exposition, pressure (altitude), humidity, vibrations, shocks, radioactive materials, electromagnetic environment, acoustic noise, telecommunication equipment interference, biological contamination from and to the environment, expected countries of commercialization, geographic environment, etc.
Id. / Stakeholder Requirement / Comment / Stakeholder source /3.5.3 Resources or used means and produced means
Resources or used means are consumed or produced elements by the system, which do not belong to the system. It is possible to define here the requested autonomy, the expected maximum of consumption or rejections, etc.
Id. / Stakeholder Requirement / Comment / Stakeholder source /3.5.4 Maintenance or Logistic Support
These requirements concern conditions of maintenance and logistics, duration of maintenance actions, management of spare parts, availability of maintenance equipment, qualification of the maintenance team, possibility or not for having specific tools, marking, identification, etc.