SEG 3101 - Labs and Tutorials


 Safety

Please consult the Health and Safety page from the Faculty of engineering and read the Laboratory Procedures and Safety Manual.

 Schedule


Tutorials/Laboratories

Tuesday 17:30-19:00 VNR 3035
Friday 13:00-14:30 STE 2052 (only one section left)
Week
Tutorial (Tuesday 17:30)
Lab (Friday 13:00)
Sept. 11
Lecture
Writing good requirements
Sept. 18 Inspection and critique of requirements specification
Inspection and critique of requests for proposals
Sept. 25 Project stakeholder presentation Brainstorming and Design Thinking
Oct. 2
Use case workshop
Personas and user story
Oct. 9
Stakeholder interview
Stakeholder interview
Oct. 16
Goal modelling tutorial
Goal modelling lab
Oct. 23
Study Break
Oct. 30 Scenario/UCM modelling tutorial
UCM/Feature interaction lab
Nov. 6
Precise modelling of domain models
Precise modelling of lifecycles and feature models
Nov. 13 DOORS tutorial
DOORS lab
Nov. 20 RMSs and project
RMSs and project
Nov. 27 Validation meeting
Validation meeting
Dec. 4
Revision / Exam preparation
No lab (study period)

In general, sample solutions will be made available in the private part of the Web site after the tutorial/lab.

 Lab 1: Writing good requirements


Criticize these so-called requirements and... try to improve them when necessary! In Word and PDF.

 Lab 2: Inspection and critique of SRS/RFP

The goals of this lab are:

The requirements document is about a Global Alert Resolution Network (GARNET). The request for proposals document comes from the University Health Network.

Part I: Critique of structure

Different templates and standards (particularly the ISO/IEC/IEEE 29148:2011 standard) are provided in the additional resources. You are invited to consult these templates and answer the following questions.
  1. Briefly describe two major positive aspects related to the SRS document structure. Justify your answer by specifying what you find appropriate for the document (e.g. a standard element relevant to the domain context).
  2. Briefly describe two major negative aspects related to the SRS document structure. Propose improvements based on your understanding of the document goals (what would improve the document such that it is better able to meet its goals) and standards (e.g. ISO/IEC/IEEE 29148:2011).

Part II: Critique of content

Using the characteristics of good requirements documents discussed in class and tutorial, identify 3 major problems in the SRS document and suggest improvements. Clearly indicate the part of the document in question (subsection, particular requirement, or recurring problem covering several sections/requirements), the observed problem, and your corrective measures (if possible).

Part III: Critique of a Request for Proposals

