0% found this document useful (0 votes)
15 views

COMP-8117-Lab 1

Windsor COMP-8117-Lab

Uploaded by

Virat Kohli
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
15 views

COMP-8117-Lab 1

Windsor COMP-8117-Lab

Uploaded by

Virat Kohli
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

Master of Applied Computing

COMP-8117
Advanced Software Engineering Topics
Dr. Aznam YACOUB – https://www.y-az.one
School of Computer Science 519-253-3000 (ext. 3781) - [email protected]
https://cs.uwindsor.ca Office Hours : Monday & Tuesday (1.00pm – 4.00pm EST)

Lab 1 : Specifications (1%)

Goal

The goal of this lab is to give you a methodology and technique to describe and define
specifications in a software project, using both informal and formal specifications.

Scenario

You’re an amazing engineer working at Detroit Robotics for 5 years. As a reward of your good
performance, the Head of Innovation Department decided to believe in you and to give you a
budget, team and resources. Your mission : create revolutionary products to enhance life of
people.

As the other members of GAFAM and NATU work on a new generation of robots to help people
with disability, you decide to try to work on a first prototype with your own vision. As an engineer,
you know that the first step is to specify your system and software. Also, Detroit Robotics asks you
to develop a simulator to show the capabilities of your robots. In this lab, we propose you to go
through all the steps to create a requirement specification. Note : you work only on the controller
of these robots (only the software part).

Training (Not evaluated)

As a reminder, we recall some definitions :

• a need is an informal expectation expressed by a customer or a user. Example : « I


would like to move from a point A to B ». Generally, the need is describe through
scenarios and use cases. It represents a problem that the customer wants to solve.
• A requirement specification (called sometimes requirements, or specifications) is an
informal or formal definition of an object under study, in a way this definition is not
ambiguous. A requirement states one functionnality/feature/quality fulfilled by the
product (software or system) to achieve one or several needs. There are various types of
specifications. Example : « My system must have 4 wheels. It can host up to 4 people – it
COMP-8117 – Lab

has for seats. Propelled by an engine, my system allows people to reach B from A in 10
seconds. »
• Software Requirement Specifications is therefore a written detailed analysis of the set of
requirements and the associated constraints. There is different kind of specifications at
different levels (from abstract to concrete level). Specifications systematically organize
requirements. There is a lot of classification, and specifications may be both formal
(mathematical) or informal (natural). Whatever the specification, its goal is to answer one
unique question : « What and Why ? ». « What is the software ? What the software does ?
What is the system ? What are the components of the system ? What are the
functionnalities of the system ? Why this software should to that ? »

Generally, we use a bottom-up or top-down approach to go through specifications, but different


other strategies exist. Moreover, the level of details depends on the project and the quality
depends on the engineer. Keep in mind that a « useful » specification is a clear specification
without ambiguity, including the external and internal work (from a functional point of view) of a
system. A specification is therefore a complete description of an object and its functionnalities.
One possible way to assess a specification : « If someone else reads my specification, is he able
to imagine exactly the quality/functionnality/feature/product I imagine in my head, in the exact
same way ? ». Keep in mind there is no « good » way of specifying.

In this training part, we’ll show you one possible approach to specify the software project
given in the scenario.

1. Clarify the need : Look at your environment around you. Pick any object and try to
answer this question : « What kind of problem this object solves ? »
a. Give a definition of this object. What is this object ? Which characteristics ?
What is the goal(s) of these objects for the final user ? Why a user would like
to use these objects ? How they’ll use it ? What kind of problems my objects
should solve, and what kind of subproblems you’ll have to solve to resolve the
entire problem ?
At this step, use cases may help you to understand the needs.
Define also what you’re developing : what is your software ? what is the boundary
between your software and your system ? How many components/software I should
develop to resolve my entier problem ?
2. Define your system :
a. Based on the your definition and the needs, try to define functions and
features. A function or a feature is a service provided by your software
responding to a need or help to fulfill the need/solve the problem.
b. Identify components of your system and organize them in two categories :
i. The external objects (generally provided by others) which will interact
with your software. We call that the Operative System.
COMP-8117 – Lab

ii. The internal objects (generally those you’ll create) which are a part of
your system. We call that the Controller and generally corresponds to
the software part.
3. For each component, determine what kind of information about them you need to :
a. Interact with them
b. And/Or Create them
c. And/Or Represent them in your software
4. For each component, define their functions (the services they can provide) to the other
components to achieve an upper level feature (a feature provided by the upper level
object).
5. Repeat Steps 2-5 (Decomposition) until you consider that your entire system is well-
defined. Why do you decide to stop the decompositiuon ?

Remember that you are SOFTWARE ENGINEER, so we have to focus on the software part in
your specifications (find the good balance when you specifiy the other aspects of the system).
Note : You’re not asked to write a complete SRS in this part.

Mandatory Part (1%)

In this mandatory part, we ask you to start writing the functional specifications of the project
asked by Detroit Robotics – not the entire SRS (follow the IEEE recommendations). We remind
you that the system is composed by two parts :
• The software which controls the robots.
• A simulator which showcases the features of your robots.

Describe the specifications of this system and software as accurate as possible in an informal way.

For this lab, there is no specific format to follow. You can use schemes if needed. Your report
should be between 10 and 20 pages. Grading will be based on the quality of writting, clarity and
completeness (« Are the specifications enough clear to imagine the objects, software and
functionnalities by reading them ? »). Remember that you are SOFTWARE ENGINEER, so we
have to focus on the software part in your specifications (find the good balance when you
specifiy the other aspects of the system).

Optional Part (1% extra credit)

Formalize your specifications using one of the following formalisms :


- Mathematical representation and structures
- UML diagrams (remember : you must not describe the implementation)
- Pseudocode (remember : you must not describe the implementation)
- SADT Method
- FAST Method

You might also like