CHAPTER 3: REQUIREMENTS DETERMINATION


Now in analysis phase
Analysis phase involves expanding vision described in system request into a thorough, detailed
understanding of exactly what the new system must do
The Analysis Phase











Analysis: breaking a whole into its parts to understand the parts’ nature, function, and
interrelationships
Outputs of planning phase (system request, feasibility study, and project plan) outline the
business goals for new system, define project’s scope, assess project feasibility, and provide
initial work plan
Planning phase deliverables are key inputs into analysis phase
Analysis involves 3 steps:
o Understand the existing situation (the as-is system)
o Identify improvements
o Define requirements for new system (to-be system)
Need strong critical thinking – ability to recognize strengths and weaknesses and recast an idea
in an improved form
Final deliverable for analysis phase: system proposal – document compiling detailed
requirements definition statement, use cases, process models, and data model together with
revised feasibility analysis and work plan
System proposal presented to approval committee, usually in the form of a system walk-through
Business value should be reviewed to ensure it remains positive
Primary cause of system development failure is failing to determine the correct requirements
“clear statements of requirements” was one of the top project success factors (following “user
involvement” and “executive management support”)
This is why iterative approaches of many RAD and agile methodologies are so effective – small
batches of requirements can be identified and implemented in incremental stages, allowing the
overall system to change and evolve over time
Requirements Determination

Is performed to transform the system request’s high-level statement of business requirements
into a more detailed, precise list of what the new system must do
What is a Requirement?

Requirement: statement of what the system must do or what characteristics it needs to have
o Business requirements – what the business needs
o User requirements – what the users need to do
o Functional requirements – what the software should do
o Nonfunctional requirements – characteristics the system should have
o System requirements – how the system should be built

Success will be measured by evaluating whether the stated business requirements have actually
been achieved

Concentrate on what the user actually needs to accomplish with the system in order to fulfill a
needed job or task
Functional requirements

Relates directly to a process the system should perform as part of supporting a user task and/or
info it should provide as the user is performing a task
System requirements


Requirements in the design phase that reflect the developer’s perspective
Focus on describing how to create the software product that will be produced from the project
Focus of requirements changes over time as the project moves from planning to analysis to design to
implementation
Requirements evolve from broad overall goal statements to detailed statements of business capabilities
that a system should provide to detailed technical statements of the way in which capabilities will be
implemented in the new system
Non-functional requirements


The quality attributes, design, and implementation constraints, and external interfaces which
product must have
Behavioral properties
If the methodology in use includes developing test plans during analysis, then these requirements will
be important in establishing testing benchmarks that will be needed later
The Process of Determining Requirements




Both business and IT perspectives need
First task: identify primary sources of requirements, including the project sponsor, project
champion(s), all users of the system (both direct and indirect), and possibly others
Requirements definition evolves over time as new requirements are identified and as the
project moves into later phases of SDLC
Keeping the requirements list tight and focused is key to success

When a requirement reflects a real business need, but is not within scope of current system or
current release, it should be evaluated in terms of its importance and impact on time and
budget
The Requirements Definition Statement


Requirements definition: straightforward text report that simply lists functional and nonfunctional requirements in an outline format
Can be ranked as having high, med, or low importance in the new system, or they can be labeled
with the version of system that will address the requirement


Most obvious purpose of requirements definition: to provide a clear statement of what the new
system should do in order to achieve the system vision described in the system request
Critically important purpose of requirements definition: to define scope of the system
Requirements Elicitation Techniques
Practical tips:
1. Recognize side effects of requirements definition process – building political support for project;
establishing trust and rapport between project team and ultimate users of system
2. Determine who is included in requirements def process
 Must include all key stakeholders
 Be sensitive to the fact that some people may have significant influence within the org even if
they do not rank high in formal hierarchy
3. Do everything possible to respect time commitment that you are asking participants to make –
plan and prep


Useful strategy: begin requirements gathering by interviewing senior managers to gain an
understanding of the project and get the “big picture”
Identifying improvements is most commonly done through JAD sessions because these sessions
enable the analysts, users, and other key stakeholders to work together and create a shared
understanding of the possibilities for the 2B system
Elicitation techniques:
1. Interviews
2. JAD
3. Questionnaires
4. Document analysis
5. Observation
1. Interviews
Usually conducted 1-on-1 but sometimes several people at the same time
1.1. Selecting Interviewees

Common to begin with senior mangers to get a strategic view and then move to mid-level
managers who can provide broad, overarching info about the business process and expected
role of system
1.2. Designing Interview Questions


Closed-ended questions, open-ended questions, probing questions
Closed-ended questions: require specific answer
o Enable analyst to control interview an obtain info needed






o Do not uncover why the answer is the way it is
Open-ended questions: seek a more wide-ranging response
o Gather rich info and give interviewee more control over info that is revealed during
interview
Probing questions: follow up on what has just been discussed in order for interviewer to learn
more
At initial stage of SDLC, as-is process can be unclear  interview process begins with
unstructured interviews – seek broad and roughly defined set of info
As project progresses, need very specific info  structure interviews – specific questions and
more close-ended
Put most important issues first
2 fundamental approaches to organizing interview questions:
o Top-down interview: appropriate for most interviews
 Start with broad, general issue and gradually work towards more specific ones
