Lecture 4/2/16
Learning Objective
• Establishing requirements
•
•
•
•
•
•
Define requirements
Requirements discovery vs requirements gathering
Classifying Requirements
Techniques for eliciting requirements
Sources of Requirements
Managing Requirements
What are requirements?
• Features of a product or service that enable its users to
achieve specific objectives
• Example:
• ATM must allow customers to withdraw cash
• Online registration system must allow the student to register for a
course
• Requirements help us to define objectives and constraints of a
system
• Example :
• A customer must be allowed to change the pin on his/her ATM
card (objective)
• The password must be between 6 and 15 characters in length
(constraint)
Requirements Discovery
•
•
•
•
Phase that takes place at the start if the project
Supports the definition of the scope of the systems
Aim is to elicit objectives from a broad group of stakeholders
Typically more chaotic than requirements gathering (which is
an on-going and ordered process as we know what we are
searching for)
Classifying Requirements
• Functional requirements specify the behaviour of the system
and the constraints on that behaviour
• Example Functional Requirements • Deposit a Check using an ATM machine
•
•
•
•
Customer inserts bank card
Systems asks for password
Customer enters password
If password is correct the system displays a menu of options from
which a customer can pick one. (If the password is incorrect the
system requests the password again)
• …….
Continued…
• Non-functional requirements specify non-behavioural
properties of the system and the constraints on those
properties
•
•
•
•
•
Usability
Reliability
Performance
Maintainability
Security
Data Gathering Techniques
• Questionnaires: Series of questions designed to
elicit specific information from us. The questions
may require different kinds of answers: some
require a simple Yes/No, others ask us to choose
from a set of pre-supplied answers.
• Interviews: Interviews involve asking someone a
set of questions. Often interviews are face-toface, but they don’t have to be (more on next
page).
Data Gathering Techniques
(continued)
• Interviews:
• Forum for talking to people
• Structured, unstructured or semi-structured
• Props, e.g. sample scenarios of use,
prototypes, can be used in interviews
• Good for exploring issues
• But are time consuming and may be
infeasible to visit everyone
Data-gathering techniques
• Focus groups and workshops: Interviews tend to
be one on one, and elicit only one person’s
perspective. It can be very revealing to get a
group of stakeholders together to discuss issues
and requirements.
• Naturalistic Observation: It can be very difficult
for humans to explain what they do or to even
describe accurately how they achieve a task.
(more on next page)
Data-gathering Techniques
(continued)
• Naturalistic observation:
• Spend time with stakeholders in their day-to-day tasks,
observing work as it happens
• Gain insights into stakeholders’ tasks
• Good for understanding the nature and
context of the tasks
• But, it requires time and commitment
from a member of the design team, and
it can result in a huge amount of data
• Ethnography is one form : entire class devoted to this.
Data-gathering
• Studying documentation: Procedures and rules are often
written down in a manual and these are a good source of data
about the steps involved in an activity and any regulations
governing a task.
Use All of the above In Combination :
Constraints of Time and Money
Sources of Authority
•
•
•
•
Sponsors
Domain Experts
Stakeholders
Users
Data Gathering Guidelines
• Focus on identifying the stakeholders
• Involve all the stakeholder groups
• Need more than on person from stakeholder group(s)
• Use a combination of data gathering techniques
For example: use observation to understand the
context, interviews to target specific user groups,
questionnaires to reach a wider population, and focus
groups to build a consensus view
Data Gathering Guidelines Cont.
• Support the data-gathering sessions with
suitable props, such as prototypes if available.
• Run a pilot session if possible to ensure that your
data-gathering session is likely to go as planned
• In an ideal world, you would understand what
you are looking for and what kinds of analysis
you want to do, and design the data-capture
exercise to collect the data you want.
• However, data gathering is expensive and often
a tightly constrained resource.
Managing Requirements
To manage requirements effectively, certain tasks must be
performed conscientiously:
•
•
•
•
•
•
Document and update requirements
Document sources
Separate requirements into distinct units
Uniquely identify each requirement
Verify requirements and document these
Prioritise requirements
Data interpretation and
analysis
• What: structure and record description of requirement
• When: Start soon after data gathering session
Data interpretation and
analysis
• Main Requirement analysis models in object-oriented systems
• Use cases diagrams:
consists of actors and user cases, discussed later
• Class diagrams
• More…
• How to develop those diagrams?
UML tools( useful in practice)
Unified Approach
• The unified approach (UA) is a conceptual model, based on
methodologies by
Booch, Rumbaugh, and Jacobson
• Tries to combine best practices, processes, and guidelines along with the
Object Management Group’s unified modeling language (UML)
UML
• UA utilizes the Unified Modeling Language which is a set of notations
and conventions
used to describe and model an application
• UML doesn’t specify a methodology or what steps to follow to
develop an application, that is the task of UA
Processes of the
Unified Approach (UA)
•
•
•
•
•
Use-case driven development
Object-oriented analysis
Object-oriented design
Incremental development and prototyping
Continuous testing
Conceptual, Logical &
Physical Models
• We begin by working with the users to produce a conceptual model
• Then we expand that into a logical model by adding all the features that
were not apparent to the users
• Finally we make all our design decisions and document them on the
physical model
Models as Communication Tools
• It is essential that you are user-driven in your modeling
• Use OO techniques to understand their business
• People skills and listening skills
• Deliverables: the documents and other products generated
at each stage
UML
• Unified modelling language is a language for specifying,
constructing, visualizing and documenting the artefacts of
software intensive systems
• Focus on a standard modelling language not a standard
process
• Promotes a development process that is use-case driven,
architecture centric, iterative and incremental
UML
UML provides several types of diagrams to represent
applications under development.
•
•
•
•
•
•
class diagram
sequence diagram
statechart diagram
component diagram
deployment diagram.
activity diagram
Activity Example – Car
Insurance
Prospective customers fill out an insurance
application, which provides information about the
customer and his or her vehicles. This information
is sent to an agent, who sends it to various
insurance companies to get quotes for insurance.
When the responses return, the agent then
determines the best policy for the type and level
of coverage desired and gives the customer a copy
of the insurance policy proposal and quote.
Complete Application
Process Application
Create Quote
Determine Best Policy
Determine Best
Coverage
Generate Policy
Proposal and Quote