COIS3030
Lecture#3 The Requirements Process
1
Functional Requirements
Describe product’s actions
The product shall produce a schedule of all
roadsDescribes
upon which
an action ice
that the product is topredicted
must take be useful to it’s operatorto form
within a given parameter
Non Functional Requirements
Describe product’s qualities and attributes
The product shall be able to determine “friend or foe” in less
Properties or qualities the product must have if it is to be acceptable to its owner
then .25 seconds
The product shall provide a pleasing user experience
The product shall be able to be used by travelers in the arrivals
hall who do not speak the home language
Constraints
Constraints can be limitations on the project itself or
restrictions on the project design
Constrains are simply another type of requirements
Constrains are global issues that shape the requirements
The product must be available at the beginning of the
new tax year
The product shall operate as an iPad, iPhone, Android,
and Blackberry App
The functionality of the end product is restricted by
the constraints. The functionality is to the benefit of
its user, but it is the non-functional requirements that
“deliver” the functionality by making the product
usable and acceptable to the users.
A Case Study
✦IceBreaker
✦Predicts when and where ice will form on roads
✦ Schedules trucks to treat the roads with de-icing material
✦Will enable road authorities to more accurately predict ice
formation, schedule road treatment more precisely and thereby
make roads safer.
✦Will also reduce the amount of de-icing material needed, helping
both finances and the environment
6
Figure 2.1
This map of the Volere
Requirements Process
shows the activities
and their deliverables.
We have used a
stylized data flow
notation. Each activity
(the bubbles) and its
deliverables (named
arrows or documents)
are explained in the
text. The dotted lines
represent how this
process is used with
iterative projects.
7
8
1-Project Blastoff
• Build the foundation for the requirements discovery that is to
follow.
• Ensure that all components of a successful project are in place.
• Defines the scope of the business problem, and seeks
agreement from stakeholder.
• Lead a discussion to define scope, and relationship with
everything around it.
• Define Stakeholders.
• Confirms goals. Figure 2.2
• Estimate of costs. The context diagram is used
• Assessment of Risks. to build a consensus among
the stakeholders as to the
• Determine Viability,
scope of the work that
a.k.a go/no go needs to be improved. The
eventual product will be
used to do part of this work. 9
10
2-Trawling for Requirements
✦Understand the underlying business reason.
✦Most stakeholders talk about perceived solution, which
may not be the optimal solution.
✦Your job is to uncover the essence of the system, not
the perceived solution!
11
2-Trawling for Requirements
Learning and understanding the functionality of the work
Figure 2.3
The blastoff determines the scope of the work to be improved. The business use cases are derived from the scope. Each of the
business use cases is studied by the requirements analysts and the relevant stakeholders to discover the desired way of working.
When this is understood, the appropriate product can be determined (the PUC scenario) and requirements or user stories
written from it. 12
13
Quick and Dirty Modelling
Models, sometimes referred to as prototypes, can be
used at any time during the specification life cycle
Figure 2.4
A quick and dirty
prototype built on a
whiteboard to provide
a rapid visual
explanation of how
some of the
requirements might be
implemented, and to
clarify misunderstood
or missing
requirements.
14
Scenarios
Show functionality of a business process by breaking it
down into a series of easily recognizable steps, written
in English, so they are accessible to all stakeholders.
15
Writing Requirements
Analysts must write requirements in an unambiguous and testable
manner, and at the same time ensure that the originating
stakeholder understands and agrees with the written requirement
before it’s passed to developers
Figure 2.5
The requirements are captured in
written form to facilitate
communication between the
stakeholders, the analysts, and the
developers (and anyone else who
has an interest). By writing the
requirements carefully, the team
ensures that the correct product
is built.
16
