OBJECT ORIENTED SYSTEM

ANALYSIS & DESIGN

CHAPTER 4
GATHERING USERS REQUIREMENTS
Outline
 Chapter IV
 Putting together requirements gathering team
 Fundamental requirements gathering techniques
 Essential Use Case Modeling
 Essential User Interface Prototyping
 Domain modeling with class responsibility collaborator (CRC) cards
 Developing a supplementary Specification
 Identifying Change Cases
 Ensuring Your Requirements Are correct:
 Requirement validation Techniques

12/21/2022 [email protected]
2
GATHERING USERS REQUIREMENTS

 What is Requirements gathering ?

 It is the practice of collecting and identifying needs of
the system from end users.
 It is the process of extracting the information from
users, customers, or group of people.
 It is all about learning and understanding the needs of
users to the analysts and developers.

12/21/2022 [email protected] 3
GATHERING USERS REQUIREMENTS

 Characteristics of requirement
 Unambiguous: not open to more than one
interpretation.
 Complete: having all the necessary or appropriate
parts.
 Verifiable: it can be tested and proven to be true.
 Consistent: done in the same way over time,
especially so as to be accurate.
 Modifiable: to change somewhat the form or
qualities of; alter partially;
 Traceable: can be tracked or detected.

12/21/2022 [email protected] 4
GATHERING USERS REQUIREMENTS

 Requirements elicitation activities:

 Identifying actors
 Identifying scenarios
 Identifying use cases
 Refining use cases
 Identifying relationships among use cases
 Identifying nonfunctional requirements

12/21/2022 [email protected] 5
GATHERING USERS REQUIREMENTS

 Types of Requirements
 Functional requirements
 Non-functional requirements

12/21/2022 [email protected] 6
GATHERING USERS REQUIREMENTS

 Functional requirements
 An action that a system must be able to do
or perform.
 An important category of the real
requirements.
 Sometimes called behavioral or operational
requirements .
 They specifies about:
 The inputs to the system,
 The outputs from the system,
 Behavioral relationships between them.
12/21/2022 [email protected] 7
GATHERING USERS REQUIREMENTS

 Non-functional requirements
 It define system behavior, features, and
general characteristics of the system such as
:
 Reliability
 Robustness,
 Automatic, UI ………

 It also defines system constraints such as:

 I/O device capability
 System representations, etc.

12/21/2022 [email protected] 8
GATHERING USERS REQUIREMENTS

 The degree of Non-functional Requirements

 Usability: How much the system is practical to the end
users.
 Reliability: Robustness, Safety
 Performance:
 Response time,
 Scalability ,
 Throughput,
 Availability
 Supportability: Adaptability, Maintainability

12/21/2022 [email protected] 9
GATHERING USERS REQUIREMENTS

 Techniques for Requirements

gathering
 Interviews
 Questionnaires
 Task Analysis
 Group Work
 Brainstorming
 Joint Application Design (JAD)
 Observation
 Prototyping

12/21/2022 [email protected] 10
GATHERING USERS REQUIREMENTS

 Interviews
 Are probably the most traditional and commonly used
technique for requirements elicitation.
 Interviews provide an efficient way to collect large
amounts of data quickly.
 The results of interviews, such as the usefulness of the
information gathered, can vary significantly depending
on the skill of the interviewer

12/21/2022 [email protected] 11
GATHERING USERS REQUIREMENTS

 Questionnaires
 Are mainly used during the early stages of requirements
elicitation and may consist of open and/or closed questions.
 For them to be effective, the terms, concepts, and
boundaries of the domain must be well established and
understood
 Questions must be focused to avoid gathering large amounts
of redundant and irrelevant information.
 They provide an efficient way to collect information from
multiple stakeholders quickly,

12/21/2022 [email protected] 12
GATHERING USERS REQUIREMENTS

 Task Analysis
 Employs a top-down approach where high-level tasks are
