SYSTEMS ENGINEERING TECHNICAL REQUIREMENTS DEFINITION PROCESS Herv Panetto

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 » Herve. Panetto@univ-Lorraine. fr Based on slides from Alain Faisandier (MAP Systems)

Copyright This work is licensed under Creative Commons Attribution. Non. Commercial-Share. Alike 3. 0 available online at http: //creativecommons. org/licenses/by-nc-sa/3. 0/

TECHNICAL REQUIREMENTS DEFINITION PROCESS TECHNICAL REQUIREMENTS CLASSIFICATION

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. Functional requirement Operational requirement (Scenario & mode) Measure of effectiveness Constraint other Operational requirement Interface requirement Validation requirement Attention : the types are defined a priori, by processes

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 Define the field of application of these transformations Take into account the various elements of validation which have an impact on architectures

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

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 …

Functional requirements The functional requirements describe the transformation, storage or carrying of energy, materials and information. Functional requirement The functional requirements are expressed with verbs of action. 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. If you use specific terms, use glossaries

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 P 1 P 2 P 3 P 4 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.

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, …).

Constraints are requirements which apply directly to the physical architectures and components. Constraint They are often characterised by dimensions, re -use of components, imposed solutions … 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.

Operational requirements (1) Operational requirement 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 …)

Operational requirements (2) Operational requirement 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.

Operational requirements (3) Operational requirement 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

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

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

Validation requirements Validation requirement These requirements are used by the designer to know the situations to be met during validation testing. 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. . .

TECHNICAL REQUIREMENTS DEFINITION PROCESS TEMPLATE OF A TECHNICAL REQUIREMENTS DOCUMENT

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 . . .

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

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 » Herve. Panetto@univ-Lorraine. fr Based on slides from Alain Faisandier (MAP Systems)