requirements-engineering.wiki (8043B)
1 == Requirements engineering with UML == 2 3 === What is UML? === 4 A unified modeling language, the defacto standard for software design. 5 6 pros: 7 * not tied to a development process 8 * can be used across the whole life cycle 9 * general purpose, can model all sorts of shit 10 * has different representations (graphical, but also text) 11 12 main characteristics: 13 * comprehensive: can describe all parts of a system 14 * scalable: "zoom in" and add more details if you want 15 * originally intended for descriptive models 16 * now also supports prescriptive models 17 18 formal modeling language — its core concepts have a well-defined meaning 19 20 UML model is represented graphically with diagrams 21 22 The different types: 23 24 {{file:img/uml-diagrams.png|Diagram of diagrams}} 25 26 The ones we will use: 27 * use case diagram: to specify the basic functionality of a software system (requirements) 28 * class diagram: to define data structures within the system 29 * state machine diagram: to define intra-object behavior 30 * sequence diagram: to specify inter-object behavior and communication 31 32 a UML _model_ contains everything related to the system. a _diagram_ is just a "window" on the model (shows some parts, but not necessarily everything). 33 34 === Requirements engineering === 35 the process of establishing: 36 * features that a system should and will have 37 * constraints under which it operates and is developed 38 39 requirement can range between: 40 * high-level abstract statement of a feature 41 * detailed mathematical functional specification 42 43 functional (what) vs non-functional (how) requirements 44 * functional: services the system should provide, how it should react to inputs, how it should behave in specific situations, opt. what it shouldn't do. 45 * precise — ambiguous requirements may be interpreted in different ways by developers and users 46 * complete — they should include descriptions of _all_ facilities required 47 * consistent — there should be no conflicts or contradictions in descriptions of system facilities 48 * verifiable — requirements should be directly mapped to parts of system 49 * non-functional: constraints on services/functions offered by the system, often apply to system as a whole instead of individual features/services 50 * system properties and constraints (e.g. reliability, response time, storage requirements) 51 * may be more critical than functional, like safety requirements 52 * may affect overall architecture of a system instead of individual components (like organization to minimize communications between robots) 53 * different types: 54 55 {{file:img/non-func-requirements.png|Non-functional requirement types}} 56 57 in UML: use case diagrams for functional requirements. 58 59 How to write requirements specifications: 60 61 | *Notation* | *Description* | 62 |------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------| 63 | Natural language | Use numbered sentences in natural language. Each sentence is one requirement. | 64 | Structured natural language. | Requirements are written in natural language on standard form/template. Each field gives info about an aspect of the requirement. | 65 | Design description languages | Use language like programming language, but with more abstract features specifying requirements by defining an operational model of the system. | 66 | Graphical notations | Graphical models with text annotations. e.g. UML use case and sequence diagrams. | 67 | Mathematical specifications | Based on math concepts like finite-state machines or sets. Most customers don't understand this so not often used. | 68 69 ==== Natural language specification ==== 70 requirements are written as natural language sentences. used because it's expressive, intuitive, universal, easily understood by customers. 71 72 guidelines: 73 * invent a standard format, use it for all requirements. 74 * use language in a consistent way ("shall" for mandatory requirements, "should" for desirable requirements) 75 * highlight text to identify important parts of requirement 76 * avoid use of computer jargon 77 * include explanation (rationale) of why a requirement is needed 78 79 ==== Use case diagrams ==== 80 express expectations of customers/stakeholders. 81 82 answers questions: 83 * what is being described? (the system) 84 * who interacts with the system? (the actors) 85 * what can the actors do? (use cases) 86 87 use case: 88 * describes functionality expected from system under development 89 * set of all use cases describes functionality that a system shall provide. 90 * notations: 91 92 {{file:img/use-case-notations.png|Use case notations}} 93 94 actors: 95 * interact with the system by using use cases, or by being used by use cases. 96 * represent roles that users adopt (users can have multiple roles) 97 * not part of the system, so outside of system boundaries. 98 * human or non-human 99 * primary/secondary: 100 * if primary, has main benefit of execution of use case. 101 * if secondary, receives no direct benefit. 102 * active or passive 103 * active: initiates execution of the use case 104 * passive: provides functionality for the execution of the use case 105 106 {{file:img/actor-notations.png|Actor notations}} 107 108 relationships between use cases and actors: 109 * actors are connected with use cases via associations (solid lines) 110 * every actors has to communicate with at least one use case 111 * association is always binary, multiplicities can be specified 112 113 {{file:img/usecase-actor-rel.png|Relationships between actors and use cases}} 114 115 relationships between use cases: 116 * «include» 117 * behavior of one use case ('included') _is always_ integrated in the behavior of another use case ('base') 118 119 {{file:img/usecase-include-rel.png|Include relationship}} 120 * «extend» 121 * behavior of one use case ('extending') _may be_ integrated in behavior of another use case ('base') 122 * both use cases can also be executed independently of each other 123 * extension points are written directly in the use case. you can specify multiple extension points. 124 125 {{file:img/use-case-extensions.png|Extensions in use cases}} 126 * generalization of use cases 127 * if use case A generalizes use case B, then B inherits behavior of A and may extend/overwrite it. B also inherits all relationships form A. 128 * A may be labeled {abstract} — cannot be executed directly, only B is executable 129 130 {{file:img/usecase-generalisation.png|Generalisation}} 131 132 relationships between actors 133 * generalization 134 * actor A inherits from actor B. e.g. A can communicate with X and Y, B can only communicate with Y. 135 * abstract actors are possible 136 137 {{file:img/actor-generalization.png|Actor generalization}} 138 139 Description of use cases: 140 * Name 141 * Short description 142 * Precondition: prerequisite for successful execution 143 * Postcondition: system state after successful execution 144 * Error situations: errors relevant to problem domain 145 * System state on occurrence of an error 146 * Actors that communicate with the use case 147 * Trigger: events which initiate the use case 148 * Standard process: individual steps to be taken 149 * Alternative processes: deviations from the standard process 150 151 Remember, it's an abstraction. Many small use cases with the same objective should be grouped. Don't decompose functionality into use cases. 152 153 === Summary of notation === 154 {{file:img/requirement-notation-p1.png|Requirements notation}} 155 156 {{file:img/requirement-notation-p2.png|Requirements notation}} 157