1 / 32

Systems Thinking and Systems Engineering

Systems Thinking and Systems Engineering. Systems Engineering: Requirements model 07 February 2013 François Christophe Galina Medyna Eric Coatanéa. Objectives of the lecture. Know different types of representations for requirements Understand the importance of modeling requirements

morgan
Download Presentation

Systems Thinking and Systems Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Systems Thinking and Systems Engineering Systems Engineering: Requirements model 07 February 2013 François Christophe Galina Medyna Eric Coatanéa

  2. Objectives of the lecture Know different types of representations for requirements Understand the importance of modeling requirements Apply techniques for refining requirements

  3. Definition of requirement structure

  4. Structure of requirement A requirement is: 1- Identified: Qualitatively defined, this is a need, 2- Specified: Quantitatively defined, this is a specified requirement, 3- Allocated: Assigned to a product, process, subsystem or a combination, 4- Covered: Satisfied by the element to which it has been allocated

  5. Structure of requirement

  6. Structure of requirement

  7. Types of representations of requirements

  8. Representation types Document Classification of requirements under categories List of requirements Tree of Requirements Detailed requirements with performance values

  9. Requirements document http://www.c-jump.com/CIS75/Week06/samples/requirements.html http://www.swisseurobot.ch/images/2012/e2012_rules_en_final.pdf

  10. Classification of requirements

  11. Classification of requirements User requirements Technical requirements Adapted from: Hull, E., Jackson, K., Dick, Jeremy., 2005, Requirement Engineering, 2nd ed., Springer, London.

  12. Classification of requirements Business requirements: • High level requirements related to company organisation User (stakeholder) requirements • Requirements related to user wishes or needs from a project Functional requirements • Functionalities required from a system derived from analysis of user requirements Non-functional requirements • Requirements related to constraints such as cost, performance, dimension, maintenance...

  13. List of requirements

  14. Treeof requirements

  15. Detailed requirements

  16. Detailed requirements

  17. Detailed requirements A detailed requirement should be quantitatively defined (specified) • Can be defined with its utility

  18. Detailed requirements:Trade-offs between requirements Example: • Power source should provide enough energy for playing 2 matches consecutively: (2*90s.) BUT • Constraints for the robot dimensions

  19. Allocated requirements Requirements should be allocated to specific parts of the system Examples of allocation:

  20. Why is it important to model requirements?

  21. Model of requirements? Why? Siemens PLM requirements Dassault RFLP Providia IBM Rational Doors Why so many vendors give importance to requirement modeling?

  22. Because... Requirements descriptions are similar to a contract between customers and suppliers It is important to capture the interactions and possible contradictions between requirements (contradictions can lead to design constraints) It is important to keep track of initial objectives • Allocation and satisfaction mechanisms used for traceability

  23. Refinement techniques

  24. Functional or non-functional? Analysis of types of verbs and objects used in requirements sentences Helps classifying requirements into different categories

  25. Functional or non-functional? A requirement is a sentence in natural language. A function is always related to transitiveand intransitive verbs. Examples: The seat must prevent injury (seat=subject, prevent= transitive verb, injury=object) The airplane seat must float. (seat =subject, float =intransitive verb)

  26. Functional or non-functional? Third type of requirement sentences exist: sentences where the verb is a linking verb Example: The seat must be easy to adjust. (seat=subject, be=linking verb, easy to adjust=subject compliment) In this type of sentence, the verb is not representing an action, this structure of sentence is representing a non-functional requirement.

  27. Classifying rules from grammatical structures

  28. Tool example This tool defines specific grammatical structures for expressing requirements: http://freespace.virgin.net/gbjedi/books/re/boilerplates/repository.htm

  29. Common keywords Finding common keywords in different requirements sentences Helps finding links/interactions/contradictions between 2 requirements from different categories Example: file:///C:/Users/Francois/Desktop/MadeByGraph/simAnalysis.htm

  30. Searching for required performance From Qualitative to Quantitative requirements: For requirements containing comparative or superlative such as: easier, better, simpler, faster Ask about: • What does the comparative or superlative refer to? • How to measure? • Which unit?

  31. Searching for required performance Words like never, always, ever, everybody, nobody, all: • often generalize a fact Ask about: • Really always? • Really everybody? • Really never?

  32. Thank for your attentionExercises:- Analyse EU-robot rules document.- Extract requirements related to the objectives of your own project

More Related