part 2 analysis lec 5 Flashcards
why the analysis phasa named this
because the analysis phase
breaking the whole into parts
critical thinking skillls
is the ability to recognize strengths and weaknesses and recast an idea in an improved form
the finial deliverable of the analysis phase
is the system proposal
what is the system proposal
is pressnted to the approval committee
whats is requirments
a statment of what the system must do or what characterterstics it needs to have
businees reqerments include
increase market share
shorten order processing time
reduce customer service costs
lower inventory spoilage
IIBA
lnternational instiute of businees analysis
define function requirements
the product capalities or things that a product must do for its users
interviews
the most commonly used
there three types of interview quastaions
closed ended quastions
open ended quastions
probing Questions
open ended questions
are those that leave room for elaboration on the part of interviewee
jad
join Application development
is information gathering techniqe that allow the project team users and management to work together to identify the requirements for the system
quastionnaire
is a set of written quastions for obtaining information from individuals
what is the types of the requirments
Business requirements
User requirements
System requirements
Business requirements
o what the business needs (recall Ch 1; system request)
define the user requirments
o what the users need to do
What is a System Requirement?
QA statement of what the system must do
o “functional requirement”;
or
QA statement of characteristics the system must have (how the system should be b
Functional Requirements
Q Specify the support the system will provide
to the user in fulfilling his/her work tasks.
1 Two types:
o A process the system should perform as a part of
supporting a user task, or
© Information the system should provide as the user
performs a task
Nonfunctional Requirements
Q Behavioral properties the system must have
© Operational — physical and technical operating environment
o Performance — speed, capacity, and reliability needs
o Security —the authority
© Cultural and political — legal requirements, cultural norms
Q Nonfunctional requirements are discussed more in
Chapter 8 (Architecture Design) o But it is good to collect them early when possible
O Requirements definition document
© Text document listing requirements in outline form
(proposal)
Business requirements ave in the system request
define interviews and what is the most carsterictis
Most important and wost used fact-finding technique
QQ The systems analysts collects information from individuals
face to face
Who should be interviewed?
Managers in early project stages to get broad understanding
o Staff can provide details and specifics later.
o Political issues are important — may be necessary to interview
influential people, even if they are not too knowledgeable
Interview Structure
© Top-Down (broad to specific; most common)
o Bottom-up (specific to broad; useful for collecting
details)
Question Type
Open-ended — broad concepts; opinions
o Closed-ended — learn or confirm facts and details
o Probing — resolve confusion; follow-up
Interviewing — Practical Tips
Cl Prepare, prepare, prepare!
Q Don’t waste the interviewee’s time
Q Take notes during and after the interview
Q Dow’t be afraid to ask for clarification
Q Be aware of non-verbal cues (body language)
O Send interview summary as soon as possible.
Request confirmation and corrections
Interview as a Requirements Elicitation
Technique STRENGTHS WEAKNESSES
STRENGTHS WEAKNESSES
° Interviewee can respond freely ° Very time-consuming, and
and openly to questions. therefore costly, fact-finding
° Interviewee can be asked for approach.
more feedback. ° Success is highly dependent
° Questions can be adapted or on the systems analyst’s
reworded for each individual. human relations skills.
» Interviewee’s nonverbal ° May be impractical due to
communication can be
peace the location of interviewees.
Questionnaires
Special-purpose documents that allow the analyst
to collect information and opinions from
respondents.
o Mass produced and distributed.
o Respondents complete the questionnaire on their own time.
Q Facts are collected from a large number of people
while maintaining uniform responses.
o When dealing with a large audience, no other fact-findi
Questionnaires, con’t.
Q Fixed -format questions
© Similar to a multiple choice exam question
o Must be able to anticipate potential answers to questions
© Easy to tabulate results
QO Free-format questions
o Like an essay question — open-ended
o Response is unpredictable
o Harder to tabulat
Questionnaires — Practical Tips
Q To Develop a (Good) Questionnaire
o Determine what facts and opinions must be collected and
from whom you should get them
© Based on the needed facts and opinions, determine
whether free- or fixed-format questions will produce the
best answers. A mix of types may be ideal.
© Pretest the questions on a small sample of “typical”
respondents — not just other systems analysts
o Understand that response rates are often low.
Questionnaires as a Requirements
Elicitation Technique
STRENGTHS WEAKNESSES
° Most can be answered ° Response is often low. How to
quickly (if properly designed). motivate participation?
° Relatively inexpensive. > Tend to be inflexible.
° Allow individuals to maintain ° Body language cannot be observed.
anonymity. Cannot clarify a vague or
- JAD — Joint Application Development
An extensive, structured group process
Q GOAL: produce complete requirements definition document
Q Directly involves project sponsor, key managers, and key
users with systems analysts
O Requires a trained facilitator and a comfortable facility for
long-term, intensive group work
Expensive but valuable
why it is important Electronic JAD — e-JAD
Q e-JAD helps group overcome group dynamic issues —
dominance, status differences, fear of reprisal
JAD as a Requirements Elicitation
Technique
STRENGTHS WEAKNESSES
° Understand wultiple ° Facilitator required
perspectives at once. ° Can take valuable time from
° Have user feedback while other work
documentation is being ° Coordination required and
made group issues arise
- Observation
O Participate in or watch a person perform
activities to learn about the system
Q Use when the validity of data collected using
other methods is in question.
Q Use when the complexity of certain aspects of
the system prevents end-users from providing a
clear explanation
Observation as a Requirements
Elicitation Technique
STRENGTHS WEAKNESSES
° Data gathered may be highly ° People may perform differently
reliable. when being observed.
° Can see exactly what is being ° Work may vary in difficulty and
done. volume.
° Relatively inexpensive ° Some activities may take place a
(comer with other fact - odd times.
inding techniques). ° The tasks being observed ave
subject to various types of
interruptions.
. Document Analysis
Q Collect Facts from Existing Documentation
© Organizational chart
© Screens of current system or printout or paper forms
© Documentation of previous system studies and designs
performed by systems analysts and consultants.
QO Analyze Facts to Determine Currency
© Even outdated documentation may be useful, but
recognize what is current and what is outdated.
Document Analysis, con’t.
Q Analyze to Understand the Documentation
o Take notes, draw pictures, and use systems analysis and
design tools to model what you are learning or proposing
for the system.
Q To Employ Document Analysis Well…
© Learn as much as you can from existing documentation.
No one wants to spend time talking about things you could
have learned about from existing documentation.
Document Analysis as a Requirements
Elicitation Technique
STRENGTHS WEAKNESSES
° Easy to find nonfunctional ° Harder to see process-based
requirements functional requirements
° Easy to find information- ° Functions and characteristics
based functional of the current system may
requirements be different than what is
wanted/needed in the new
system
