Week 05 ToDos

1. Watch Lecture Videos

Watch the week 05 lecture videos in advance of your team meeting.

Lecture References:
See the course Resources→References for instructions on how to access lecture references.

• Karl Wiegers and Joy Beatty, Software Requirements, 3ed, Microsoft Press, 2013.
  • Chapter 12: A picture is worth 1024 words
  • Chapter 14: Beyond Functionality
• Soren Lauesen, Software Requirements: Styles and Techniques, 1ed., Pearson Education, 2001.
  • Chapter 6: Quality Requirements

---

2. Updated Use Case Diagram

Provide an updated Use Case diagram that includes the new use cases that were elicited with other teams in the Elicitation exerise in Week 4. Also, incorporate any feedback and suggestions for improvement that the TAs identified in your previous submission. Your models should have 5+ full use cases (don’t count sub use-cases). As before, use a diagram or modelling tool like LucidChart to create your use-case diagram. Supplement your diagram with a short description of each use case, explaining what that use case is about, and a short description of each actor. Put your use-case diagram and descriptions in the PDF file named «TeamName»_D5.pdf and submit it to LEARN.

Grading Scheme: Your Use Case Diagram and descriptions will be marked on the basis of (1) the Completeness and Correctness of your use-case diagram, (2) the level of detail of your use-case diagram, and (3) the Completeness and Clarity of the supplemental descriptions. See the Week5 rubric for details.

---

3. Workflow Models

Express your understanding of the user’s expected workflows as they use your proposed product in three use cases. Specifically, choose what your team considers to be the three most complex use cases in your updated use case diagram, and create one workflow model for each chosen use case. That workflow model should be an Activity Diagram if the use case has a complex workflow (i.e., complex control flow among users and product) OR a Data-Flow Diagram if the use case has a complex collection of data sources and sinks. For each workflow model, explain why your team decided that it was more appropriate to create an Activity Diagram vs. a Data-Flow Diagram. Also, to help us better understand your models, provide a short description of each process or activity in each model.

Use a diagram or modelling tool like LucidChart to create your workflow models. Include your models, explanations of model choice, and model descriptions in the PDF file named «TeamName»_D5.pdf and submit it to LEARN.

Here are example workflow models from the Modern Family project.

Grading Scheme: Most of the weight of this week’s deliverables is on your three workflow models. Your workflow models and descriptions will marked on the basis of the (1) Completeness, Correctness, and Level of Detail of the workflow models, (2) your explanation of your choice of which workflow model to create, and (3) the Completeness and Clarity of the workflow model descriptions. See the Week5 rubric for details.

---

4. Design Quality Requirements Interviews

In advance of running Quality Requirements Interviews, your team needs to hypothesize which quality attributes are the most important to your stakeholders. Specifically, identify six quality attributes that your team believes are most important to your project. Provide a short description of what each quality attribute means in the context of your project. For example, if you believe scalability is important, specify whether you are referring to the number of users (of which user clase) your solution should accommodate or the number or size of data your solution should accommodate. (For example, scalability in the context of WaterlooWorks can mean that the system needs to accommodate large numbers of students simultaneously logged in and viewing Job Postings, or that the system needs to process large numbers of student and employer rankings to produce matches of students to jobs.) For each quality attribute specify the units of measure for that attribute but do not specify target metrics. In Week 6, you will ask your stakeholders to provide the target metrics; however, by specifying the units of measure, you will help ensure that your stakeholders all specify their target metrics with respect to the same units of measure (which will make it easier for you to compare and combine their responses). Your team may decide that a quality attribute has two variants that are important to your project. (For example, the above scalability example mentions two meanings of “scalability” with respect to the WaterlooWorks system.) But to ensure that you consider a wide variety of quality attributes, limit the number of variants of any quality attribute to two variants and propose at least four distinct quality attributes as your hypothesized top-priority attributes for your project. Place your writeup in the PDF file named «TeamName»_D5.pdf and submit it to LEARN.

Here are examples of five quality attribute choices from the EduLab project, which supports the parents of homeschooled children by connecting them with teachers and online educational resources.

Grading Scheme: This writeup will be marked on the basis of (1) the Completeness of the descriptions of the quality attributes (number of attributes, units of measure, description of how the attributes apply to the context of your project), and (2) the Relevance of the quality attributes chosen. See the Week5 rubric for details.

---

Due Next Monday (Feb. 9, 8:59pm ET)

• Every team: Create a single PDF named «TeamName»_D5.pdf that includes the following, and submit it to LEARN
  • Updated Use-Case Diagram and supplemental descriptions
  • Workflow models, explanations, and descriptions
  • Quality Attribute choices and descriptions