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