Chapter 3

Requirement determination

Eng. Abdulrazak A. Dirie

20th of Mar 2023

 Introduction
• Analysis phase of SDLC.
• System request into thorough.
• Detailed requirement definition statements.
• Use case, process model and data model.
 Analysis
• Breaking a whole project into its parts with the
intent of understanding the parts’ nature,
function, and interrelationships is called analysis.
• The planning phase deliverables are the key
inputs into the analysis phase.
• The basic process of analysis involves three steps:
– Understand the existing situation (the as-is system).
– Identify improvements.
– Define requirements for the new system (the to-be
system).
 Analysis
• The analyst must have strong critical thinking sills.
• Critical thinking is the ability to recognize strengths and
weaknesses and recast an idea in an improved form.
• The final deliverable of the analysis phase is the system
proposal.
• The components of the system proposal are :
– requirements definition
– use cases
– process models
– data model
 Analysis
• Determining requirements is the single most
critical aspect of the entire SDLC.
• Failing to determine the correct requirements
is a primary cause.
• During requirements determination, the to-be
system concept is easy to change because
little work has been done yet.
 REQUIREMENTS DETERMINATION
• A requirement is simply a statement of what the
system must do or what characteristics it needs to
have.
• During a systems development project, requirements
will be created that describe:
– what the business needs (business requirements);
– what the users need to do (user requirements);
– what the software should do ( functional requirements);
– characteristics the system should have (nonfunctional
requirements);
– how the system should be built (system requirements).
 REQUIREMENTS DETERMINATION

• In the system request, there are statements that

describe the reasons for proposing the systems
development project.
• These business requirements help define the overall
goals of the system and help clarify the contributions
it will make to the organization’s success.
• Success will be measured by evaluating whether the
stated business requirements have actually been
achieved.
 REQUIREMENTS DETERMINATION
• A functional requirement relates directly to a
process the system has to perform as a part of
supporting a user task and/or information it
needs to provide as the user is performing a task.
 REQUIREMENTS DETERMINATION

• User requirements and functional requirements

defined in the analysis phase will flow into the
design phase.
• Requirements in the design phase reflect the
developer’s perspective, and they usually are
called system requirements.
• These requirements focus on describing how to
create the software product.
 REQUIREMENTS DETERMINATION
• A requirement is a statement of what the system
must do, and the focus of requirements will
change over time as the project moves from
planning to analysis to design to
implementation.
REQUIREMENTS DETERMINATION
• The International Institute of Business Analysis
(IIBA) defines functional requirements as “the
product capabilities, or things that a product
must do for its users.”
• Functional requirements begin to define how
the system will support the user in completing
a task
 REQUIREMENTS DETERMINATION
• The IIBA defines this group of requirements as “the
quality attributes, design, and implementation
constraints, and external interfaces which a product
must have.
• Performance and usability.
• These requirements will be discovered during
conversations with users in the analysis phase.
• Nonfunctional requirements are primarily used in the
design phase when decisions are made about the
user interface, the hardware and software, and the
system’s underlying architecture
The Process of Determining Requirements
• Both business and IT perspectives are needed to
determine requirements during the analysis phase.
• Systems analysts may not understand the true
business needs of the users.
• A recent study by the Standish Group found that the
lack of user involvement is the top reason for IT
project failure.
• The analyst is to identify the primary sources of
requirements, including the project sponsor, project
champion(s), all users of the system (both direct and
indirect), and possibly others known as stakeholders.
The Process of Determining Requirements
• The analyst must also consider how best to elicit the
requirements from the stakeholders.
• There are a variety of elicitation techniques that can be used
to acquire information, including interviews, questionnaires,
observation, joint application development (JAD), and document
analysis.
• The analyst works with the entire project team and the
business users to verify, change, and complete the list of
requirements and, if necessary, to prioritize the importance of
the requirements that are identified.
• During this process, use cases, process models, and data
models may be used to clarify and define the ideas for the new
system.
 The Requirements Definition Statement

• The requirements definition statement usually just called the

requirements definition is a straightforward text report that
simply lists the functional and nonfunctional requirements in
an outline format.
• The most obvious purpose of the requirements definition is
to provide a clear statement of what the new system should
do in order to achieve the system vision described in the
system request.
• A critically important purpose of the requirements definition,
however, is to define the scope of the system.
• Case study 107
 REQUIREMENTS ELICITATION TECHNIQUES