Writing good requirements and specifications is not limited to software. We also find requirements in contracts and in requests for proposals (RFPs, appels d'offres in French). For this real request for proposals, identify 3 major problems related to requirements (functional and non-functional) and suggest improvements that will bring the most value to the applicants and evaluators of this RFP.

 Lab 3: Stakeholder meeting and brainstorming session

This lab gives you an opportunity to test your skills in a brainstorming session! Please read the description of the project and familiarize yourself with the first deliverable. Look at the existing conferences and systems in order to prepare your questions and session.

Stakeholder meeting

Presentation and questions/answers with one important stakeholder who has experienced many problems in this context (Dr. Vahdat Abdelzad).

Brainstorming Session / Design Thinking

  1. Setup (10 minutes)
  2. Storm Phase (30 minutes)
  3. Calm Phase (20 minutes)
  4. Each team presents a couple of important and exciting ideas (12 minutes)
  5. Lessons learned, and discussion of next project steps (8 minutes)

 Lab 4: Use Cases, Personas, and User Stories

Use Case Workshop (Tutorial)

Here is the statement of work. You will define use cases that describe the use of elevators. Please, use the provided template.

Personas and User Stories (Lab)

Each team must prepare a persona description and up to 8 user stories for 1 or 2 user types for your project's system. Teams should ideally target different roles. For example:

You can use the template you want for user narratives. For personas, you can use this template or another as long as the following parts are covered:

You might get some inspiration from this tutorial.

Please paste your personas and stories in this online Google document for the presentation / discussion!

 Lab 5: Stakeholder Interview

You will be interviewing a stakeholder (Daniel Amyot on Tuesday, or student Lia Chauvel on Friday) for the project. Each interview will last 25 minutes maximum (entering/exiting, set-up, and hello/bye included...). All team members shall be there. Please be punctual as the interview time slot cannot be extended.

Interview slots

There should be a total of 8 teams. 6 will be able to use the lab / tutorial hours, but I need two teams outside of these hours for the moment (e.g., on 4:15pm and 4:45pm on Tuesday; these 2 teams get 30 minutes!). Please add your team to one of the slots in this Google document (2nd tab).

Interview evaluation criteria

This lab represents 35% of the grade for deliverable 2, composed of the following elements:
Caution: Please treat the person you are interviewing as an expert in the field in general and not as a person with a background in software engineering technology. We are playing our role, you are playing yours (and this does influence the evaluation of your interview).

 Lab 6: Goal Modelling (GRL)

This lab has two parts:

Part I: Tutorial. Introduction to jUCMNav and GRL

Part II: Exercise

Model
You are asked to model the concerns of various stakeholders for a software system used to manage scientific paper submissions and reviews for conferences. Using jUCMNav, create a GRL model (with more than one diagram) that minimally covers the following concerns. You can decompose your description into more detailed intentional elements if you feel it necessary:

Two alternatives are considered for handling security concerns for all users: password only, and password combined with captchas (see http://en.wikipedia.org/wiki/Captcha). Two alternatives are also considered for allocating submitted papers to reviewers: automatic allocation (based on paper keywords and reviewers’ interests), and an interactive allocation where the system makes suggestions (also based on paper keywords and reviewers’ interests) that need to be approved or modified by the conference chair.

Ensure you have used suitable actors with their intentional elements. Specify contribution levels that make sense, and possibly specify the importance of some of the goals.

Strategies
Develop 4 strategies illustrating the impact of all combinations of alternatives. Which of your combinations will maximize the satisfaction of the largest category of users? Who will dislike this solution? Do you have a strategy where all three types of stakeholders have a satisfaction level above 0? (Answers obviously depend on your model…).

You can also export the results of your strategy evaluations as a comma-separated values file and format it in a table, or export a PDF report.

Note: there might be a bug in the tool's export functionality, which might result in an Invalid thread access error. If this happens, select a strategy, run it in execution mode, and then export to CSV (or generate your PDF report).

Other Tutorials

For other jUCMNav tutorials, see: http://jucmnav.softwareengineering.ca/twiki/bin/view/ProjetSEG/JUCMNavTutorials

 Lab 7: Scenario Modeling and Feature Interaction Analysis with UCM

This lab is in two parts.

Part I: UCM and jUCMNav (Tutorial)

Part II: Feature Interactions (Lab)

 Lab 8:  Precise domain, lifecycle, and feature models

The goals of this tutorial/lab are to get familiar with:

Please follow these instructions (both English and French are provided). Part 1 will be covered in the tutorial and parts 2-3 in the lab.

 Lab 9: DOORS Tutorial

In this tutorial, you will learn how to create and manipulate requirements documents (formal modules) in DOORS and how to create and exploit links between individual requirements.

Accounts for DOORS

You should have received an email specifying your username and your temporary password for our central DOORS server. Have them ready for the lab. The tool will ask you to change your password.

To connect the DOORS client to the central DOORS server, edit the properties of the menu entry

        Start Menu \ Design \ IBM Rational \ IBM Rational DOORS 9.5

such that the end becomes

        ...5492B\Root\DOORS\9.5\bin\doors.exe -d 36677@137.122.91.105

No need to start or use the local DOORS server.

Files for the tutorial/lab

The tutorial Zip file contains:

Remote access to DOORS client

DOORS 9.5 is also available as one of the software applications that can be used remotely (even from home)!

  1. Go to https://remoteapps.genie.uottawa.ca/ and log in using the UOTTAWA\ domain prefix (e.g., UOTTAWA\damyot)
  2. Select IBM Rational DOORS 9.5
  3. This will download a .rdp file that you need to execute (remote desktop configuration)
  4. Login again using the credentials from step 1
  5. Login to DOORS using the credentials you received by email (you will be asked to change your password the first time you connect).

When you close the last window, the application may return an error message but this is not an issue (and IT is working to fix it).

You can move the .rdp file to your desktop or shortcuts.

 Lab 10: RMS and Project

This is a continuation of Lab 9 and an opportunity of progressing your project under the guidance of the TA (Malak). Make good use of her time to ask specific questions about the project, the validation meeting, and the third deliverable!

 Lab 11: Specification Validation Meetings

For the 3rd deliverable of the project, you will have a validation meeting with a major stakeholder (Daniel for the 3 teams who met Lia for the interview, and likely Malak for the teams who met Daniel for the interview) on the week of November 27.

The goals of the validation meeting are:

Each validation meeting will last 25 minutes maximum (entering/exiting, set-up, and hello/bye included...). All team members shall be there. Prototypes are most welcomed! Please be punctual as the meeting time slots cannot be extended.

The meetings will be held in two rooms during the tutorial (Nov. 28 for teams 8, 7, 2) and the lab (Dec. 1). See editable schedule (register your team!). As in for the interviews, two teams will need to meet outside of these regular slots (times to be negotiated with Daniel and Malak).

 Lab 12: Revision / Exam Preparation

The Tuesday tutorial on December 4 is booked for a revision session and final exam preparation (with Daniel)