1. TECHNICAL REQUIREMENTS DEFINITION PROCESS
SYSTEMS ENGINEERING
SYSTEMS ENGINEERING
TECHNICAL REQUIREMENTS DEFINITION PROCESS
Hervé Panetto, Professor
University of Lorraine, TELECOM Nancy
Research Centre for Automatic Control (CRAN UMR 7039 CNRS)
Chair of IFAC CC 5 « Manufacturing and Logistics Systems »
SYSTEMS ENGINEERING COURSE
Based on slides from Alain Faisandier (MAP Systems)

2. Copyright
This work is licensed under Creative Commons Attribution- NonCommercial-ShareAlike 3.0 available online at

3. TECHNICAL REQUIREMENTS DEFINITION PROCESS8
TECHNICAL REQUIREMENTS CLASSIFICATION
8 - TECHNICAL REQUIREMENTS CLASSIFICATION

4. The classification of requirements
Requirements represent simple ideas. In order to prepare the design work, it is necessary to indicate the notion represented by each requirement.
Interface
requirement
Measure of
effectiveness
Functional
requirement
Constraint
other Operational
requirement
Operational
requirement
(Scenario & mode)
Validation requirement
Attention : the types are defined a priori, by processes

5. Usefulness of the requirements classification for design
For the designer, the classification of the requirements makes it possible to identify the nature of work to be carried out.
Reading the requirements baseline allows to:
Identify the situations of life to be taken into account and the corresponding operational conditions
Identify the limits applicable to physical architectures and to components
Know the various transformations to be operated on energy, materials and information
Participate to exchanges between various sets
Take into account the various elements of validation which have an impact on architectures
Define the field of application of these transformations

6. Usefulness of the requirements classification for justification
The requirements describe one vision of the problem placed under the responsibility of the author and communicated to the designers.
The solution must refer exclusively to the requirements.
The designers have to justify that :
Every situation of life are detected and the operational conditions are taken into account
The physical architectures and the components respect the imposed limits
All the expected transformations are carried out
All contributions to interfaces are taken into account
The transformations are effective in the expected fields of application
The situations of validation are taken into account

7. Operational requirements
The scenarios and operating modes describe the expected behaviour of the system in its various situations of life.
Operational
Requirement
(Scenario & Mode)
To find the operational situations, imagine all the situations to which the future product or service will have to face :
Normal usage – disposal - maintenance – altered mode – fire – usage during daylight – usage during dark – usage by unforeseen operators ... Processed in a wash machine …

8. Functional requirements
The functional requirements describe the transformation, storage or carrying of energy, materials and information.
The functional requirements are expressed with verbs of action.
Functional
requirement
The functions express treatments whose execution will be allocated to mechanical means, software, human role, organisation, etc.
To be exhaustive, the functional
requirements specify:
The inputs,
The outputs,
The triggers,
The functions workflow.
About method APTE and "Value Analysis" techniques :
The APTE method was developed within the framework of the Value Analysis. Its technique known as "functional analysis" is used to establish an inventory of services and constraints related to a product. The goal is to calculate the costs engaged by the means implemented concerning a set of services or a set of constraint, and to make economic viability and opportunity studies.
If these methods and techniques are very advisable to carry out opportunity studies and economic viability, it is not appropriate for the logical design.
Note : Do not confuse characteristics, constraints and functions.
« To be mobile  » is a characteristic of a product, but not a function of a system.
« To resist to anything» is a constraint, but not a function.
Functions as seen by the software specialists :
In Systems Engineering, the description of functions is a primary importance. The verb used indicates the treatment to be carried out and remains the principal element of the requirement of the function.
In the software the verbs which express the treatments are, in proportion, very few (generally : calculate a value, light an indicator, read a signal, decode, etc.) The attention of the designers goes more on the data which become the elements which specify the function. Such an attitude is right in software engineering and wrong in Systems Engineering.
If you use specific terms, use glossaries

9. Expected effectiveness
The measure of effectiveness quantify the field of application and the objectives to be reached by the functions.
Expected effectiveness
Solution B
Solution A
Solution C
P1 P2 P3 P4
A design process must be able to establish several technological solutions, according to several functional and physical architectures.
The measures of effectiveness are used to carry out the selection between these various solutions.

10. How to express measure of effectiveness ?
(the quantified expected effectiveness)
For a static measure of effectiveness, define :
the object concerned with the measure (function, component, input, output, ...),
the values (mini, maxi, average, … and margin),
the units,
the intervals or delineating events (which trigger or stop the necessity to keep the performance),
the context (significant to work out the tests of effectiveness),
the probability (% of cases for which the measure has to be reached).
For a dynamic measure of effectiveness, add :
the execution time values (mini, maxi, average, …),
the consumption of means/inputs (mini, maxi, average, …).
Example :
For each computer, the set of processes shall not use more than 50% of
the CPU in nominal mode and 70% in peak mode.

