Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Modelling Software Requirements: Important diagrams and templates (lecture slides)

6.102 Aufrufe

Veröffentlicht am

Online lecture at the School of Computer Science, University of Hertfordshire, Hatfield, UK, as part of the 11th Europe Week from 2nd to 6th March 2015.

Veröffentlicht in: Bildung
  • Als Erste(r) kommentieren

Modelling Software Requirements: Important diagrams and templates (lecture slides)

  1. 1. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Modelling Software Requirements –Important diagrams and templates– Prof. Dr. Dagmar Monett Díaz Computer Science Dept. Faculty of Cooperative Studies Berlin School of Economics and Law dagmar@monettdiaz.com Europe Week, 2nd – 6th March 2015 120 Minutes
  2. 2. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Dilbert  Scott Adams At http://dilbert.com/strip/2000-02-27/ (Educational/Classroom usage permission is granted by Universal Uclick. All Rights Reserved) Oh, my, diagrams… 2
  3. 3. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 3 Main topics
  4. 4. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 4 Main topics  Where does the major content come from?  Requirements Engineering and Requirements Development: An Overview  Why using visual models?  The Requirements Modelling Language (RML) - Objectives, People, Systems and Data Models  The Unified Modelling Language (UML) - Most used UML diagrams  What’s next? Further reading, sources of inspiration
  5. 5. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 5 Next topics…  Where does the major content come from?  Requirements Engineering and Requirements Development: An Overview  Why using visual models?  The Requirements Modelling Language (RML) - Objectives, People, Systems and Data Models  The Unified Modelling Language (UML) - Most used UML diagrams  What’s next? Further reading, sources of inspiration
  6. 6. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 6 ©
  7. 7. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Visual Models for Software Requirements Joy Beatty and Anthony Chen 1st Edition, 480 pp. Microsoft Press, 2012 ISBN-13: 978-0-7356-6772-3 (See more at https://www.microsoftpressstore.com/store/vis ual-models-for-software-requirements- 9780735667723) 7 Wiegers & Beatty
  8. 8. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Software Requirements Karl Wiegers and Joy Beatty 3rd Edition, 672 pp. Microsoft Press, 2013 ISBN-13: 978-0-7356-7966-5 (See more at http://aka.ms/SoftwareReq3E/files) 8 Wiegers & Beatty
  9. 9. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Software Engineering Ian Sommerville 9th Edition, 792 pp. Addison-Wesley, 2010 ISBN-13: 978-0137035151 (10th Edition: April 2015. See more at http://iansommerville.com/software- engineering-book/) 9 Sommerville
  10. 10. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 10 The traditional software development process: Perceptions, communication patterns and interests…
  11. 11. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 11Cartoon  http://projectcartoon.com/
  12. 12. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 12Cartoon  http://projectcartoon.com/
  13. 13. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 13 Requirements and Requirements Engineering – An Overview –
  14. 14. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 14 A requirement is… According to Wiegers & Beatty: “[A requirement is a] statement of a customer need or objective, or of a condition or capability that a product must possess to satisfy such a need or objective. A property that a product must have to provide value to a stakeholder.” See lecture “A Structured Approach to Requirements Analysis” for more on this topic!
  15. 15. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Requirements Engineering Definition according to Wiegers & Beatty: Requirements engineering is the subdiscipline of systems engineering and software engineering that encompasses all project activities associated with understanding a product's necessary capabilities and attributes. Includes both requirements development and requirements management. 15 See lecture “A Structured Approach to Requirements Analysis” for more on this topic!
  16. 16. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 16 Subdisciplines of Requirements Engineering
  17. 17. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 17 Subdisciplines of Requirements Engineering Requirements Engineering Requirements Development Requirements Management Acc. to Wiegers & Beatty See lecture “A Structured Approach to Requirements Analysis” for more on this topic!
  18. 18. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 18 Subdisciplines of Requirements Development Elicitation Requirements Engineering Analysis Specification Validation Requirements Development Requirements Management Acc. to Wiegers & Beatty See lecture “A Structured Approach to Requirements Analysis” for more on this topic!
  19. 19. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 19 Subdisciplines of Requirements Management Tracking Requirements Engineering Managing Controlling Tracing Requirements Development Requirements Management Acc. to Wiegers & Beatty See lecture “A Structured Approach to Requirements Analysis” for more on this topic!
  20. 20. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 20 Topics of other related lectures
  21. 21. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 21 Subdisciplines of Requirements Engineering Elicitation Requirements Engineering Analysis Specification Validation Requirements Development Requirements Management All are topics of lecture: “A Structured Approach to Requirements Analysis”
  22. 22. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 22 Subdisciplines of Requirements Development Requirements Engineering Requirements Development Requirements Management Elicitation Analysis Specification Validation Topic of lecture “Requirements Engineering Techniques for Eliciting Requirements”
  23. 23. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 23 Subdisciplines of Requirements Development Requirements Engineering Requirements Development Requirements Management Elicitation Specification Validation Topics of lecture “Requirements Engineering Methods for Documenting Requirements” Analysis
  24. 24. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 24 Subdisciplines of Requirements Development Requirements Engineering Requirements Development Requirements Management Elicitation Analysis Specification Validation Topic of (this) lecture “Modelling Software Requirements. Important diagrams and templates”
  25. 25. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 25 Subdisciplines of Requirements Development Requirements Engineering Requirements Development Requirements Management Elicitation Analysis Specification Validation Topic of lecture “Methods for Validating and Testing Software Requirements”
  26. 26. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 26 A Requirements Development process framework
  27. 27. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 27 Subdisciplines of Requirements Development Elicitation Requirements Engineering Analysis Specification Validation Requirements Development Requirements Management Acc. to Wiegers & Beatty
  28. 28. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield RD process framework 28 Elicitation Analysis Specification Validation re-evaluate Adapted from Wiegers & Beatty identifying, discovering evaluating, verifying documenting, SRS classifying, representing, deriving, negotiating RD: Requirements Development SRS: Software Requirements Specification See lecture “A Structured Approach to Requirements Analysis” for details!
  29. 29. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 29 A structured approach to Requirements Development
  30. 30. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 30 A structured approach to RD (1) Define stakeholders!  Who is interested in the system?  Who makes decisions?  Who are the users, managers, developers, etc.? In other words, WHO has influence on the software requirements? (2) Define goals!  Stakeholders have goals (define coarse goals!)  These goals can be divided into more specific goals (define granular goals!) In other words, WHAT should be implemented or achieved? (3) Define requirements!  Goals can be derived into concrete requirements  How to get to the requirements? (goal-based!)  Model those requirements using diagrams, templates, etc. In other words, HOW will the goals be achieved?
  31. 31. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 31 A structured approach to RD Granular goals CG3 CG2 CG1 Coarse goals Define stakeholders Define goals Define requirements Diagrams Templates Models WHO WHAT HOW See lecture “A Structured Approach to Requirements Analysis” for details!
  32. 32. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 32 Requirements Specification
  33. 33. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield RD process framework 33 Elicitation Analysis Specification Validation re-evaluate Adapted from Wiegers & Beatty identifying, discovering evaluating, verifying documenting, SRS classifying, representing, deriving, negotiating RD: Requirements Development SRS: Software Requirements Specification
  34. 34. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield RD process framework 34 Elicitation Analysis Specification Validation re-evaluate Adapted from Wiegers & Beatty identifying, discovering evaluating, verifying documenting, SRS classifying, representing, deriving, negotiating RD: Requirements Development SRS: Software Requirements Specification
  35. 35. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Specification: Definition 35 Acc. to Wiegers & Beatty Specification “[Specification is the] process of documenting a software application's requirements in a structured, shareable, and manageable form. Also, the product from this process.”
  36. 36. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 36 A structured approach to RD Granular goals CG3 CG2 CG1 Coarse goals Define stakeholders Define goals Define requirements Diagrams Templates Models WHO WHAT HOW classifying, representing, deriving, negotiating identifying, discovering documenting, SRS + + evaluating, verifying +
  37. 37. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 37 Key actions in specification
  38. 38. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Key action 38 Acc. to Wiegers & Beatty Specification Translating the collected user needs into written requirements and diagrams suitable for comprehension, review, and use by their intended audiences.
  39. 39. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 39 So far…  Where does the major content come from?  Requirements Engineering and Requirements Development: An Overview  Why using visual models?  The Requirements Modelling Language (RML) - Objectives, People, Systems and Data Models  The Unified Modelling Language (UML) - Most used UML diagrams  What’s next? Further reading, sources of inspiration
  40. 40. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 40 Next topics…  Where does the major content come from?  Requirements Engineering and Requirements Development: An Overview  Why using visual models?  The Requirements Modelling Language (RML) - Objectives, People, Systems and Data Models  The Unified Modelling Language (UML) - Most used UML diagrams  What’s next? Further reading, sources of inspiration
  41. 41. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 41 Why using visual models?
  42. 42. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 42 Why using visual models?  A picture is worth a thousand word!  Communicating certain type of information more efficiently.  As a means of facilitating discussion about an existing or proposed system - Incomplete and incorrect models are OK as their role is to support discussion.  As a way of documenting an existing system - Models should be an accurate representation of the system but need not be complete.  As a detailed system description that can be used to generate a system implementation - Models have to be both correct and complete. Acc. to Sommerville
  43. 43. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 43 Requirements Modelling Language (RML)
  44. 44. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 44 Requirements Modelling Language  RML® – to visually model requirements  RML focuses on specifying needs, rather than solution designs.  It looks at a project’s goals and objectives.  It uses models to break down these objectives into requirements which are easily understood by both business stakeholders and developers.  The RML models can be used as a starting point for many of the models within UML and SysML. According to Seilevel @ http://www.seilevel.com/ba-resources/rml-requirements-visual-models/
  45. 45. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 45 RML classification of models
  46. 46. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 46 RML Model categorisation According to Beatty & Chen O P S D OPSD classification of RML models Objectives of the solution People who are using the solution Systems themselves Data that is being processed
  47. 47. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 47 RML Objectives Models
  48. 48. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 48 RML Objectives Models According to Beatty & Chen O P S D OPSD classification of RML models Objectives of the solution “Describe the business value of the system and help prioritise features and requirements based on their value.”
  49. 49. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 49 RML Objectives Models According to Beatty & Chen O P S D  Business Objectives Model  Objective Chain  Key Performance Indicator Model  Feature Tree  Requirements Mapping Matrix
  50. 50. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 50 Business Objective Model
  51. 51. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Business Objective Model 51 “The Business Objective Model (BOM) is created to document a project’s value [for the end users and] for the company creating it.” According to Beatty & Chen: (© Seilevel. See more at http://www.seilevel.com/ba-resources/rml-requirements-visual- models/business-objective-model/ )
  52. 52. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 52 BOM Template RML® model created by Seilevel http://www.seilevel.com/
  53. 53. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 53 BOM Template RML® model created by Seilevel http://www.seilevel.com/ Measurable target that specifies when the business problem is solved Vision, product concept to solve the business problem It measures whether the business objective or the solution is successful or not Issue preventing the business from achieving its goals pair
  54. 54. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 54 BOM Example RML® model created by Seilevel http://www.seilevel.com/ “Executives at a printer company evaluate their financial success”
  55. 55. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 55 Feature Tree
  56. 56. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Feature Tree 56 “Feature Trees are high-level models organizing features into feature groups, capturing the entire scope of a project into a single model. They show the relationships between features” According to Beatty & Chen: (© Seilevel. See more at http://www.seilevel.com/ba-resources/rml-requirements-visual- models/feature-tree/)
  57. 57. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 57 Feature Tree Template RML® model created by Seilevel http://www.seilevel.com/
  58. 58. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 58 Feature Tree Template RML® model created by Seilevel http://www.seilevel.com/ Levels of detail: highest level features (L1), mid-level features (L2), and low-level features (L3) This is a subfeature This is a main feature A “fishbone” diagram The product concept being developed
  59. 59. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 59 Feature Tree Example RML® model created by Seilevel http://www.seilevel.com/ “Content access at a training organisation’s portal”
  60. 60. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Dilbert  Scott Adams At http://dilbert.com/strip/2013-02-25/ (Educational/Classroom usage permission is granted by Universal Uclick. All Rights Reserved) Features in teamwork… 60
  61. 61. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 61 RML People Models
  62. 62. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 62 RML People Models According to Beatty & Chen O P S D OPSD classification of RML models People who are using the solution “Describe who is using the system along with their business processes and goals.”
  63. 63. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 63 RML People Models According to Beatty & Chen  Organisation Chart  Process Flow  Use Case  Roles and Permissions Matrix O P S D
  64. 64. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 64 Organisation Chart
  65. 65. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Organisation Chart 65 “An Org Chart is a collection of boxes connected by lines with a hierarchical structure.” According to Beatty & Chen: (© Seilevel. See more at http://www.seilevel.com/ba-resources/rml-requirements-visual- models/organization-charts/ )
  66. 66. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 66 Organisation Chart Template RML® model created by Seilevel http://www.seilevel.com/
  67. 67. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 67 Organisation Chart Template RML® model created by Seilevel http://www.seilevel.com/ Organizational group name, role or individual person Hierarchical reporting relationships within the organisation
  68. 68. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 68 Organisation Chart Example RML® model created by Seilevel http://www.seilevel.com/ “Individual Org Chart for an automobile manufacturing organisation” VP: Vice-President; IT: Information Technology; QA: Quality-Assurance; BA: Business Analyst
  69. 69. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 69 Use Case template, use case diagram, and use case scenario
  70. 70. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Use Case 70 “A Use Case is a people model that describes the interactions between the actors and a system. The value of a use case is that it helps users picture themselves executing a task, allowing them to identify the features that might be required to support each step.” According to Beatty & Chen: (© Seilevel. See more at http://www.seilevel.com/ba-resources/rml-requirements-visual- models/use-cases/ )
  71. 71. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 71 Use Case Template RML® model created by Seilevel http://www.seilevel.com/
  72. 72. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 72 Use Case Template RML® model created by Seilevel http://www.seilevel.com/ Headerfields Userinteractions withthesystem
  73. 73. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 73 How to identify actors?  Who (or what) is notified when something occurs within the system?  Who (or what) provides information or services to the system?  Who (or what) helps the system respond to and complete a task? According to Joy Beatty Actors: persons, actual people (stakeholders), but also another software system, or a hardware device.
  74. 74. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 74 Sample Use Cases According to Joy Beatty Application: Airport check-in kiosk Check in for a flight Print boarding passes Change seats Check luggage Purchase an upgrade Application: Online bookstore Update customer profile Search for an item Buy an item Track a shipped package Cancel an unshipped order <action> + <object>
  75. 75. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 75 Example: Patient information system Adapted from Ian Sommerville’s book Register patient View personal info View record Edit record Setup consultation Export statistics Generate reportMedical receptionist Nurse Manager Doctor
  76. 76. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 76 Example: Patient information system Adapted from Ian Sommerville’s book Register patient Unregister patient View personal info Transfer data Contact patient Medical receptionist Other use cases that involve the Medical receptionist:
  77. 77. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 77 Use case modelling Adapted from Ian Sommerville’s book Single use case of the Patient Management System: Transfer data Medical receptionist Patient record system
  78. 78. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Transfer data 78 Use case modelling Adapted from Ian Sommerville’s book Medical receptionist Patient record system Message pass in both directions but the Medical receptionist initiates the transaction Also used to represent external systems and hardware (and not only human interaction) There are two actors that interact with the system This is the task that involves the external interaction, i.e., the use case Single use case of the Patient Management System:
  79. 79. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 79 Use case modelling Adapted from Ian Sommerville’s book Transfer data Medical receptionist Patient record system Name Transfer data Description A receptionist may transfer data (patient’s personal information, treatment summary) from the Patient Management System to a general patient record database. Actors Medical receptionist, Patient record system. Frequency of use Every time the patient’s information is updated. Triggers User command issued by medical receptionist. … …
  80. 80. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 80 How to identify Use Cases?  What functions will the actor want from the system?  Does the system store information?  Do the actors need to create, update, or delete information?  Does the system need to notify an actor about changes in an internal state?  Are there any external events the system must know about?  What is the actor’s overall job?  What problems has the actor had in the past?  What steps are manual today? According to Joy Beatty
  81. 81. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 81 Use case scenario  A scenario is “a real-life example of how a system can be used.”  …“an instance of a use case” (Wiegers & Beatty).  …“a single thread through the use case.”  …a normal flow but also alternative flows and exceptions.  It should include: - A description of the starting situation; - A description of the normal flow of events; - A description of what can go wrong; - Information about other concurrent activities; - A description of the state when the scenario finishes. According to Ian Sommerville
  82. 82. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 82 Example of usage scenario “Setup consultation allows two or more doctors, working in different offices, to view the same record at the same time. One doctor initiates the consultation by choosing the people involved from a drop-down menu of doctors who are on-line. The patient record is then displayed on their screens but only the initiating doctor can edit the record. In addition, a text chat window is created to help coordinate actions. It is assumed that a phone conference for voice communication will be separately set up.” According to Ian Sommerville
  83. 83. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 83 Normal and alternative flows Adapted from Wiegers & Beatty Step 1 Step 2 Step 3 Step 4 Step 3a Step 3b Step 3c (use case preconditions) (use case postconditions) (branch condition) (continuation condition) Normal flow Alternative flow Activitydiagram!
  84. 84. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 84 How to identify alternatives?  Is there some other action that can be chosen?  If X does not happen, then what should happen?  What if the actor cancels an operation (e.g., closes a window)?  What if the actor provides incomplete information?  What might go wrong at this step?  What if part of the system goes down or is unavailable?  Are there any events (or interrupts) that might occur at any time during the use case? According to Joy Beatty
  85. 85. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 85 Active learning exercise Image © renjith krishnan at http://www.freedigitalphotos.net/
  86. 86. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Quiz 86 (Taken from the public Examination Questionnaire Set © IREB, International Requirements Engineering Board e.V.) What is not depicted in a use case diagram? (A) The actors of an application. (B) The use cases of an application. (C) An application’s functionality. (D) The process steps of an application.
  87. 87. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 87 RML Systems Models
  88. 88. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 88 RML Systems Models According to Beatty & Chen O P S D OPSD classification of RML models Systems themselves “Describe what systems exist, what the user interface looks like, how the systems interact, and how they behave.”
  89. 89. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 89 RML Systems Models According to Beatty & Chen  Ecosystem Map  System Flow  User Interface Flow  Display-Action-Response  Decision Table  Decision Tree  System Interface Table O P S D
  90. 90. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 90 User Interface Flow
  91. 91. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield User Interface Flow 91 “User Interface Flows show graphically how a user will navigate a solution’s user interface. They are system models that show how different pages (screens) of a user interface are connected and how a user can step through various pages of the system (navigation paths).” According to Beatty & Chen: (© Seilevel. See more at http://www.seilevel.com/ba-resources/rml-requirements-visual- models/user-interface-flow/ )
  92. 92. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 92 User Interface Flow Template RML® model created by Seilevel http://www.seilevel.com/
  93. 93. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 93 User Interface Flow Template RML® model created by Seilevel http://www.seilevel.com/ Screens (UI pages) Directional arrow that orders the navigation path between screens Action Smaller section to ease readability when common functionality
  94. 94. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 94 User Interface Flow Example RML® model created by Seilevel http://www.seilevel.com/ “UI flow for a trivia system in which users take quizzes with trivia questions”
  95. 95. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 95 Decision Tree and Decision Table
  96. 96. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Decision Tree 96 “The Decision Tree shows complex logic, allowing you to analyze a series of decisions. It is significantly easier to validate the logic visually in a Decision Tree than by describing the logic in a list of statements.” According to Beatty & Chen: (© Seilevel. See more at http://www.seilevel.com/ba-resources/rml-requirements-visual- models/8386-2/ )
  97. 97. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 97 Decision Tree Template RML® model created by Seilevel http://www.seilevel.com/
  98. 98. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 98 Decision Tree Template Conditions, phrased as questions Possible values. Answers to the questions asked in the decision Expected outcomes or behaviours of the system. The result of taking a decision choice pathway RML® model created by Seilevel http://www.seilevel.com/
  99. 99. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 99 Decision Tree Example RML® model created by Seilevel http://www.seilevel.com/ “An insurance company’s process to determine eligibility for home insurance policies”
  100. 100. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Decision Table 100 “A Decision Table helps you to analyze all the permutations of complex logic in a comprehensive way. They are used if there is no specific order to evaluating the decisions. If the decisions need to be made in any kind of order, a Decision Tree should be used instead.” According to Beatty & Chen: (© Seilevel. See more at http://www.seilevel.com/ba-resources/rml-requirements-visual- models/8445-2/ )
  101. 101. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 101 Decision Table Example  It answers the question “Under what conditions will an outcome occur?”  Or “Given these conditions, what outcome should I choose?” RML® model created by Seilevel http://www.seilevel.com/
  102. 102. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 102 Decision Table Example This decision table shows the same logic as in the Decision Tree Example RML® model created by Seilevel http://www.seilevel.com/ Irrelevant outcome Outcome applies when the choices are valid Combination of choices
  103. 103. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 103 RML Data Models
  104. 104. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 104 RML Data Models According to Beatty & Chen O P S D OPSD classification of RML models Data that is being processed “Describe the relationships between business data objects from an end-user perspective, the life cycle of the data, and how the data is used to make decisions.”
  105. 105. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 105 RML Data Models According to Beatty & Chen  Business Data Diagram  Data Flow Diagram  Data Dictionary  State Table  State Diagram  Report Table O P S D
  106. 106. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 106 Data Flow Diagram
  107. 107. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Data Flow Diagram 107 “A Data Flow Diagram […] shows a visual representation of the flow of information through systems, data stores, and actors, focusing on how data changes or is used through processes.” According to Beatty & Chen: (© Seilevel. See more at http://www.seilevel.com/ba-resources/rml-requirements-visual- models/data-flow-diagrams/ )
  108. 108. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 108 Data Flow Diagram Template RML® model created by Seilevel http://www.seilevel.com/
  109. 109. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 109 Data Flow Diagram Template Internal to and manipulated by the system Data being placed into the store A read operation How data moves, flows through the system Data flow Processes communicate through data stores Also terminator RML® model created by Seilevel http://www.seilevel.com/
  110. 110. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 110 Data Flow Diagram Example RML® model created by Seilevel http://www.seilevel.com/ “How data flows in an order placement system”
  111. 111. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 111 State-Transition Diagram and State Table
  112. 112. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield State Diagram 112 “State Diagrams are data models that show the changes between states of business data objects in the system. They show the cycle of an object’s states, including events that trigger changes in state. They only show transitions, triggers, and the flow of the changes.” According to Beatty & Chen: (© Seilevel. See more at http://www.seilevel.com/ba-resources/rml-requirements-visual- models/state-diagrams/ )
  113. 113. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 113 State Diagram Template RML® model created by Seilevel http://www.seilevel.com/
  114. 114. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 114 State Diagram Template Final state Initial state A possible system state Allowed state change Event or condition that causes a change or transition RML® model created by Seilevel http://www.seilevel.com/
  115. 115. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 115 State Diagram Example RML® model created by Seilevel http://www.seilevel.com/ “A loan application system”
  116. 116. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield State Table 116 “A State Table is a data model used to identify all states and all possible single step changes between the states for a business data object. A state describes the stage of a business data object’s lifecycle. Object’s states must be unique and the object has to be in one of the states at all times.” According to Beatty & Chen: (© Seilevel. See more at http://www.seilevel.com/ba-resources/rml-requirements-visual- models/state-tables/ )
  117. 117. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 117 State Table Example RML® model created by Seilevel http://www.seilevel.com/
  118. 118. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 118 State Table Example All possible transitions between states in the form of a matrix. RML® model created by Seilevel http://www.seilevel.com/
  119. 119. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 119 So far…  Where does the major content come from?  Requirements Engineering and Requirements Development: An Overview  Why using visual models?  The Requirements Modelling Language (RML) - Objectives, People, Systems and Data Models  The Unified Modelling Language (UML) - Most used UML diagrams  What’s next? Further reading, sources of inspiration
  120. 120. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 120 Active learning exercise Image © renjith krishnan at http://www.freedigitalphotos.net/
  121. 121. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Quiz 121 Which RML models apply to the following definition: “They describe who is using the system along with their business processes and goals.”? (A) People models. (B) System models. (C) Data models. (D) Objectives models.
  122. 122. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 122 Next topics…  Where does the major content come from?  Requirements Engineering and Requirements Development: An Overview  Why using visual models?  The Requirements Modelling Language (RML) - Objectives, People, Systems and Data Models  The Unified Modelling Language (UML) - Most used UML diagrams  What’s next? Further reading, sources of inspiration
  123. 123. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 123 Unified Modelling Language (UML)
  124. 124. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 124 “The Unified Modelling Language™ - UML - is OMG's most-used specification, and the way the world models not only application structure, behaviour, and architecture, but also business process and data structure.” OMG is a not-for-profit computer industry specifications consortium UML® Resource Page: http://www.uml.org/ UML®
  125. 125. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 125 UML®  Unified Modelling Language.  The standard object-oriented modelling language.  Current standard: v. 2.4.1 (August 2011)  Originally, Unified Method (1995)  Roots: - OMT: Object-Modelling Technique (Booch) - OODA: Object-Oriented Domain Analysis (Rumbaugh) - OOSE: Object-oriented Software Engineering (Jacobson)
  126. 126. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 126 Most used UML diagrams
  127. 127. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 127 UML®  Activity diagrams, which show the activities involved in a process or in data processing.  Use case diagrams, which show the interactions between a system and its environment.  Sequence diagrams, which show interactions between actors and the system and between system components.  Class diagrams, which show the object classes in the system and the associations between these classes.  State diagrams, which show how the system reacts to internal and external events. According to Ian Sommerville Process model
  128. 128. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 128 Example of activity diagram Adapted from Booch, Rumbaugh & Jacobson set up order assign seats [single order] [subscription] assign seats debit account award bonus mail packet charge credit card
  129. 129. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 129 Example of activity diagram Adapted from Booch, Rumbaugh & Jacobson set up order end of activity, completion activity node (action) decision (branch) assign seats [single order] [subscription] guard condition synchronisation bar (concurrent fork) initiation assign seats debit account award bonus mail packet charge credit card alternative threads concurrent threads synchronisation bar (concurrent join) merge (unbranch)
  130. 130. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 130 UML®  Activity diagrams, which show the activities involved in a process or in data processing.  Use case diagrams, which show the interactions between a system and its environment.  Sequence diagrams, which show interactions between actors and the system and between system components.  Class diagrams, which show the object classes in the system and the associations between these classes.  State diagrams, which show how the system reacts to internal and external events. According to Ian Sommerville Interaction model
  131. 131. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 131 UML®  Activity diagrams, which show the activities involved in a process or in data processing.  Use case diagrams, which show the interactions between a system and its environment.  Sequence diagrams, which show interactions between actors and the system and between system components.  Class diagrams, which show the object classes in the system and the associations between these classes.  State diagrams, which show how the system reacts to internal and external events. According to Ian Sommerville Interaction model
  132. 132. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 132 Example of sequence diagram Adapted from Booch, Rumbaugh & Jacobson :Kiosk ticketServer:Server :CreditService insertCard(customer) pickDate(date) offer(seatChoice) select(seats) submit(order) charge(customer, amount) authorise ok print(order) sd BuyTickets destroy()
  133. 133. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 133 Example of sequence diagram Adapted from Booch, Rumbaugh & Jacobson :Kiosk ticketServer:Server :CreditService insertCard(customer) pickDate(date) offer(seatChoice) select(seats) submit(order) charge(customer, amount) authorise ok print(order) return message, dotted line lifeline time sd BuyTickets anonymous objectobject instance execution specification parameter synchronous message destroy() asynchronous message outside environment object destruction externalmessage point(gate) name
  134. 134. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 134 UML®  Activity diagrams, which show the activities involved in a process or in data processing.  Use case diagrams, which show the interactions between a system and its environment.  Sequence diagrams, which show interactions between actors and the system and between system components.  Class diagrams, which show the object classes in the system and the associations between these classes.  State diagrams, which show how the system reacts to internal and external events. According to Ian Sommerville Structural model
  135. 135. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 135 UML®  Activity diagrams, which show the activities involved in a process or in data processing.  Use case diagrams, which show the interactions between a system and its environment.  Sequence diagrams, which show interactions between actors and the system and between system components.  Class diagrams, which show the object classes in the system and the associations between these classes.  State diagrams, which show how the system reacts to internal and external events. According to Ian Sommerville Event-driven model
  136. 136. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 136 Example of state diagram Adapted from Booch, Rumbaugh & Jacobson set Idle Confirming Selling entry / sell () identifyUser: Identifying Selecting pick(seat) / add to selection (seat) Purchasing exit / eject card insert card push “cancel” push “resume” push “buy” push “confirm” / reset selection fail
  137. 137. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 137 Example of state diagram Adapted from Booch, Rumbaugh & Jacobson set Idle Confirming Selling entry / sell () identifyUser: Identifying Selecting pick(seat) / add to selection (seat) Purchasing exit / eject card insert card push “cancel” push “resume” push “buy” push “confirm” / reset selection failinitial state internal transition final state explicit exit normal exit event entry activity completion transition completion transition parameter event outer transition aborts internal activity simple state action composite state transition submachine state reference exit point exit activity state name
  138. 138. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 138 So far…  Where does the major content come from?  Requirements Engineering and Requirements Development: An Overview  Why using visual models?  The Requirements Modelling Language (RML) - Objectives, People, Systems and Data Models  The Unified Modelling Language (UML) - Most used UML diagrams  What’s next? Further reading, sources of inspiration
  139. 139. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 139 Active learning exercise Image © renjith krishnan at http://www.freedigitalphotos.net/
  140. 140. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Quiz 140 (Adapted from the public Examination Questionnaire Set © IREB, International Requirements Engineering Board e.V.) The management of a company hires a software engineer (you) to specify and develop a new e-commerce system. During initial discussions with different representatives of the customer you find the following: your main contact person described her ideas by telling you the expected interactions between specialists and the e-commerce system in the form of different flows of user actions and system reactions. Which approach is particularly well suited to elicit and document the requirements in this case? (A) Creating an organisation model. (B) Creating a use case diagram and documenting the use cases. (C) Creating a data flow model. (D) Creating a features tree.
  141. 141. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 141 Next topics…  Where does the major content come from?  Requirements Engineering and Requirements Development: An Overview  Why using visual models?  The Requirements Modelling Language (RML) - Objectives, People, Systems and Data Models  The Unified Modelling Language (UML) - Most used UML diagrams  What’s next? Further reading, sources of inspiration
  142. 142. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 142 To take away…
  143. 143. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 143 Why using visual models?  A picture is worth a thousand word!  Communicating certain type of information more efficiently.  As a means of facilitating discussion about an existing or proposed system - Incomplete and incorrect models are OK as their role is to support discussion.  As a way of documenting an existing system - Models should be an accurate representation of the system but need not be complete.  As a detailed system description that can be used to generate a system implementation - Models have to be both correct and complete. Acc. to Sommerville
  144. 144. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 144 RML Model categorisation According to Beatty & Chen O P S D OPSD classification of RML models Objectives of the solution People who are using the solution Systems themselves Data that is being processed
  145. 145. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 145 Use case modelling Adapted from Ian Sommerville’s book Transfer data Medical receptionist Patient record system Name Transfer data Description A receptionist may transfer data (patient’s personal information, treatment summary) from the Patient Management System to a general patient record database. Actors Medical receptionist, Patient record system. Frequency of use Every time the patient’s information is updated. Triggers User command issued by medical receptionist. … …
  146. 146. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 146 What comes next?
  147. 147. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 147 Subdisciplines of Requirements Development Requirements Engineering Requirements Development Requirements Management Elicitation Analysis Specification Validation Topic of lecture “Methods for Validating and Testing Software Requirements”
  148. 148. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield RD process framework 148 Elicitation Analysis Specification Validation re-evaluate Adapted from Wiegers & Beatty identifying, discovering evaluating, verifying documenting, SRS classifying, representing, deriving, negotiating RD: Requirements Development SRS: Software Requirements Specification
  149. 149. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 149 A structured approach to RD Granular goals CG3 CG2 CG1 Coarse goals Define stakeholders Define goals Define requirements Diagrams Templates Models WHO WHAT HOW classifying, representing, deriving, negotiating identifying, discovering documenting, SRS + + evaluating, verifying +
  150. 150. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 150 Other references
  151. 151. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Booch, Rumbaugh & Jacobson 151 The Unified Modeling Language User Guide Grady Booch, James Rumbaugh and Ivar Jacobson 2nd Edition, 496 pp. Addison-Wesley Professional, 2005 ISBN-13: 978-0321267979
  152. 152. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Rumbaugh, Jacobson & Booch 152 The Unified Modeling Language Reference Manual James Rumbaugh, Ivar Jacobson and Grady Booch 2nd Edition, 721 pp. Addison-Wesley Professional, 2004 ISBN-13: 978-0321718952
  153. 153. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Cockburn 153 Writing Effective Use Cases Alistair Cockburn 1st Edition, 304 pp. Addison-Wesley Professional, 2000 ISBN-13: 978-0201702255 (See http://alistair.cockburn.us/get/2465)
  154. 154. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Bittner & Spence 154 Use Case Modeling Kurt Bittner, Ian Spence 1st Edition, 368 pp. Addison-Wesley Professional, 2002 ISBN-13: 978-0201709131
  155. 155. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Requirements-Engineering und -Management: Aus der Praxis von klassisch bis agil Chris Rupp & die SOPHISTen 6th Edition, 570 pp. Carl Hanser Verlag München, 2014 ISBN-13: 978-3-446-43893-4 In German (Chapters and related topics in English are available for free at https://www.sophist.de/) 155 Rupp & The SOPHISTs
  156. 156. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Further reading  IREB - International Requirements Engineering Board e.V. http://www.ireb.org/en/service/downloads.html 156
  157. 157. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Conference sites…  21st International Working Conference on Requirements Engineering: Foundation for Software Quality (REFSQ 2015), Essen, Germany http://refsq.org/2015/ 157
  158. 158. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Conference sites…  23rd IEEE International Requirements Engineering Conference (RE’15), Ottawa, Canada http://re15.org/ 158
  159. 159. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 159 Homework: “Model software requirements of your current course projects using visual models from RML !” Image © renjith krishnan at http://www.freedigitalphotos.net/
  160. 160. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 160 The traditional software development process: Perceptions, communication patterns and interests…
  161. 161. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 161Cartoon  http://projectcartoon.com/
  162. 162. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 162 The ideal, perfect, still possible software development process: Perceptions, communication patterns and interests…
  163. 163. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 163Adapted from cartoon  http://projectcartoon.com/
  164. 164. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 164 Done!  Where does the major content come from?  Requirements Engineering and Requirements Development: An Overview  Why using visual models?  The Requirements Modelling Language (RML) - Objectives, People, Systems and Data Models  The Unified Modelling Language (UML) - Most used UML diagrams  What’s next? Further reading, sources of inspiration
  165. 165. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield Modelling Software Requirements –Important diagrams and templates– Prof. Dr. Dagmar Monett Díaz Computer Science Dept. Faculty of Cooperative Studies Berlin School of Economics and Law dagmar@monettdiaz.com Europe Week, 2nd – 6th March 2015 monettdiaz@dmonett

×