• An analyst is very much like a detective (and
business users sometimes are like elusive
suspects).
• He or she knows that there is a problem to be
solved and therefore must look for clues that
uncover the solution.
• The best analysts will thoroughly search for
requirements using a variety of techniques and
make sure that the current business processes
and the needs for the new system are well
understood before moving into design.
 Requirements Elicitation in Practice
• The analyst should recognize that important side
effects of the requirements definition process
include:
– building political support for the project
– establishing trust
– rapport between the project team
– The ultimate users of the system.
• Every contact and interaction between the analyst
and a potential business user or manager is an
opportunity to generate interest, enthusiasm, and
commitment to the project.
 Cont…
• In this section, we focus on the five most
commonly used requirements elicitation
techniques:
– interviews,
– JAD sessions,
– questionnaires,
– document analysis
– observation.
 Interviews
• The interview is the most commonly used requirements
elicitation technique. After all, it is natural—usually, if you
need to know something, you ask someone.
• In general, interviews are conducted one on one (one
interviewer and one interviewee), but sometimes, due to
time constraints, several people are interviewed at the same
time.
• There are five basic steps to the interview process:
– selecting interviewees,
– designing interview questions,
– preparing for the interview,
– conducting the interview,
– post-interview follow-up.
 Joint Application Development (JAD)
• Joint application development (or JAD as it is more commonly
known) is an information gathering technique that allows the
project team, users, and management to work together to
identify requirements for the system.
• IBM developed the JAD technique.
Define objectives
• Key stakeholders involved in JAD process:
– Execution process.
Session
– Facilitator preparation
– IT Representatives
– End user Session conduct
– Scribe
– Observer documentation
 Questionnaires
• Questionnaire is a set of written questions for obtaining
information from individuals.
• Questionnaires often are used when there is a large number of
people from whom information and opinions are needed.
• Key functions to do in questionnaires:
– Selecting Participants, population.
• Identify the population
• Use representative samples for large populations
– Designing the Questionnaire.
• Careful question selection.
• Remove ambiguities
– Administering the Questionnaire
• Working to get good response rate
• Offer an incentive (free pen, coffee,..)
– Questionnaire Follow-up.
• Send results to participants.
• Send a thank-you.
 Questionnaires
• May be paper based or electronic( eg. Web based).
• Common uses:
– Large number of people.
– Need both info and opionions.
– When designing for use outside the organization (customers, vendors).
• Typical response rates: <50% (paper); <30%(web).
 Document Analysis
• Document analysis provides info about the “as
–is” system.
• Review technical documents when available.
• Review typical user documents.
• Form.
• Reports.
• Policy manuals.
 Observation
• Users/ managers often don’t remember everything
they do.
• Checks validity of information gathered in other
ways.
• Behaviors may change when people are watched.
– Workers tend to be very careful when watched.
– Keep a low profile.
– Try not to interrupt or influence the workers.
– Be careful not to ignore periodic activities.
• Weekly ..Monthly …. Annually
Problems in Requirements determination

• Analyst may not have access to correct users.

• Requirements specifications may not be in adequate.
• Some requirements may not be known in the beginning
• Verifying and validating requirements can be difficult.
 Requirement analysis strategies
• Problem analysis
– Ask users to identify problems with the current system.
– Ask users how they would solve these questions.
– Good for improving efficiency or ease-of-use.
• Root cause analysis
– Focus is on the cause of a problem, not its solution.
– Create a prioritized list of problems.
– Try to determine their causes.
– Once the causes are known, solutions can be developed.
 Requirement analysis strategies
cont..
• Duration analysis
– Determine the time required to complete each step in business
process.
– Compare this to the total time required for the process.
– Large differences suggest problems that might be solved by:
• Integrating some steps together.
• Performing some steps simultaneously (in parallel).
• Activity based costing
– Same as duration analysis but applied to costs.
• Informal benchmarking
– Analyzes similar processes in other successful organizations.
 Requirement analysis strategies
cont..
• Outcome analysis
– What does the customer want in the end.
• Technology analysis
– Apply new technology to bussiness process & identify benefits.
• Activity elimination
– Eliminate each activity in a business process in a “force-fit” exercise.
 System proposal
• Combines all material created in planning & analysis.
• Including sections:
– Executive summary
• Provides all critical information as summary form.
• Helps busy executives determine which sections they need to read
in more detail.
– The system request
– The work plan
– The feasibility analysis
– The requirements definition.
– Current models of the system (expected to evelve)
 Summary
• Discussed in this chapter:
– Explained in detail functional and non-functional
requirements determination.
– Requirement analysis strategy.
– Requirement gathering techniques.
– Alternative requirements documentation
techniques.
– The system proposal.