Requirements Engineering, Spring 2021

Project Phase II: Requirements Elicitation, Specification and

Validation
Due: May 16 (Sunday) – Interim Report II – A link to a softcopy should be submitted via blackboard,
and the softcopy posted on the team web site. Updated project plan also should be submitted.

Due: Final Project II submission, presentation and demo. At the time of the demo, a
hardcopy should be submitted, which should include;
Final project plan
Project I
Project II (Vision Document + WRS, possibly with the overlapping portion removed)
Any dependency/traceability between Project I and Project II, all in one document.

The hardest single part of building a software system is deciding precisely what to build.
No other part of the conceptual work is as difficult as establishing the detailed technical
requirements, including all the interfaces to people, to machines, and to other
software systems. No part of the work so cripples the resulting system if done wrong.
No other part is more difficult to rectify later. [Brooks, 1987]

I. Summary

Your team shall continue with the problem analysis from the first phase of the course project, but this
time using more advanced, (semi-)formal notations with richer ontologies.

For this phase of the problem analysis, you will be doing a second round of elicitation, analysis,
specification and validation of the Theia-like system, while accommodating some new changes to the
preliminary definition of the system.

More specifically, your team's task is to develop:

➢ Product Specification:
o Enterprise/domain/world/business modeling, using OO (module on
enterprise/business/systems modeling), GO/AO (modules on goal-oriented elicitation and
non-functional requirements).
o Software requirements modeling and specification, using OO/GO/AO.

➢ Process Specification:
• Functional process modeling, using IDEF/UML to model your own team’s RE process.
• Non-functional process modeling (using the NFR Framework/KAOS).
You should clearly describe the decision making process, whereby you chose the particular notation(s)
you’ve used for the product and process specifications.

It is recommended that your team consider using a tool, which can be found at
[Link]

II. Changes to the Preliminary Definition

Various customer surveys and the currently prevalent AAC market, seem to indicate some items of
critical importance to potential users, which your system must address:

➢ The system should save and present at least the last 5 phrases/words constructed by the user
through the system, conveniently from the main screen.
➢ To allow personalization, the users/assistive persons should be able to associate their own
text/name to an icon/image in the system and also be able to set the size of the icons on the
screen.
➢ A video phone, such as Skype, should be available, and video phone sessions should be recorded
if so desired by the user.
➢ Sensors (temperature, accelerometer, light, microphone, camera, etc.) should be maximally used
, if needed.
➢ Every menu item should be maximally 3 voice instructions away, but at the same time the system
should make available at least around 100 icons.

In case, your project is not within the scope of the existing system, your team should introduce
some changes on your own, according to the creeping rate estimate your team presented at the
end of the Project Phase I, and the changes should be approved by the instructor .

III. The Deliverable

Your description should be elegant and comprehensible. Your deliverable should be available as both on-
line (one URL per team member) and off-line specifications (submission of one copy per team).
You can choose to use a Vision Document/WRS-template/IEEE-style format for the deliverable, in which
the major sections typically include:
Introduction, Main Body (items below, for this project), Glossary (Definitions and Acronyms) and
References (See, for example, "Document Templates - general IEEE" on the course web site).

1. The Process Specification:

Your process specification should show all the iterations your team has gone through, each involving the
modeling and prototyping of your own Theia-like system. In other words, specify what activities your
team has carried out, who have been involved, in the project phases I and II, and what the relationship is
between the two phases, in terms of the inputs and outputs.

[Please see the “Sample Process Spec” on the course webpage, as discussed in class]

Diagrams that are highly recommended:

- IDEF0
 - PIG
- SIG
- {Class, optional}

2. Issues:

As with the first part of the course project, discuss any issues (e.g., incompleteness, inconsistency,
ambiguity, redundancy) that you/your team have encountered in further carrying out the problem analysis,
while using ontologically richer notations.
As with the first deliverable, discuss how you have resolved the issues by describing options considered,
tradeoffs analysed, and decisions made.

3. The Product Requirements Models and Specification:

- Develop business/enterprise/world/domain models, including a vision document, together with goal

model(s) and agent model(s).

- Develop a clarified definition of the software requirements and specification model(s).

- Establish the traceabilities.

Diagrams that are highly recommended:

- SIG (See if this one can be connected/related to the SIG in the Vision Doc.)
- PIG (See if this one can be connected/related to the SIG in the Vision Doc.)
- Class
- Use Case
- Sequence
- [Activity, optional]

4. A Prototype

Develop a running prototype, based on the mockup prototype which you constructed as part of the
deliverable I. Your prototype should be more fully functional, and with enhanced quality.
A user manual should accompany your prototype.

5. Justifications on Why to Choose your System.

Describe why your team believes your product will be better than, or at least as good as, the products
from other teams.