Requirements

1
 Requirements Engineering
• The process of establishing the services that
– The customer requires from a system; and
– The constraints under which it operates and is developed.
• The requirements themselves are the descriptions of
– The system services; and
– Constraints that are generated during the requirements
engineering process.

2
 What is a Requirement?
• It may range from a high-level abstract statement of
a service or of a system constraint to a detailed
mathematical functional specification.
• This is inevitable as requirements may serve a dual
function
– May be the basis for a bid for a contract - therefore must
be open to interpretation;
– May be the basis for the contract itself - therefore must be
defined in detail;

3
 Types of Requirements
• User requirements
– Statements in natural language plus diagrams of the
services the system provides and its operational
constraints.
– Written for customers.
• System requirements
– A structured document setting out detailed descriptions of
the system’s functions, services and operational
constraints.
– Defines what should be implemented so may be part of a
contract between client and contractor.

4
 Types of Requirements
• Functional requirements
– Statements of services the system should provide,
– How the system should react to particular inputs;
– How the system should behave in particular situations.
• Non-functional requirements
– constraints on the services or functions offered by the
system such as timing constraints,
– constraints on the development process, standards, etc.

5
 Types of Requirements

• Domain requirements
– Requirements that come from the application
domain of the system and that reflect
characteristics of that domain.
– They may be functional or non-functional
requirements.

6
 Functional requirements
• Describe functionality or system services.
– Expected users and the type of system where the
software is used.
• Functional user requirements may be
– High-level statements of what the system should
do
– Functional system requirements should describe
the system services in detail.

7
 Example
• A library system that provides a single
interface to a number of databases of articles
in different libraries.
• Users can search for, download and print
these articles for personal study.

8
 Non-functional requirements
• These define system properties and constraints e.g.
– reliability,
– response time and storage requirements.
– Constraints are I/O device capability,
– system representations, etc.
• Non-functional requirements may be more critical
than functional requirements.

9
 Non-functional classifications
• Product requirements - system must behave in a
particular way e.g.
– execution speed, reliability, etc.
• Organisational requirements - result of
organisational policies e.g.
– process standards used, implementation requirements,
delivery requirements etc.
• External requirements - factors which are external to
the system e.g.
– interoperability requirements, legislative requirements,
etc.

10
 Non-functional requirements
examples
• Product requirement
– The user interface for LIBSYS shall be implemented as
simple HTML without frames or Java applets.
• External requirement
– The system shall not disclose any personal information
about customers apart from their name and reference
number.

11
 Seven Fact‐Finding Methods
• Background Research
• Sampling of existing documentation, forms, and
databases
• Observation of the work environment
• Questionnaires
• Interviews
• Prototyping
• Joint requirements planning (JRP)

12
 Seven Fact‐Finding Methods

• Background Research
• Sampling of existing documentation, forms, and
databases
• Observation of the work environment
• Questionnaires
• Interviews
• Prototyping
• Joint requirements planning (JRP)

13
 Observation

• Observation – a fact-finding technique wherein the

systems analyst either participates in or watches a
person perform activities to learn about the system.

• Work sampling - a fact-finding technique that

involves a large number of observations taken at
random intervals.

14
 Observation Guidelines

• Determine the who, what, where, when, why, and how of

the observation.
• Obtain permission from appropriate supervisors or
managers.
• Inform those who will be observed of the purpose of the
observation.
• Keep a low profile.
• Take notes during or immediately following the
observation.
• Review observation notes with appropriate individuals.
• Don't interrupt the individuals at work.
• Don't focus heavily on trivial activities.
• Don't make assumptions.
15
 Seven Fact‐Finding Methods

• Background Research
• Sampling of existing documentation, forms, and
databases
• Observation of the work environment
• Questionnaires
• Interviews
• Prototyping
• Joint requirements planning (JRP)

16
 Interviews

Interview - a fact-finding technique whereby the systems

analysts collect information from individuals through
face-to-face interaction.
 Types of Interviews and Questions

• Unstructured interview – an interview that is conducted