o Bottom-up interview
 Starts with very specific questions and moves to broad questions
 May be appropriate if lower-level staff members feel threatened or are unable
to answer high-level questions
2. Joint Application Development (JAD)





JAD: an info gathering technique that allows project team, users, and management to work
together to identify requirements for system
Claim: JAD can reduce scope creep by 50%
Is a structured process in which 10-20 users meet under the direction of a facilitator skilled in
JAD techniques
Facilitator: person who sets meeting agenda and guides the discussion, but does not join the
discussion as a participant
Facilitator must be an expert in both group process techniques and systems analysis and design
techniques


One problem with JAD: suffers from traditional problems associated with groups: sometimes
people are reluctant to challenge opinions of others (particularly their boss), a few people
dominate the discussion, not everyone participates
Solution: electronic JAD, or e-JAD uses groupware
o Participant uses special software to anonymously submit ideas, view all ideas generated
by group, and rate and rank ideas through voting
o Research suggests that e-JAD can reduce time required to run JAD sessions by 50 – 80%
2.1. Selecting Participants


Selected on basis on info they can contribute, to provide a broad mix of org levels, and to build
political support for new system
Ideally, participates should be very best people in that business unit
2.2. Designing JAD Sessions



Difference between JAD and interviewing is that all JAD sessions are structured – must be
carefully planned
Closed-ended questions seldom used as they do not spark open and frank discussion
Better to proceed top-down
2.3. Conducting the JAD Session


Participants have strong feelings about the system
Channelling these feelings so that the session moves forward in a positive direction and getting
participants to recognize and accept – but not necessarily agree on – opinions and situations
different from their own requirements significant expertise in systems analysis and design, JAD,
and interpersonal skills
Tasks of JAD facilitators:





Ensure that group stick to agenda
Help group understand the technical terms and jargon surrounding system development
process
Help participants understand specific analysis techniques used
Record group’s input on a public display area
Structure info that group provides and help group recognize key issues and important solutions
3. Questionnaires


Set of written questions for obtaining info from individuals
Often used when there is a large number of people from whom info and opinions are needed
3.1. Selecting Participants

Sample: people selected who are representative of entire group
3.2. Administering Questionnaires

Improve response rates:
o Explain why questionnaire being conducted
o Why respondent has been selected
o State date by which questionnaire to be returned
o Offer inducement to complete questionnaire
4. Document Analysis




Used to understand the as-is system
In many cases the as-is system is not well-documented
Formal system docs: forms, reports, policy manuals, org chart
Real or informal system differs from formal ones, and these differences, particular large ones,
give strong indications of what needs to be changed
o Most powerful indication that system needs to be changed is when users create their
own tools to do their job
5. Observation




Powerful to gain insight into as-is system
Enables analyst to see reality of a situation, rather than listening to others describe it in
interviews or JAD sessions
Goal: keep a low profile to not interrupt those working and influence those being observed
Understand that what the analysts observe may not be the normal day-to-day routine because
people tend to be extremely careful in their behavior when they are being watched
o Hawthorne effect
Selecting the Appropriate Techniques
Factors:






Type of info
Depth of info
Breadth of info
Integration of info
User involvement
Cost
Requirements Analysis Strategies
Problem Analysis


Asking the users and managers to identify problems and solutions
Improvements made tend to be small and incremental
Root Cause Analysis




Ideas produced by problem analysis tend to be solutions to problems
Sometimes solutions are appropriate, but many times they address a symptom of the problem,
not the true problem or root cause
Root cause analysis: focuses on the problems first rather than solutions
Key point: to challenge the obvious and dig into the problem deeply enough that the true
underlying cause(s) is revealed
Duration Analysis





Examination of amount of time it takes to perform each process in the current as-is system
Determine total time it takes, on average, to perform a set of business processes for a typical
input
Time each individual steps, total them, and compare the total for the total for the overall
process
Process integration: changing the fundamental process so that fewer people work on the input,
which often requires changing the processes and retraining staff to perform a wider range of
duties
Process parallelization: changing the process so that all individual steps performed at the same
time
Activity-based Costing


Examine cost of each major process or step
Focus on improvements for most costly processes
Informal Benchmarking


Benchmarking: studying how other orgs perform a process to learn how your org can improve
Informal benchmarking: common for customer-facing business processes
o Managers and analysts think about other org, or visit them as customers to watch how
the business process is performed
Outcome Analysis


Focuses on understanding the fundamental outcomes that provide value to customers
Encourage managers and project sponsors to pretend that they are customers and to think
carefully about what the org’s products and services enable the customers to do – and what
they could enable the customer to do
Technology Analysis


Starts by having the analysts and managers develop a list of important and interesting techs
Group systematically identifies how each and every tech could be applied to the business
process and identifies how the business would benefit
Activity Elimination

Identify how the org could eliminate each and every activity in the business process, how the
function could operate without it, and what effects are likely to occur