decomposed into subtasks and eventually detailed
sequences until all actions and events are described.
 The primary objectives of this technique is to construct a
hierarchy of the tasks performed by the users and the
system,
 Provides information on the interactions of both the user and
the system with respect to the tasks as well as a contextual
description of the activities that take place.

12/21/2022 [email protected] 13
GATHERING USERS REQUIREMENTS

 Group Work
 Such as collaborative meetings is a very common and often
default technique for requirements elicitation.
 Groups are particularly effective because they involve and
commit the stakeholders directly and promote cooperation.
 These types of sessions can be difficult to organize due to
the number of different stakeholders that may be involved in
the project.
 Key factors in the success of group work are the makeup of
participants and the cohesion within the group.
 Stakeholders must feel comfortable and confident in
speaking openly and honestly,

12/21/2022 [email protected] 14
GATHERING USERS REQUIREMENTS

 Brainstorming
 A group problem solving technique in which members
spontaneously share ideas and solutions.
 It is used to invent a new way to solve a problem.
 Involves both idea generation and idea reduction.
 The most creative and innovative ideas will be found.
 It encourages free thinking and expression, and
 Allows to discover new and innovative solutions for
existing problems.

12/21/2022 [email protected] 15
GATHERING USERS REQUIREMENTS

 Joint Application Design (JAD)

 It is a kind of more structured and intensive
brainstorming approach.
 Involves all the available stakeholders
investigating through general discussion both
the problems to be solved, and the available
solutions
 With all parties represented, decisions can be
made rapidly and issues resolved quickly.

12/21/2022 [email protected] 16
GATHERING USERS REQUIREMENTS

 The 6 “P”s of Joint Application Design (JAD)

1. Purpose - Why do we do things? (Goals, needs,
motivation)
2. Participants - Who is involved? (People, roles,
responsibilities)
3. Principles - How do we function? (Guidelines, working
agreements, ground rules)
4. Products - What do we create? (Deliverables,
decisions, plans, next steps)
5. Place - Where is it located? (Venue, logistics)
6. Process - When do we do what? (Activities, sequence)

12/21/2022 [email protected] 17
GATHERING USERS REQUIREMENTS

 Observation
 The analyst observes the actual execution of existing
processes by the users ,without direct interference.
 This technique is often used in a combination with
others such as interviews and task analysis.

12/21/2022 [email protected] 18
GATHERING USERS REQUIREMENTS

 Prototyping
 Is a mock-up or partial implementation of a
software system.
 Is the process of quickly putting together a
working model (a prototype).
 Need
 Helps to developers, users, and customers to
better understand on system requirements
 Helps to clarify and complete requirements
 It is the Simplified version of the proposed system
 Used to test the feasibility without building the
whole system.

12/21/2022 [email protected] 19
GATHERING USERS REQUIREMENTS

 Prototyping
 Prototypes can take many forms:
 Paper prototypes
 Prototype on index card
 Storyboard/ Scenarios
 Screen mock-ups
 Models (executables)

12/21/2022 [email protected] 20
GATHERING USERS REQUIREMENTS

 From where Requirements Elicitated

 Greenfield Engineering
 Starts from scratch, no prior system exists
 Triggered by user (end user or client) needs
Eg. Develop a game from scratch

 Re-engineering
 Re-design and/or re-implementation of an existing system using newer technology
 Triggered by technology enabler
Eg. Reengineer an existing game

 Interface Engineering
 Provision of existing services in a new environment
 Triggered by technology enabler or new market needs
Eg. game developed for offline use, now we want an online multiplayer-version

12/21/2022 [email protected] 21
GATHERING USERS REQUIREMENTS

 Requirements Documentation
 It is written text or illustration that accompanies
computer software or is embedded in the source
code.
 The documentation either explains how the software
operates or how to use it, and may mean different
things to people in different roles.
 Requirements documentation depending on:
 The type of the system being developed
 The level of detail included
 Organizational practice
 Budget
 Schedule