with only a general goal or subject in mind and with few, if any,
specific questions. The interviewer counts on the interviewee to
provide a framework and direct the conversation.

• Structured interview – an interview in which the

interviewer has a specific set of questions to ask of the
interviewee.

•Open-ended question – question that allows the

interviewee to respond in any way that seems appropriate.

•Closed-ended question – a question that restricts answers

to either specific choices or short, direct responses. 18
 Procedure to Conduct an Interview

1. Select Interviewees
– End users
– Learn about individual prior to the interview
2. Prepare for the Interview
– An interview guide is a checklist of specific questions
the interviewer will ask the interviewee.
3. Conduct the Interview
– Summarize the problem
– Offer an incentive for participation
– Ask the interviewee for assistance
4. Follow Up on the Interview
– Memo that summarizes the interview
19
 Interviewing Do’s and Don’ts
Do’s Don’ts
Be courteous Continuing an interview
unnecessarily.
Listen carefully Assuming an answer is finished or
leading nowhere.
Maintain control Revealing verbal and nonverbal clues.
Probe Using jargon
Observe mannerisms and nonverbal Revealing your personal biases
Communication Talking instead of listening
Be patient Assuming anything about the topic
and the interviewee
Keep interviewee at ease Tape recording -- a sign of poor
listening skills.
Maintain self-control 20
 Seven Fact‐Finding Methods
• Background Research
• Sampling of existing documentation, forms, and
databases
• Observation of the work environment
• Questionnaires
• Interviews
• Prototyping
• Joint requirements planning (JRP)

21
 Joint Requirements Planning
• Joint requirements planning (JRP)
– a process whereby highly structured
group meetings are conducted for the
purpose of analyzing problems and defining
requirements.
– JRP is a subset of a more comprehensive joint application development or
JAD technique that encompasses the entire systems development process.

• JRP Participants-
– Sponsor
– Facilitator
– Users and Managers 22
– Scribes
– IT Staff
 Steps to Plan a JRP Session

1. Selecting a location
– Away from workplace when possible
– Requires several rooms
– Equipped with tables, chairs, whiteboard, overhead projectors
– Needed computer equipment
2. Selecting the participants
– Each needs release from regular duties
3. Preparing the agenda
– Briefing documentation
– Agenda distributed before each session

23
Typical room layout for JRP session

24
 Guidelines for Conducting a JRP Session

• Do not unreasonably deviate from the agenda

• Stay on schedule
• Ensure that the scribe is able to take notes
• Avoid the use of technical jargon
• Apply conflict resolution skills
• Allow for ample breaks
• Encourage group consensus
• Encourage user and management participation without
allowing individuals to dominate the session
• Make sure that attendees abide by the established
ground rules for the session
25
 Brainstorming

• Sometimes, one of the goals of a JRP session is to

generate possible ideas to solve a problem.
– Brainstorming is a common approach that is used for
this purpose.

• Brainstorming – a technique for generating

ideas by encouraging participants to offer as
many ideas as possible in a short period of time
without any analysis until all the ideas have been
exhausted.
26
 Brainstorming Guidelines

• Isolate the appropriate people in a place that will be free

from distractions and interruptions.
• Make sure everyone understands the purpose of the
meeting.
• Appoint one person to record ideas.
• Remind everyone of brainstorming rules.
• Within a specified time period, team members call out
their ideas as quickly as they can think of them.
• After the group has run out of ideas and all ideas have
been recorded, then and only then should the ideas be
analyzed and evaluated.
• Refine, combine, and improve the ideas that were
generated earlier.
27
 Benefits of JRP

• JRP actively involves users and management in the

development project (encouraging them to take
“ownership” in the project).
• JRP reduces the amount of time required to develop
systems.
• When JRP incorporates prototyping as a means for
confirming requirements and obtaining design
approvals, the benefits of prototyping are realized

28
The PIECES Problem‐Solving Framework
P the need to improve performance
I the need to improve information (and data)
E the need to improve economics, control costs, or
increase profits
C the need to improve control or security
E the need to improve efficiency of people and
processes
S the need to improve service to customers,
suppliers, partners, employees, etc.