requirements-engineering.html (9678B)
1 <!DOCTYPE html> 2 <html> 3 <head> 4 <script type="text/javascript" async src="https://cdn.jsdelivr.net/gh/mathjax/MathJax@2.7.5/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script> 5 <link rel="Stylesheet" type="text/css" href="style.css"> 6 <title>requirements-engineering</title> 7 <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 8 </head> 9 <body> 10 11 <div id="Requirements engineering with UML"><h2 id="Requirements engineering with UML">Requirements engineering with UML</h2></div> 12 13 <div id="Requirements engineering with UML-What is UML?"><h3 id="What is UML?">What is UML?</h3></div> 14 <p> 15 A unified modeling language, the defacto standard for software design. 16 </p> 17 18 <p> 19 pros: 20 </p> 21 <ul> 22 <li> 23 not tied to a development process 24 25 <li> 26 can be used across the whole life cycle 27 28 <li> 29 general purpose, can model all sorts of shit 30 31 <li> 32 has different representations (graphical, but also text) 33 34 </ul> 35 36 <p> 37 main characteristics: 38 </p> 39 <ul> 40 <li> 41 comprehensive: can describe all parts of a system 42 43 <li> 44 scalable: "zoom in" and add more details if you want 45 46 <li> 47 originally intended for descriptive models 48 49 <li> 50 now also supports prescriptive models 51 52 </ul> 53 54 <p> 55 formal modeling language — its core concepts have a well-defined meaning 56 </p> 57 58 <p> 59 UML model is represented graphically with diagrams 60 </p> 61 62 <p> 63 The different types: 64 </p> 65 66 <p> 67 <img src="img/uml-diagrams.png" alt="Diagram of diagrams" /> 68 </p> 69 70 <p> 71 The ones we will use: 72 </p> 73 <ul> 74 <li> 75 use case diagram: to specify the basic functionality of a software system (requirements) 76 77 <li> 78 class diagram: to define data structures within the system 79 80 <li> 81 state machine diagram: to define intra-object behavior 82 83 <li> 84 sequence diagram: to specify inter-object behavior and communication 85 86 </ul> 87 88 <p> 89 a UML <em>model</em> contains everything related to the system. a <em>diagram</em> is just a "window" on the model (shows some parts, but not necessarily everything). 90 </p> 91 92 <div id="Requirements engineering with UML-Requirements engineering"><h3 id="Requirements engineering">Requirements engineering</h3></div> 93 <p> 94 the process of establishing: 95 </p> 96 <ul> 97 <li> 98 features that a system should and will have 99 100 <li> 101 constraints under which it operates and is developed 102 103 </ul> 104 105 <p> 106 requirement can range between: 107 </p> 108 <ul> 109 <li> 110 high-level abstract statement of a feature 111 112 <li> 113 detailed mathematical functional specification 114 115 </ul> 116 117 <p> 118 functional (what) vs non-functional (how) requirements 119 </p> 120 <ul> 121 <li> 122 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. 123 124 <ul> 125 <li> 126 precise — ambiguous requirements may be interpreted in different ways by developers and users 127 128 <li> 129 complete — they should include descriptions of <em>all</em> facilities required 130 131 <li> 132 consistent — there should be no conflicts or contradictions in descriptions of system facilities 133 134 <li> 135 verifiable — requirements should be directly mapped to parts of system 136 137 </ul> 138 <li> 139 non-functional: constraints on services/functions offered by the system, often apply to system as a whole instead of individual features/services 140 141 <ul> 142 <li> 143 system properties and constraints (e.g. reliability, response time, storage requirements) 144 145 <li> 146 may be more critical than functional, like safety requirements 147 148 <li> 149 may affect overall architecture of a system instead of individual components (like organization to minimize communications between robots) 150 151 <li> 152 different types: 153 154 </ul> 155 </ul> 156 <blockquote> 157 <img src="img/non-func-requirements.png" alt="Non-functional requirement types" /> 158 </blockquote> 159 160 <p> 161 in UML: use case diagrams for functional requirements. 162 </p> 163 164 <p> 165 How to write requirements specifications: 166 </p> 167 168 <table> 169 <tr> 170 <th> 171 <span id="Requirements engineering with UML-Requirements engineering-Notation"></span><strong id="Notation">Notation</strong> 172 </th> 173 <th> 174 <span id="Requirements engineering with UML-Requirements engineering-Description"></span><strong id="Description">Description</strong> 175 </th> 176 </tr> 177 <tr> 178 <td> 179 Natural language 180 </td> 181 <td> 182 Use numbered sentences in natural language. Each sentence is one requirement. 183 </td> 184 </tr> 185 <tr> 186 <td> 187 Structured natural language. 188 </td> 189 <td> 190 Requirements are written in natural language on standard form/template. Each field gives info about an aspect of the requirement. 191 </td> 192 </tr> 193 <tr> 194 <td> 195 Design description languages 196 </td> 197 <td> 198 Use language like programming language, but with more abstract features specifying requirements by defining an operational model of the system. 199 </td> 200 </tr> 201 <tr> 202 <td> 203 Graphical notations 204 </td> 205 <td> 206 Graphical models with text annotations. e.g. UML use case and sequence diagrams. 207 </td> 208 </tr> 209 <tr> 210 <td> 211 Mathematical specifications 212 </td> 213 <td> 214 Based on math concepts like finite-state machines or sets. Most customers don't understand this so not often used. 215 </td> 216 </tr> 217 </table> 218 219 <div id="Requirements engineering with UML-Requirements engineering-Natural language specification"><h4 id="Natural language specification">Natural language specification</h4></div> 220 <p> 221 requirements are written as natural language sentences. used because it's expressive, intuitive, universal, easily understood by customers. 222 </p> 223 224 <p> 225 guidelines: 226 </p> 227 <ul> 228 <li> 229 invent a standard format, use it for all requirements. 230 231 <li> 232 use language in a consistent way ("shall" for mandatory requirements, "should" for desirable requirements) 233 234 <li> 235 highlight text to identify important parts of requirement 236 237 <li> 238 avoid use of computer jargon 239 240 <li> 241 include explanation (rationale) of why a requirement is needed 242 243 </ul> 244 245 <div id="Requirements engineering with UML-Requirements engineering-Use case diagrams"><h4 id="Use case diagrams">Use case diagrams</h4></div> 246 <p> 247 express expectations of customers/stakeholders. 248 </p> 249 250 <p> 251 answers questions: 252 </p> 253 <ul> 254 <li> 255 what is being described? (the system) 256 257 <li> 258 who interacts with the system? (the actors) 259 260 <li> 261 what can the actors do? (use cases) 262 263 </ul> 264 265 <p> 266 use case: 267 </p> 268 <ul> 269 <li> 270 describes functionality expected from system under development 271 272 <li> 273 set of all use cases describes functionality that a system shall provide. 274 275 <li> 276 notations: 277 278 </ul> 279 <blockquote> 280 <img src="img/use-case-notations.png" alt="Use case notations" /> 281 </blockquote> 282 283 <p> 284 actors: 285 </p> 286 <ul> 287 <li> 288 interact with the system by using use cases, or by being used by use cases. 289 290 <li> 291 represent roles that users adopt (users can have multiple roles) 292 293 <li> 294 not part of the system, so outside of system boundaries. 295 296 <li> 297 human or non-human 298 299 <li> 300 primary/secondary: 301 302 <ul> 303 <li> 304 if primary, has main benefit of execution of use case. 305 306 <li> 307 if secondary, receives no direct benefit. 308 309 </ul> 310 <li> 311 active or passive 312 313 <ul> 314 <li> 315 active: initiates execution of the use case 316 317 <li> 318 passive: provides functionality for the execution of the use case 319 320 </ul> 321 </ul> 322 <blockquote> 323 <img src="img/actor-notations.png" alt="Actor notations" /> 324 </blockquote> 325 326 <p> 327 relationships between use cases and actors: 328 </p> 329 <ul> 330 <li> 331 actors are connected with use cases via associations (solid lines) 332 333 <li> 334 every actors has to communicate with at least one use case 335 336 <li> 337 association is always binary, multiplicities can be specified 338 339 </ul> 340 <blockquote> 341 <img src="img/usecase-actor-rel.png" alt="Relationships between actors and use cases" /> 342 </blockquote> 343 344 <p> 345 relationships between use cases: 346 </p> 347 <ul> 348 <li> 349 «include» 350 351 <ul> 352 <li> 353 behavior of one use case ('included') <em>is always</em> integrated in the behavior of another use case ('base') 354 355 </ul> 356 </ul> 357 <blockquote> 358 <img src="img/usecase-include-rel.png" alt="Include relationship" /> 359 </blockquote> 360 <ul> 361 <li> 362 «extend» 363 364 <ul> 365 <li> 366 behavior of one use case ('extending') <em>may be</em> integrated in behavior of another use case ('base') 367 368 <li> 369 both use cases can also be executed independently of each other 370 371 <li> 372 extension points are written directly in the use case. you can specify multiple extension points. 373 374 </ul> 375 </ul> 376 <blockquote> 377 <img src="img/use-case-extensions.png" alt="Extensions in use cases" /> 378 </blockquote> 379 <ul> 380 <li> 381 generalization of use cases 382 383 <ul> 384 <li> 385 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. 386 387 <li> 388 A may be labeled {abstract} — cannot be executed directly, only B is executable 389 390 </ul> 391 </ul> 392 <blockquote> 393 <img src="img/usecase-generalisation.png" alt="Generalisation" /> 394 </blockquote> 395 396 <p> 397 relationships between actors 398 </p> 399 <ul> 400 <li> 401 generalization 402 403 <ul> 404 <li> 405 actor A inherits from actor B. e.g. A can communicate with X and Y, B can only communicate with Y. 406 407 <li> 408 abstract actors are possible 409 410 </ul> 411 </ul> 412 <blockquote> 413 <img src="img/actor-generalization.png" alt="Actor generalization" /> 414 </blockquote> 415 416 <p> 417 Description of use cases: 418 </p> 419 <ul> 420 <li> 421 Name 422 423 <li> 424 Short description 425 426 <li> 427 Precondition: prerequisite for successful execution 428 429 <li> 430 Postcondition: system state after successful execution 431 432 <li> 433 Error situations: errors relevant to problem domain 434 435 <li> 436 System state on occurrence of an error 437 438 <li> 439 Actors that communicate with the use case 440 441 <li> 442 Trigger: events which initiate the use case 443 444 <li> 445 Standard process: individual steps to be taken 446 447 <li> 448 Alternative processes: deviations from the standard process 449 450 </ul> 451 452 <p> 453 Remember, it's an abstraction. Many small use cases with the same objective should be grouped. Don't decompose functionality into use cases. 454 </p> 455 456 <div id="Requirements engineering with UML-Summary of notation"><h3 id="Summary of notation">Summary of notation</h3></div> 457 <p> 458 <img src="img/requirement-notation-p1.png" alt="Requirements notation" /> 459 </p> 460 461 <p> 462 <img src="img/requirement-notation-p2.png" alt="Requirements notation" /> 463 </p> 464 465 </body> 466 </html>