12/21/2022 [email protected] 22
GATHERING USERS REQUIREMENTS

 Problems of elicitation
 Not having good skills to collect information and can’t
understand the group problem.
 Not well defined the actual Problem, Ignoring or omitting
the actual problem.
 Lack of analyst knowledge with the problem.
 Lack of user’s knowledge also creates problems for
elicitation.

12/21/2022 [email protected] 23
GATHERING USERS REQUIREMENTS

 Modeling with class responsibility collaborator(CRC) cards

 It provides a simple yet effective technique for working with
your users to determine their needs.
 A CRC model is a collection CRC standard index cards that
have been divided into three sections: class, responsibilities
and collaborator
 A class is any person, place, thing, event, concept, screen or report.
 The responsibilities of a class are the things that it knows and does, its attributes
and methods.
 The collaborators of a class are the other classes that it works with to fulfill its
responsibilities.

12/21/2022 [email protected] 24
GATHERING USERS REQUIREMENTS

 Requirements checking (quality criteria)

 Validity:
 Does the system provide the functions which best support the
customer’s needs?
 Consistency:
 Are there any requirements conflicts?
 The requirements must be compatible with each other.
 Completeness:
 Are all functions required by the customer included?
 Realism:
 Can the requirements be implemented given available budget and
technology
 Adequacy:
 The requirements must address the actual needs of the system.
 Unambiguity:
 Every requirement must be described in a way that precludes
different interpretations.

12/21/2022 [email protected] 25
GATHERING USERS REQUIREMENTS

 Requirements checking (quality criteria)

 Comprehensibility:
 The requirements must be understandable by the
stakeholders.
 Verifiability:
 Can the requirements be checked?
 Importance:
 Each requirement must indicate how essential it is for the
success of the project.
 Feasibility:
 All requirements can be implemented with the available
technology, human resources and budget.
 Traceability:
 The context in which a requirement was created should be
easy to retrieve.

12/21/2022 [email protected] 26
GATHERING USERS REQUIREMENTS

 Requirements validation
 It is concerned with finding problems with the
requirements
 Validation is performed by:
 Relevant stakeholders,
 Other requirement sources
 External reviewers, if necessary.
 Requirements error costs are high so validation is very
important

12/21/2022 [email protected] 27
GATHERING USERS REQUIREMENTS

 The six principles of requirements validation

1. Involving the Right Stakeholders
 Ensure that relevant company-internal as well as relevant
external stakeholders participate in validation.
2. Defect Detection vs. Defect Correction:
 Separate defect detection from the correction of the detected
defects.
3. Making multiple Independent Views:
 Whenever possible, try to obtain independent views that can be
integrated during requirements validation in order to detect
defects more reliably.

12/21/2022 [email protected] 28
GATHERING USERS REQUIREMENTS

 The six principles of requirements validation

4. Use of Appropriate Documentation Formats
 Consider the documentation format that fit with the organization
standard
5. Creation of development artefacts/samples during
validation
 To support defect detection by creating artefacts, If your
validation approach generates poor results

6. Repeated Validation ?
 Requirements change quickly during requirements elicitation
 Inconsistencies easily added with each change
 Tool support is needed

12/21/2022 [email protected] 29
GATHERING USERS REQUIREMENTS

 Requirements validation techniques

 Requirements reviews: Systematic manual analysis of
the requirements
 Prototyping: Using an executable model of the system
to check requirements.
 Test-case generation :Developing tests for
requirements to check testability
 Automated consistency analysis: Checking the
consistency of a structured requirements description
 Inspection: an organized examination process of the
requirements.
 Walkthrough: it does not have formally defined
procedure, simply it is about
 Checking early whether an idea is feasible or not.
 Obtaining the opinion and suggestions of other people.
 Checking the approval of others and reaching agreement.
12/21/2022 [email protected] 30