Chapter Four

Gathering user requirements

Outline
 Overview of Requirements Gathering

o is also called requirements elicitation

o is a process of collecting the user needs to solve a problem or issues and to

achieve an objective
o is the first step in software development

o If the requirement gathering is not done properly/ completely, all the

subsequent phase is incomplete, no matter how best the design, until and
unless requirements are complete
o Types of requirements can be categorized as follows:
o Functional Requirements

o Non – Functional Requirements

Cont…
 Cont…

 Functional Requirements

o specifies the software functionality that the developers must build into the
product to enable users to accomplish their tasks, thereby satisfying the
business requirements
o is a state what the system must do

o is usually stated by using the “shall” statement

o Example:

o The website shall notify the administrator via email when a user
register with it
 Cont…

 Non – Functional Requirements

o are Constraints or standards that the system must have or comply with

o describe aspects of the system that are not directly related to the functional
behavior of the system
o include a broad variety of requirements that apply to many different
aspects of the system, from usability to performance
o These requirements are:

o Usability, Reliability, Robustness, Safety, Performance,

Supportability(adaptability, maintainability and internationalization ),
Portability
 Putting Together Requirements Gathering Team

o Choosing Good Subject-Matter Experts – is a person who has special

skills or knowledge on a particular job or topic.
o Choosing Good Facilitators – is to make easy or ease a process.

o Choosing Good Scribes – a scribe is a person who copies manuscripts or

a pointed instrument used for marking where something should be cut.
Fundamental Requirements Gathering Techniques

The following are fundamentals of requirement gathering techniques

oInterview

oDirect Observation

oAnalyzing Documents

oQuestionnaires
 Interview Questions

Two types of interview questions:

oopen-ended : are usually used to probe for information when you cannot
anticipate all possible responses or when you do not know the precise
question to ask
o Disadvantage: takes longer time for the questions to be answered and are
difficult to summarize

oclosed-ended: provide a range of answers from which the interviewee may

choose
o disadvantage :useful information that does not quite fit the defined answers may be
overlooked as the respondent tries to make a choice instead of providing his or her
best answer
 Direct Observation

o Is to obtain more firsthand and objective measures of employee interaction

with information systems

o Yields only a small segment of data from a possibly vast variety of data

sources.
 Analyzing Documents

o Is useful for examining system and organizational documentation to

discover more details about current systems and the organization they
support
o in analysis of documents you can find information about:
o Problems with existing systems (e.g., missing information or redundant
steps)Opportunities to meet new needs
o Opportunities to meet new needs if only certain information or information
processing were available (e.g., analysis of sales based on customer type)
o Organizational direction that can influence information system requirements
(e.g., trying to link customers and suppliers more closely to the organization)
 Cont…

o Titles and names of key individuals who have an interest in relevant existing
systems (e.g., the name of a sales manager who has led a study of buying
behavior of key customers)
o Values of the organization or individuals who can help determine priorities for
different capabilities desired by different users (e.g., maintaining market share
even if it means lower short-term profits)
o Special information-processing circumstances that occur irregularly that may
not be identified by any other requirements determination technique (e.g.,
special handling needed for a few large-volume customers who require use of
customized customer ordering procedures)
 Questionnaires

o Is preparing some questions to be answered and filled on papers so that

you would obtain the information you need in gathering information
o the challenges with interviews is that you will only get the information
that the person is consciously aware of
 Essential Use Case Modeling

o It is a diagram of all the use-cases, actors and use case-actor association

used to describe a particular system
o A use case model comprises zero or more use case diagrams, although
most have at least one diagram, and one or more use-case specifications
(often simply called use cases)
o Use case diagrams are one of the standard Unified Modeling Language
(UML) artifacts
o There are two basic types of use case models:

o Essential use case models

o System use case models

 Cont…

o Essential use case models:

o referred to as a task case model or an abstract use case model

o models a technology independent view of your behavioral

requirements
o System use case models

o also known as concrete use case models or detailed use case models

o model your analysis of your behavioral requirements, describing in

detail how users will work with your system, including references to
its user-interface aspects.
 Essential use-case modeling

o A fundamental aspect of usage-centered designs, an approach to software

development.
o Intended to capture the essence of problems through technology-free,
idealized, and abstract descriptions.
o More flexible, leaving open more options and more readily
accommodating changes in technology.
o More robust than concrete representations, simply because they are more
likely to remain valid in the face of both changing requirements and
changes in the technology of implementation.
o Ideal artifacts to capture the requirements for your system.
 Cont…

o The use case diagrams depict the core elements:

1. Use Case
2. Actor
3. System Boundary
1. Use Case(s) –
describes a sequence of actions that provide something of measurable value to
an actor
describes the typical ways (or cases) of using the system
expresses the goal of the actors involved and
describes the task that the system, with the assistance of appropriate actors, will
perform
o It is drawn as a horizontal ellipse as follows:
 Cont…
 Identifying Use Case
