SEG 3101 - Labs and Tutorials
Please consult the Health
and Safety page from the Faculty of engineering and read the
Procedures and Safety Manual.
||STE 2052 (only one section left)
|Tutorial (Tuesday 17:30)
|Lab (Friday 13:00)
|Writing good requirements
||Inspection and critique of requirements
|Inspection and critique of requests for
|| Project stakeholder
||Brainstorming and Design
|Use case workshop
|Personas and user story
|Goal modelling tutorial
|Goal modelling lab
||Scenario/UCM modelling tutorial
|UCM/Feature interaction lab
|Precise modelling of domain models
|Precise modelling of lifecycles and feature
||RMSs and project
|RMSs and project
|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
Lab 1: Writing good requirements
Criticize these so-called requirements and... try to improve them
when necessary! In Word
Lab 2: Inspection and critique of SRS/RFP
The goals of this lab are:
- To give you an opportunity to examine a real software
- To give you an opportunity to familiarize yourself with real
requirements specification templates (e.g., as in the ISO/IEC/IEEE
29148:2011 standard, available on campus or via VPN).
- To give you an opportunity to examine a real request for
- To check your understanding of good requirements writing
practices based on constructive criticism.
- To improve an existing document on an unknown application
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.
- 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).
- 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
Presentation and questions/answers with one important stakeholder
who has experienced many problems in this context (Dr. Vahdat
Brainstorming Session / Design Thinking
- Setup (10 minutes)
- Overview of brainstorming session
- If you are only 2-3 in your team, please join
another small team
- Choose who will be the moderator and the scribe (take
turns if needed)
- Agree on consensus method and voting scheme
- Storm Phase (30 minutes)
- Quantity, quantity, quantity...
- Document your ideas where everybody can see them (board,
Google Docs, paper...)
- Calm Phase (20 minutes)
- Consolidate your ideas - synergy!
- Aim at accepting 20-25 ideas; vote if necessary
- Each team presents a couple of important and exciting ideas
- Teams are encouraged to "steal" ideas from other teams
- Lessons learned, and discussion of next project steps (8
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.
- Preparation: ~5 minutes
- Development: ~45 minutes
- Presentation and solution samples: ~20 minutes (probably 5
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
- Daniel the organizer (of a complex conference)
- Suzie the administrator (of the system)
- Karim the treasurer (of the complex conference)
- Lin the young student (who attends her first conference
- Diana the productive researcher (who participates to 5
conferences per year)
- Matt the workshop organizer
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
- Name and role
- Photo (anonymous and free)
- Demographic information
You might get some inspiration from this
Please paste your personas and stories in this
online Google document for the presentation / discussion!
- Preparation: ~5-10 minutes
- Development: ~45 minutes
- Presentation and discussion: ~20 minutes (probably the teams
that have not presented in the Use Case Workshop)
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.
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
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
- Organization and Preparedness (12 marks)
- Did you evaluate existing systems, if any?
- Do you know the results of the brainstorming session?
- The roles such as interviewer and scribe are clearly
identifiable at all times?
- Has the team prepared an adequate list of questions?
- Is the team taking notes or recording the interview?
- Is the team quickly running out of questions?
- Is the team on track to fulfill the objective of the
- Effectiveness: (15 marks)
- How good are the questions/follow-up?
- Can you identify the goals of the stakeholder?
- Can you identify ideal functionalities? Important ones?
- Have you done a suitable follow-up (short email) with the
stakeholder (copied to prof/TA)?
- Conduct/Clarity (4 marks)
- Are the team's questions clear and well-structured?
- Is the team using technical terms or assuming that the
customer has software engineering knowledge?
- Politeness (2 marks)
- Is the team polite before, during, and after the
interview (e.g., the customer should be thanked for his
time, offered a chance to ask questions...)
- Punctuality (2 marks)
Lab 6: Goal Modelling (GRL)
This lab has two parts:
Part I: Tutorial. Introduction to jUCMNav and GRL
- See LabGRL.zip
- Contains a 2 presentations (English and French) and 3 .jucm
demo files. Don't look at the solution yet; you need to learn
one step at a time!
Part II: Exercise
- When you have finished exploring the GRL language with the
jUCMNav tool, you are invited to do the following exercise.
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:
- The authors want a rapid submissions process and (especially)
a quick evaluation verdict.
- The reviewers want to be assigned papers of interest because
they know they will review interesting papers faster.
- The conference chairs want the system to be really secure and
wish to minimize their system management duties.
Two alternatives are considered for handling security concerns
for all users: password only, and password combined with captchas
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
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.
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
For other jUCMNav tutorials, see: http://jucmnav.softwareengineering.ca/twiki/bin/view/ProjetSEG/JUCMNavTutorials
Lab 7: Scenario Modeling and Feature Interaction Analysis
This lab is in two parts.
Part I: UCM and jUCMNav (Tutorial)
Part II: Feature Interactions (Lab)
- Instructions (Word, PDF)
- UCM model (jUCMNav) (make sure it is properly saved as
a .jucm file)
Lab 8: Precise domain, lifecycle, and feature models
The goals of this tutorial/lab are to get familiar with:
- domain modeling using UML 2 class diagrams and constraints
- system and lifecycle modeling using UML 2 state diagrams
- variability in software product lines and feature models
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 firstname.lastname@example.org
No need to start or use the local DOORS server.
Files for the tutorial/lab
The tutorial Zip
- DOORSintro.ppt: DOORS Introduction (PowerPoint)
- DOORSintro.pdf: DOORS Introduction (PDF)
- DOORS_101.dpa: DOORS Demo Project (import with File
--> Restore --> Project)
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)!
- Go to https://remoteapps.genie.uottawa.ca/ and log
in using the UOTTAWA\ domain prefix (e.g., UOTTAWA\damyot)
- Select IBM Rational DOORS 9.5
- This will download a .rdp file that you need to execute
(remote desktop configuration)
- Login again using the credentials from step 1
- Login to DOORS using the credentials you received by email
(you will be asked to change your password the first time you
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
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:
- Present a summary of the scope, structure,
and content of your requirements specification document
(possibly some sections may still need to be polished)
- Clarify any remaining issues and negotiate if
- Obtain approval from the client to move forward
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)