SEG 3101 - Project
This project shall be done in teams of 4-5 people.
Name: Complex Conference Registration
Large scientific conferences are composed of hundreds of
participants and span several days, with several parallel events
such as formal presentations, guest speakers, workshops, tutorials,
demonstrations, posters, discussion panels, etc. These conferences
also offer several registration options. Here are some examples of
complex conferences with their programs and registration options:
There exist many generic systems supporting the management of
registrations (the bread and butter!) to a conference. For instance:
Despite the apparent saturation of this market, most major
scientific conferences end up developing their own registration
system (or hiring a company to do so). Generic registration systems
have difficulty managing:
Your project consists in producing a Software Requirements
Specification for a Complex Conference Registration System
(CCRS) that will provide most of the functionality and
services required to effectively manage registrations to conferences
such as those mentioned above.
- The combinatorial explosion of types of fees (student/regular,
early/late, member/non-member, author/participant, rich/poor
country, conference/workshops/all, etc.)
- Social activities (participants and companions) and additional
- Valid selection of affiliated events (workshops, tutorials,
- Various types of payment
- Modifications and cancellation scenarios with refund policies
- Business rules of the conference (e.g., one regular
registration per paper presented)
- Services to organizers (monitoring of registrations,
corrections, reports, etc.)
- Requests for invitation letters for visas
- And various constraints (meals, allergies, handicaps, need for
Deliverable 1 (5%, deadline: October 6)
This first deliverable focuses on a first list of prioritized
user requirements and will be relatively simple and short. To
help structuring your approach, here is a template to use for your
- Short overview of the purpose of this document
- One-paragraph, clear vision of your project
2. User Requirements
- Include the user requirements resulting from the
brainstorming / Design Thinking session and additional sources
- These requirements should be revised to be well written.
Eliminate duplicates and make them consistent without changing
the scope (i.e., without removing essential features).
- These requirements should be sorted by priority according to
their potential benefits without regard to
cost or development challenges.You can use a simple
prioritization scale (with 3-4 values).
- It could be interesting to add attributes to your
requirements (and make a table out of them instead of just a
- At least 25 requirements (including NFRs) are expected here.
- Your filtering/cleaning strategy and its success must be
discussed briefly (~ 1/2 page).
- Your prioritization strategy and its efficiency must be
discussed briefly (~ 1/2 page).
- Include the references cited in the document (e.g.,
standards, Web sites, competitors...), if any.
Here is an overview of the marking scheme for Deliverable 1:
- 50%: List of well-written user requirements
- 10%: Prioritization results
- 15%: Discussion of your strategy for cleaning up the initial
- 15%: Discussion of your prioritization strategy and of its
- 10%: Clarity and quality of the document, grammar
- 5% (bonus): Exciting vision!
Deliverable 2 (10%, deadline: November 3)
Stakeholder Requirements Specification
The following template is to be used for your document. The use of a
Requirements Management System (RMS) for this deliverable is allowed
(but not mandatory). Interview notes can simply be submitted
electronically (scanned or typed).
2. Domain description
2.1. Glossary (terms and acronyms)
2.2. General knowledge about the domain
Including competing/related systems if any
2.3. Environment and context
3. Initial description of the problem
3.1. Description of stakeholders and their goals
Include a GRL model describing relations between goals and
3.2. Description of the system scope
3.3. Main use cases
Three alternatives for you here:
3.4. Preliminary requirements
- Provide the main use cases using a UML use case diagram.
Detail two interesting ones in a textual form (be consistent
with your diagram!). Including at least one misuse case in
- Provide a Use Case Map model of your main use cases, and
provide appropriate plug-ins detailing at least two of them.
- Provide 20+ user stories for your main functionalities.
Document two of them with test-level details. Include at least
one negative user story.
Give a list of the system's preliminary requirements (in a
tabular form, with identifiers and other relevant attributes).
These requirements should reflect the points of view of stakeholders
(they could still be conflicting at this point).
Major risks on the project.
4. Aspects needing clarifications
5. Back to interviews
What were your objectives? How well have they been met? What
could have been done better?
6. Description of team and roles
Provide a table with all team members and the tasks they were
involved in for this deliverable. You can be specific by stating
percentages of the work done and number of hours spent by each
team member if this information is available. If for some
legitimate reasons, the work share is unbalanced, please state
these reasons in a short paragraph. Notice that the
information provided here might be used to adjust the project
final grade for the team members.
Appendix A: Interview notes
Summary of questions, answers, GUI elements, and other
- 35%: Interview
- 35%: Report
- Sections 1 to 6 of the above Stakeholder Requirements
- 20%: Elicitation Notes
- Appendix A of the Stakeholder Requirements Specification
- Summary of interview questions/answers
- 10%: Clarity and quality of the document, grammar
- Bonus up to 10%:
- Use of jUCMNav to model goals and of jUCMNav or some UML
tool to model the use cases
Deliverable 3 (10%, deadline December 5)
Software Requirements Specification
Your goal in this last deliverable is to produce a Software
Requirements Specification that includes useful attributes
and traceability information. The SRS shall be linked
to the (revised) goals of your second deliverable. Some points to
- The use of a Requirements Management System (e.g., DOORS,
Jira, ...) is MANDATORY for this
- Define and document useful attributes for your textual
- You shall include the stakeholder goals and GRL model from
your elicitation document (second deliverable) in the RMS
because your requirements shall be linked to these goals. Along
the way, you shall also update your GRL model from the second
deliverable in order to reflect certain modifications to your
understanding of the stakeholders, goals, and requirements.
- Feel free to use the jUCMNav to DOORS import feature, or (more
likely) simply list your goals and include the main diagram in a
module (manually or otherwise).
- You shall use an IEEE/ISO 29148-like template for
your software requirements module.
- Include a verification section or attribute that
specifies which method will be used to check each requirement (see
IEEE/ISO 29148, section 184.108.40.206 - How).
- Show to what extent your goals are aligned with your
requirements. Typed traceability links (e.g., in DOORS or in
another RMS) must be used here. If you use DOORS, do not use the
default link module (create your own).
- Use requirements inspection and validation techniques covered
in class to review the quality of your document and
requirements. Check your traceability coverage with your tool!
- In a separate document/module, Provide a table with
all team members and the tasks they were involved in for this
deliverable. You can be specific by stating percentages of the
work done and number of hours spent by each team member if this
information is available. If for some legitimate reasons, the
work share is unbalanced, please state these reasons in a short
paragraph. Notice that the information provided here might
be used to adjust the project final grade for the team members.
This is the last deliverable. Aim for quality rather
Usage of a Requirements Management Tool other than DOORS
If you do not use DOORS:
- You will need to provide Daniel and Malak with access to your
- You will have to provide a traceability matrix in your
document or something equivalent with your RMS.
Here is the marking scheme for this third deliverable (SRS):
- 25%: Efficiency of the validation meeting with the customer
- 5%: Organization of the meeting: preparation (including
prototypes), discussion among team members (distracting the
- 5%: Scope: adequate summary of the scope or objectives of
- 5%: Issues: clarification issues were addressed /
- 2%: Punctuality: team member start and finish on time
- 3%: Professionalism: politeness, respect, the customer
does not get cut while talking
- 5%: Negotiation of changes: the team must not always
accept the customer's major change requests without
clarification or negotiation
- 5%: Import/creation of your goals (GRL model) into the
- 15%: General conformance to IEEE 29148 template guidelines
(with eventual adjustments if models are included)
- 30%: Quality of requirements in SRS
- 15%: Use of traceability links and completeness/consistency
of the software requirements versus the goals.
- 10%: Clarity of the SRS, quality of the grammar and writing
- Bonus up to 10%: based on a case-by-case
evaluation of performance beyond expectations