To identify use cases, is to identify potential services by asking your stakeholders the
following questions from the point of view of the actors:
 What are users in this role trying to accomplish?
 To fulfill this role, what do users need to be able to do?
 What are the main tasks of users in this role?
 What information do users in this role need to examine, create, or change?
 What do users in this role need to be informed of by the system?
 What do users in this role need to inform the system about?
Example:
From the point of view of the Student actor, you may discover that students
 Enroll in, attend, drop, fail, and pass seminars.
 Need a list of available seminars.
 Need to determine basic information about a seminar, such as its description and its
prerequisites.
 Obtain a copy of their transcript, their course schedules, and the fees due.
 Pay fees, pay late charges, receive reimbursements for dropped and cancelled courses, receive
grants, and receive student loans.
 Cont…

2. Actor(s) –
 is a person, organization, or external system that plays a role in one or more
interactions with your system
 in other term we can say users

 are outside the system and usually outside the control of the system.

oActors are drawn as stick figures as shown below:

 Cont…

 Identifying Actors
To help find actors in your system, you should ask yourself the following
questions:
 Who is the main customer of your system?
 Who obtains, supply, use, remove and provides information from this or to
the system?
 Who installs, operates and shut-down the system?
 What other systems interact with this system?
 Does anything happen automatically at a preset time?
 Where does the system get information?
Example:
If the person employed as the registrar at a university is also taking courses, he or she may play
the roles of both Student and Registrar. This is perfectly valid from a use case point of view.
To describe an actor, you want to give it a name that accurately reflects its role within your
model. Actor names are usually singular nouns, such as Grade Administrator, Customer, and
Payment Processor.
 Cont…

3. System Boundary (optional) –

 is used to indicate the scope of your system

 It is drawn by a rectangle around the use cases

 Anything within the box represents functionality that is in scope, and anything
outside the box is not.
oThe symbol looks the following:
 Cont…

o Use case diagram also depicts the core relationships:

o Association
o Extend
o Include
o Generalization
 Association(s)
 is a relationship between actors and use cases
 is indicated in use case diagrams by solid lines.
 exists whenever an actor is involved with an interaction described by a
use case
 exist between use cases and even between actors, although this is
typically an issue for system use case models
 Cont…

 Extend

 a relationship from the extension use case to a base use case

specifying how the behavior of extension use case can be inserted
into the behavior defined for the base use case
 It is represented as follows:

 Include

 a relationship from a base use case to inclusion use case specifying

how the behavior of the inclusion use case can be inserted into the
behavior defined for the base use case.
 It is represented as follows:
 Cont…

 Generalization
 a taxonomic relationship between a more general use case and a more
specific use case.
 It is represented as follows:
 Cont…

Generally the following picture shows an example for use case diagram
 Cont…

There are several interesting things to note about the use cases:
No time ordering is indicated between use cases.

Actors are usually involved in many use cases.

Use cases are not functions.

Use cases should be functionally cohesive.

Each use case should be temporally cohesive.

Use cases should describe something of business value.

Repetitive actions need not be expressed within a single use case.

 Domain Modeling With CRC

o Is a collection of standard index cards that have been divided into three
sections, as depicted in figure below:

o Class represents a collection of similar objects

o Responsibility is something that a class knows or does

o Collaborator is another class that a class interacts with to fulfill its

responsibilities
 Cont…

Example:
 Cont…

how do you create CRC models? Iteratively perform the following steps:
Find Classes

Find Responsibility

Define Collaborators

Move the cards around

Cont…
 Cont…

Advantages of CRC Cards

The experts do the analysis

User participation increased

Breaks down communication barriers

Simple and straightforward

Portable

Transition – ease of transition from process orientation to object-orientation

 Cont…

Disadvantages of CRC Cards

Inefficient for large systems

Limited details

Hard to get users together.

CRC cards are limited.

 Developing Supplementary Specification

o Is a RUP (Rational Unified Process) document that contains requirements

not contained directly in your use cases
o Is a container into which you place other requirements

o Often includes business rules, technical requirements, and constraints

1. business rules:
o defines or constrains one aspect of your business that is intended to
assert business structure or influence the behavior of your business
o often focuses on access control issues

o focus on the policies of your organization

 Cont…

Example: from university system perspective

•Professors are allowed to input and modify the marks of the students taking
the seminars they instruct, but not the marks of students in other seminars.
•How to convert a percentage mark (for example, 91 percent) that a student
receives in a seminar into a letter grade (for example, A-)
 Cont…

There are at least three sections of a business rules:

•Name – the name should give you a good idea about the topic of the
business rule.
• Description – the description defines the rule exactly. Although I used text
to describe this rule it is quite common to see diagrams such as flow charts or
UML activity diagrams used to describe an algorithm.
•Example (optional) – an example of the rule is presented to help clarify it.

• Source (optional) – the source of the rule is indicated so it may be verified

(it is quite common that the source of a rule is a person, often one of your
project stakeholders, or a team of people).
• Related Rules (optional) – a list of related business rules, if any, is
provided to support traceability between rules.
 Cont…

Example: The potential constraints for the university system

 Cont…

2. Constraints:
ois a restriction on the degree of freedom you have in providing a solution

oIt is effectively global requirements, such as limited development resources

or a decision by senior management that restricts the way you develop a
system
ocan be economic, political, technical, or environmental and pertain to your
project resources, schedule, target environment, or to the system itself.
 Cont…

Example:

The potential constraints for the university system

 Identifying Change Cases

o Are used to describe new potential requirements for a system or

modifications to existing requirements
o describe the potential change to your existing requirements, indicate the
likeliness of that change occurring, and indicate the potential impact of
that change.

Example:

Consider an existing University

 Ensuring Your Requirements Are correct: Requirement
Validation Techniques
 Requirements Validation Vs Requirements Verification

 Requirements Validation

• Checking a work product against higher-level work products or

authorities that frame this particular product.
• It is a heterogeneous process based on application of a great variety of
independent techniques.
• It is nothing more than checking whether the analysts have understood the
stakeholders‘ intention correctly and have not introduced any errors when
writing the specification.
• Requirements are validated by stakeholders.
 Cont…

 Requirements Verification

• Checking a work product against some standards and conditions

(specification) imposed on this type of product and the process of its
development to allow them to be used effectively to guide further work.‖
• Requirements are verified by the analysts mainly

• It is shown graphically as follows:

 Cont…

• A stakeholder is a party that has an interest in a company and can either

affect or be affected by the business.
• Requirements elicitation is the practice of researching and discovering
the requirements of a system from users, customers, and other
stakeholders.
• Negotiation is an open process for two parties to find an acceptable
solution to a complicated conflict.
 Cont…

Characteristics of Requirements Validation and Verification

 Cont…

Requirements Validation Techniques

The most common validation technique that can be performed manually is called
review. Three major types of reviews can be differentiated:
•Prototypes – A prototype allows the stakeholders to try out the requirements for the
system and experience them thereby: develop the prototype (tool support), Training of
the stakeholders, Observation of prototype usage, and Collect issues.
•Inspections – A static analysis technique that relies on visual examination of
development products to detect errors, violations of development standards, and other
problems.
•Walk-throughs – is a meeting where you gather all of your stakeholders together
and walk- through the requirements documentation, page-by-page, line-by-line, to
ensure that the document represents everyone‘s complete understanding of what is to
be accomplished in this particular project
 Cont…

 Testing Early and Often

o Testing is the process of evaluating a system or its components with the

intent to find that whether it satisfies the specified requirements or not
o is executing a system in order to identify any gaps, errors, or missing
requirements in contrary to the actual desire or requirements
 Cont…

There are mainly three reasons why we should start testing early and often:
With early and regularly tests we have a much higher chance of catching up
with our due dates.
Testing early and often saves us much effort.

It is easier to get back on track.

 Cont…

 Use Case Scenario Testing

o is simply called test documentation

o Scenario describes of how one or more people or organizations interact

with the system
o Scenario describes the steps, events, and/or actions which occur during
the interaction
o Use case testing is defined as a software testing technique, that helps
identify test cases that cover the entire system, on a transaction by
transaction basis from start to the finishing point.
 Cont…

Example 1:

Suppose in a use case for ―Login‖ functionality, to access a Gmail of a Web

Application. An actor is represented by “A” and system by “S”. The UI is
shown as follows:

The basic main test cases are:

 Cont…

Explanation of the test cases:

In the first step, the Actor enters email and password for end-to-end
scenario of login functionality.
In the next step, the system will validate the password.

Next, if the password is correct, the access will be granted.

There can be an extension of this use case. In case password is not valid
system will display a message and ask for re-try four times.
If Password, not valid four times system will ban the IP address.
 Cont…

Example 2:

Suppose in a use-case for ―Login‖ functionality of an ATM, an actor is

represented by “A” and system by “S”. Here below, the test cases and
description:
 Cont…
Advantages of Use Case Scenario Testing
•It helps to capture the functional requirements of a system.
•It is traceable.
•It can serve as the basis for the estimating, scheduling, and validating effort.
•It can evolve at each iteration from a method of capturing requirements, to
development guidelines to programmers, to a test case and finally into user
documentation.
Disadvantages of Use Case Scenario Testing
•Poor identification of structure and flow.
•Time-consuming to generate.
•Limited software tool support.
•Still poor integration with established methods.