CHAPTER-TWO

REQUIREMENT GATHERING AND TECHNIQUES

08/16/2021
What is a Requirement?

 Requirements are essentially what the system, application or

business process is required to do.
 Requirements are the specific qualities, features, and objects that
the system will ultimately include.
 A common Requirement definition drawn from IEEE-STD-1220-
1998 (IEEE 1998):
 Requirement is a statement that identifies a product or process
operational, functional, or design characteristic or constraint, which is
unambiguous, testable or measurable, and necessary for product or process
acceptability (by stakeholders).
 (Users’ are not the one and only source of our requirements. It is more
convenient to use the term ‘stakeholder`, which defines all the people and
entities involved in or affected by the system.)
Cont…

 Requirements are the basis of any project, defining what

the stakeholders – users, customers, suppliers, developers,
businesses – in a new (or legacy) potential system need
from it, and also what the system must do in order to
satisfy that need.
 A statement of what the system must do
 A statement of characteristics the system must have
 Focus is on business user needs during analysis phase
 Requirements will change over time as project moves from analysis to
design to implementation
Cont…

 A requirement can be:

 Broad and high level, defining - for example - that a
process is necessary to update a particular database
 More specialized and detailed, recording the
expectation that - for example - a system call must
always be acknowledged by return.
System requirements
System requirements are the set of technological constraints that the
organization imposes on the CMS.
The following are questions you may ask: to gather system
requirements and they are more specific than the content and
publication questions
System integration: With what existing systems will the system
(CMS) have to integrate? Existing systems include those connected
to the management system, as well as those that provide information
to the publishing system.
Hardware and software: What company standards for hardware
and software apply to the system (CMS)?
For example, all your graphic artists use Macintosh computers; you
need to know that so you can make sure your collection software
works on their computers.
 Development environments: What requirement or preference
does the organization have for software development
environments? The question is not "What platform do you
prefer?”. Has the organization or any department mandated the
use of a particular platform?
 Deployment platforms: What requirement or preference does
the organization have for publication deployment platforms? The
clear answers are about Web servers, Web application servers,
databases, firewalls, and server farms. You may find this sort of
information easiest to collect. Either the organization has all its
platforms set up and prefers to continue using them, or the
organization does not and wants this choice to be part of your job.
What e-mail platforms are in use that can do bulk mailings.
 Performance: What requirements exist for scaling and performance
in the management or publication systems? How long the current
systems can go on before they begin to degrade.
 Deployment: Are there standard rollout procedures? If you are in a
large organization that has existed for more than a year or two, you
have undoubtedly rolled out an enterprise system before. If this
rollout was done well, you have a written legacy of good procedures
and guidelines. If you can find this legacy, you will save a
tremendous amount of time and effort.
 Maintenance: Are there system maintenance standards? What
standards are used to measure the quality of maintenance agreements
and support procedures? You can also save a lot of time.
Requirement Types
1.Functional Requirements
 A process the system hast to perform.
 Information the system must contain.

2.Nonfunctional Requirements or Technical Requirement

Non functional requirements are following .
• Availability: The system availability is the feature to explain
the amount of time that a system has to be accessible and
working in a proper way.
Cont…
 Backup: The system backups are the automatic regular copies of the crucial
information in a system.
 All the key pieces of information must be stored regularly, in order to have
recovery copies just in case an incident happened.
 These recovery copies must be storage in separate units, and must be
accessible by the system administrators.
 These administrators will be in charge to recover the system to the most
updated state when the system fails.
 Disaster recovery: The disaster recovery feature is the system capacity that enables
a system to reboot working fine just after a system complete fail. When an incident
happen it is important to have a clear protocol that explains what to do and how and
what to recover.
 This protocol must be accessible in any moment (even with the system down), and the
system administrators must know it. The solution proposed must recover its proper
state in any solution in less than 24h. The optimal situation should require less than
this time.
Cont…
 Fault tolerance: The fault-tolerant is a design (plan) that enables a
system to continue operation, possibly at a reduced level, rather than
failing completely, when some part of the system fails. Whole system
is not stopped due to problems either in the hardware or the software.
 Interoperability: Interoperability is the feature that describes the
facility to interchange information between different systems and the
capacity to use it. Being able to accomplish end-user applications
using different types of computer systems, operating systems, and
application software, interconnected by different types of local and
wide area networks.
 Error handling: System must handle error by displaying error
message. System should response to input error and extreme
condition.
Cont…
 Maintainability: In engineering, maintainability is the ease
with which a product can be maintained in order to isolate
defects and correct them, build up new requirements and make
easier its future maintenance, and cope with a changed
environment. Learning from the past in order to improve ability
or reliability of systems based on maintenance experience.
 Performance: The system performance is the capacity to keep
the optimal (best) behavior of the system components in any
time, any physical or logical circumstances (load, temperature,
disk occupation, response time, network concurrence etc.)i.e.
accessing information and performance activities in a short
period of time.
Cont…
 Platform compatibility: The platforms compatibility feature is the system
capability of run into different platforms without penalties in performance
neither extra configuration.
 Scalability: The scalability feature is the ability of a system to handle a
growing amount of work in a capable manner or its ability to be enlarged to
accommodate that growth. It may refer to the capability of a system to increase
total throughput under an increased load when hardware resources are added. A
system, whose performance improves after adding hardware, proportionally to
the capacity added, is said to be a scalable system.
 Security: The Security in the field of information technology is a very broad
concept. It may be defined as the ability to guarantee the integrity of the
information providing by the system, and the access control to it. The control
policies that determine which entities can see what information is a concept that
is also associated with this field.unauthorize access to the system and its data is
not allowed. System data may only changed by system’s data administrator.
Requirements Gathering
 Requirements Gathering is the collection and analysis of
those specific functions and features that must be present
in a technology solution to meet the stated business needs.
 These requirements are the basis for evaluating potential
solutions as well as for the
design/development/configuration of the chosen option.
 Gathering requirements is typically the first step in
developing a solution, be it for developing a system or a
process.
Requirement gathering steps:
1. Meet with your team to decide:
How widely your requirements-gathering effort must extend. Who
will you ask, and what questions? How quickly will you need
responses?
Whether you are staffed appropriately for the effort to come.
When and how you will get review and consent for the
requirements document you will produce.
2. Plan for dealing with roadblocks.
Establish a deadline for responding, and expect that some
groups and individuals may be less helpful than others.
3. From your discussion, prepare a requirements plan of
attack document, which describes with whom you'll talk to
gather your requirements.
Cont…
4. Organize your efforts into three types of requirements:
 Gather content requirements first, if you can. Keep
your questioning simple: What information to deliver
and how it is created or acquired.
 Gather system requirements. The list of questions for
this phase is more extensive, but m any are specific to
your particular technology environment.
 Gather publication requirements. These requirements
are centered on identifying and serving your top three
audiences.
Cont…
5. From all the information you have collected, put together the requirements
document
6. Get a review of an official consent for the requirements document to
inoculate your project against additional requirements proposed later in the
planning and implementation phase.
 In short,

1. Identify Stakeholders and Subject Matter Experts (these are the people who
you'll need to elicit requirements from).
2. Facilitate Requirements Gathering
3. Document Requirements
4. Circulate Requirements for Review and Feedback
5. Make Updates and Seek Sponsor and Stakeholder Sign-off
 When you have completed the requirements process and document, you are
ready to move on to the logical design phase.
REQUIREMENT GATHERING TECHNIQUES
1.Brainstorming - Brainstorming with a group of Stakeholders and Subject Matter
Experts can be a good starting point for generating ideas on what the solution needs
to look/act like. After all the ideas are generated, the participants prioritize the ones
they think are the best for this solution.
Five steps to making brainstorming effective:
Set up the ground rule
Set time limit
Define starting point
Shout out and write
Pick the best requirement
Five step to pick best requirement:
Flag the requirement
Count the requirement
Everyone prioritizes the requirement
Tally the score
Make list of first cut requirements
Cont…
2. Document Analysis - Review any relevant existing
documentation (i.e. users guides of existing systems, other
system related documentation, industry information,
compliance etc.) to identify requirements.
3. Focus Group -is a gathering of people who are representative
of the users or customers of a product to get feedback.
4. Interface Analysis - Interfaces for a software product can be
human or machine. Integration with external systems and
devices is just another interface. Interface analysis involves
reviewing the touch points with other external systems.
Cont…
Cont…
5. Interview - Interviewing Stakeholders, current system users
and subject matter experts is probably the most common
approach to gathering requirements.
 Close ended question : eg. how many students are there?
 Open ended question : eg.what do you think about tomorrow
class?
 Probing Questions: eg. why? Can you give example?
Cont…
6. Observation - The study of users in their natural habitats is
what observation is about.
By observing users, an analyst can identify a process flow,
awkward steps, pain points and opportunities for improvement.
Observation can be passive or active (asking questions while
observing).
Passive observation is better for getting feedback on a prototype
(to refine requirements),
Active observation is more effective at getting an understanding
of an existing business process.
Either approach can be used to uncover implicit requirements
that otherwise might go overlooked.
Cont…
7. Prototyping- Prototypes can be very effective at gathering
feedback. Low fidelity prototypes can be used as an active
listening tool.
Often, when people cannot articulate a particular need in the
abstract, they can quickly assess if a design approach would
address the need.
Prototypes are most efficiently done with quick sketches of
interfaces and storyboards. Prototypes are even being used as
the “official requirements” in some situations.
Cont…
8. Requirements Workshop - Also known as a joint application
design (JAD) session, workshops can be very effective for
gathering requirements.
 Intensive group-oriented requirements determination technique
 Brings together key users, managers and systems analysts
 Purpose: collect system requirements simultaneously from key
people
 Conducted off-site
 More structured than a brainstorming session, involved parties
collaborate to document requirements.
Cont…
Cont..
 JAD Participants:
 Session Leader: facilitates group process
 Users: active, speaking participants
 Managers: active, speaking participants
 Sponsor: high-level champion, limited participation
 Systems Analysts: should mostly listen
 Scribe: record session activities
 IS Staff: should mostly listen
 End Result
 Documentation detailing existing system
 Features of proposed system
Cont…
9. Reverse engineering: Is this a starting point or a last resort?
When a migration project does not have access to sufficient
documentation of the existing system, reverse engineering will
identify what the system does. It will not identify what the
system should do, and will not identify when the system does
the wrong thing.
10. Survey/Questionnaire - When collecting information from
many people – too many to interview with budget and time
constraints – a survey or questionnaire can be used. The survey
can force users to select from choices, rate something (“Agree
Strongly, Agree…”), or have open ended questions allowing
free-form responses.
Characteristics of Requirements
 What makes good requirement? Good requirements are
complete, correct, feasible, necessary, prioritized,
unambiguous, and verifiable.
 In other words, they accurately describe what you have
been asked to build, they are realistic, they solve one or
more needs within your organization, and they can be
demonstrably validated.
Determining Requirements
Participation by business users is essential
Three techniques help users discover their needs for the new system:
• Business Process Automation (BPA)
• Business Process Improvement (BPI)
• Business Process Reengineering (BPR)
Basic Process of Analysis
 Understand the “As-Is” system
 Identify improvement opportunities
 Develop the “To-Be” system concept
Techniques vary in amount of change
 BPA – small change
 BPI – moderate change
 BPR – significant change
Business Process Automation
 Identifying Improvements in As-Is Systems
Problem Analysis
 Ask users to identify problems and solutions
 Improvements tend to be small and incremental
 Rarely finds improvements with significant business value

Root Cause Analysis

 Challenge assumptions about why problem exists
Business Process Improvement
Duration Analysis
 Calculate time needed for each process step
 Calculate time needed for overall process
 Compare the two – a large difference indicates a
badly fragmented process
Potential solutions:
 Process integration – change the process to use fewer
people, each with broader responsibilities
 Parallelization – change the process so that individual
step are performed simultaneously
Cont…
Activity-Based Costing
 Calculate cost of each process step
 Consider both direct and indirect costs
 Identify most costly steps and focus improvement efforts
on them
Benchmarking
 Studying how other organizations perform the same
business process
 Informal benchmarking
 Common for customer-facing processes
 Interact with other business’ processes as if you are a customer
Business Process Reengineering (BPR)
Search for and implementation of radical change in
business processes to achieve breakthrough
improvements in products and services
Goals
 Reorganize complete flow of data in major sections of an
organization
 Eliminate unnecessary steps
 Combine steps
 Become more responsive to future change
Identifying Processes to Reengineer
 Key business processes
 Structured, measured set of activities designed to
produce specific output for a particular customer
or market
 Focused on customers and outcome
 Same techniques are used as for requirements
determination
Cont…
Business Process Reengineering Steps
Outcome Analysis
 Consider desirable outcomes from customers’ perspective
 Consider what the organization could enable the customer to do
Technology Analysis
 Analysts list important and interesting technologies
 Managers list important and interesting technologies
 The group identifies how each might be applied to the business and how
the business might benefit
Activity Elimination
 Identify what would happen if each organizational activity were
eliminated
 Use “force-fit” to test all possibilities
The requirements process
Three ways to do requirement process.:
Canvass (investigate) widely
One who have used originally to find out what was going on in the organization.
It should include only those people who are in a position to require something of
the system.
It also helps to ask different people for different types of requirements, based on
what they are qualified to comment on.
Catalog everything:
May be your position in the requirements process is scribe and librarian. Keep the
list of potential requirements from getting out of control and becoming confusing.
The work you do to synthesize (combine) people's input into an easy-to-read and
easy-to-understand if document is crucial. When someone does not see his/her
words in the document you produce, you should make it clear.
Get consent (approval): Formal approval of the requirements is a must .At last
you must get approval from concern organization to start your project’s work for
accomplish your goal.