11. Constraints
Constraints are requirements which apply directly to the physical architectures and components.
They are often characterised by dimensions, re-use of components, imposed solutions …
Constraint
The constraints come "from upstream", such as for example
a geometry or an imposed technology.
The constraints can possibly come "from downstream"
due to design choices.
Constraints can also come from non technical choices
such as make-or-buy strategy, project management decisions, etc.

12. Operational requirements (1)
Ergonomics - human factors :
Easiness of use of the expected product (dimensions, weight, protection against the human errors, man - machine interactions, man to man communication ...) – biomechanical ergonomics and cognitive ergonomics …
Training of users
User's documentation ; user's manual (procedures of operation, syntax and semantics of commands, display screen, contents of error messages, user support …)

13. Operational requirements (2)
Dependability
These requirements cover :
reliability : capability to obtain a correct operation in time,
maintainability : ability to be repaired, modified,
availability of the service when necessary,
safety of people and goods : consists in reducing the potential of damage which can occur following a failure.
These requirements apply to technologies involved in the system (mechanics, electronics, …, software, humans).
They are defined according to the following approach :
Identify the risks associated with the functions compared to the mission (undesired events),
Determine critical classes of functions,
Define suitable provisions to mitigate the risks.

14. Operational requirements (3)
Logistics - environment - means :
Packing, moving, handling, storage
Maintenance constraints : periodicity, duration, specific tools ...
Behaviour with the environment such as climatic, electromagnetism and with the various aggressions to be met during the product life ...
Restrictions of physical means / resources

15. Interfaces requirements (1)
The interface requirements describe the functional AND physical interactions between systems.
An interface is logical and physical.
The logical part are interactions between functions.
The physical part is supported by physical "links" binding sets of components.
The interfaces requirements describe the contribution of one element to the implementation of an interface function.
The interfaces are not only technologies for energy, materials or information to carry.

16. Interface requirements (2)
The interface requirements define the relationships with the elements outside of the perimeter of the system ; ie the means to connect, interact or communicate these outside elements with the system.
They are classified according their technological types :
Functional (inputs, outputs, triggers)
Physical (mechanical, electronics, electrical, magnetism, chemical, …)
Human (operator protocols)
Software (protocols, formats)
For functional interfaces :
reception of inputs,
sending of outputs,
transportation of flows
For physical interfaces :
connection to the system ;
connection to outside ;
transportation of flows between inside and outside

17. Validation requirements
These requirements are used by the designer to know the situations to be met during validation testing.
Validation requirement
These requirements can be used to specify :
The final validation scenarios
The phenomena that must be observed during validation testing (vibrations, temperatures, inflections, computer memory occupation, speed cycle…),
conditions and kind of test (sampling for destructive control, x-rays control, etc.),
constraints on measurement points, volumes, calibration, margins ...
Generally the validation requirements are placed in the Integration and Validation Plans.

18. TECHNICAL REQUIREMENTS DEFINITION PROCESS11
TEMPLATE OF A TECHNICAL REQUIREMENTS DOCUMENT
11 - TEMPLATE OF A TECHNICAL REQUIREMENTS DOCUMENT

19. System Requirements Document template (1)
Introduction (Object, applicable and reference documents, terminology, …)
Presentation of the System
Purpose, mission and objectives of the system
Physical context of the system (boundaries)
Functional context of the system
Stakeholders list
Technical requirements
Functional requirements
Measures of effectiveness (performance efficiency)
Interface requirements
Functional interfaces (exchange of flows)
Physical interfaces (physical connections)
Operational requirements
Operating modes and operational scenarios
Ergonomics and human factors
Dependability requirements (reliability, availability, maintainability, safety)
Environment requirements
. . .

20. System Requirements Document template (2)
(continued)
Used means requirements (quantity of inputs)
Produced means requirement (quantity of outputs)
Maintenance requirements
Transportation and storage requirements
User documentation requirements
Constraints
Physical constraints
Design and implementation constraints (imposed means, re-use)
Constraints for reservation and future evolution
Constraints for installation
Constraints for disposal
Products cost and deadline constraints
Other Quality constraints
Standardisation and regulation constraints
Final Validation, Certification requirements

21. TECHNICAL REQUIREMENTS DEFINITION PROCESS
SYSTEMS ENGINEERING
SYSTEMS ENGINEERING
TECHNICAL REQUIREMENTS DEFINITION PROCESS
Hervé Panetto, Professor
University of Lorraine, TELECOM Nancy
Research Centre for Automatic Control (CRAN UMR 7039 CNRS)
Chair of IFAC CC 5 « Manufacturing and Logistics Systems »
SYSTEMS ENGINEERING COURSE
Based on slides from Alain Faisandier (MAP Systems)