A1256655477cyGVs

1
LECTURE 4.Investigating System Requirements
2

• We have discussed the activities of the analysis
  and the design phases as well as the
• objective of each of the activities in the
  phases. This and next lectures focus on the
• required skills and associated tasks related with
  the analysis phase. The two key skills
• are
• Fact-finding for the investigation of
  system requirements (this lecture)
• Modeling of business processes based on
  the system requirements (next lecture)
• System requirements are the functions that the
  new system must perform. We can
• divide them into two categories
•  Functional requirements
• Technical requirements
• Functional and Technical Requirements
• Functional requirements are system requirements
  that describe functions or processes
• that the system must support.
• They derive directly from the
  capabilities identified in the planning phase
• Based on the procedures and business
  rules that the organization uses to run business
  (e.g. system will calculate tax amounts, report
  year-end tax deductions)

3
Technical requirements are system requirements
that describe an operating environment or
performance objective (e.g. the new system must
run in a client-server environment with Windows
NT, must have one second response time) II.
Stakeholders The source of System Requirements
Primary source of information for functional
system requirements is the various
stakeholders of the system      Stakeholders
are people who have an interest in the successful
implementation of the system     
Generally, there are three categories of
stakeholders The users who actually
use the system The clients who pay for
and own the system The technical staff
who ensure the system operates in the computing
environment of the organization (Figure 4-1
illustrates the various kinds of stakeholders)
4
FIGURE 4-1 Stakeholders with an interest in new
system development.
5
Identifying system stakeholders is one of the
most important first steps in determining systems
requirements The second task is to identify
the critical person from each stakeholder type to
be available as the business expert. 2.1 User
Stakeholders Types of system users should be
identified in two dimensions horizontally and
vertically Horizontally means across
departments Vertically means hierarchy within
a department (e.g. lower, middle and upper
managers) Types of users on the vertical
dimension and their information needs are
Business operations users are the people who use
the system daily to perform operations or
transactions (A transaction is a piece of work
or an activity done in an organization, e.g.
enter an order) Query users (a query is a
request for information) are the people who needs
current information from the system. They could
be business people or customers (may not perform
transactions, but just view specific
information!). They provide an analyst with kinds
of information that should be available daily,
weekly, monthly, and annually Management
users Managers are responsible for daily
efficient and effective functioning of the
company. They need reports, performance
statistics, want to know volumes of transactions
and requests, etc.  
6
Executive users (top executives) want
information to help with strategic issues, e.g.
compare improvements in resource utilization 2.2
Client Stakeholders They pay for the project
so they are important! Project team must
provide project status reviews to clients   2.3
Technical Stakeholders The technical staff
includes the people who establish and maintain
the computing environment of the organization
They are source of many technical requirements
provide guidance in such areas as programming
language, computer platform, equipment etc.
CASE STUDY The Stakeholders for Rocky Mountain
Outfitters To demonstrate the different types of
stakeholders, lets continue an example with the
RMOs Customer Support System. Operational
users of the new order-processing system
include Inside sales representatives (who
take orders over the telephone). They need to
looking up product information for customers and
confirming availability and shipping dates
7
Clerks (who process mail order). Need the
possibility of scanning order information into
the system to eliminate typing Warehouse
workers (who put the shipments together after the
orders are taken). Need information about orders
that have been shipped, orders to be shipped, and
back orders John and Liz Blankens, as owners,
are interested in reports of the ordered and
shipped products, as well as in watching seasonal
trends within and across products Project is
funded in part from internal cash flows.
Co-investors are interested in some financial
information Since the system involves new
technology (Internet), it requires a very heavy
involvement from technical staff Figure 4-2 is a
partial organization chart of RMO, indicating
some people who involved in the requirements
definition. It does not show all of the business
operations staff, but it does identify
departments in which these stakeholders work.
8
FIGURE 4-2 Organization chart of the RMO
indicating stakeholders for the new system.
9
III. Identifying System Requirements The
objective of the analysis phase of the SDLC is to
understand the business functions and develop the
system requirements The question that always
arises whether to study and document the
existing system, or document only the
requirements of the new system? Using
structured approach, analyst first documents the
existing system then extrapolates the
requirements of the new system from the
documentation of the existing system. The
development of system requirements was a
four-step process 1. Identify the physical
processes and activities of the existing system
2. Extract the logical business functions in each
existing physical process 3. Develop the
logical business functions to be used in the new
system 4. Develop the physical processing
requirements of the new system Figure 4-3
illustrates this approach. It requires a lot of
time and effort (a term model is used to describe
the functions)
FIGURE 4-3 The previous approach to identifying
system requirements.
10
Todays (accelerated) approach -  
 There is not the time nor the money to develop
all four sets of documentation -       The
focus is on developing of a set of logical
requirements for the new system, i.e. the
objective is to develop the logical model of the
new system immediately (see Figure
4-4) -            
FIGURE 4-4 The current approach to requirements
development.
Review of the current system is done as
much as necessary to understand the business
needs, but not to define the specific processes
The physical model of the new system is
developed as part of system design Thus,
instead of developing four sets of documentation
the project team develops only one set of
documents In either approach, a system analyst
has to balance investigation of current
procedures with needs to focus on requirements of
the new system
11

• Questions asked by the system analysts to gather
  information
• What are the current business processes and
  operations?
• Ask the users, What do you do now?
• Assess what current functions can remain and
  which should be eliminated by technology
• How should the business processes be performed?
• Ask the user How can it be done?, What steps
  are should be followed? (using the new system)
• What information is needed?
• Specific information requirements, e.g. Databases
  needed

12

• Skills Needed and Methods Used
• Understanding of users needs
• Ability to analyze and solve business problems
  effectively and efficiently
• Being able to identify and capture business rules
  that determine the system requirements
• Effective requirements are complete,
  comprehensive and correct
• An efficient analyst is one who moves the project
  ahead rapidly with minimal intrusion on users
  time and other resources
• Methods of information gathering to identify
  requirements
• Distribute questionnaires to stakeholders
• Review existing reports, forms and procedure
  descriptions
• Conduct interviews and discussion with users
• Observe business processes and workflows in real
  life (can video or audio record activities, do
  usability testing etc.)
• Build prototypes
• Conduct joint application design (JAD) sessions

13
Distribute and Collect Questionnaires Questionnair
es have a limited and specific use in information
gathering. Allow to collect information from a
large number of stakeholders Can be used to
obtain early insight on the information needs of
the various stakeholders Can be useful for
collecting demographic or quantitative
information (e.g. how many orders do you enter a
day? What is your educational background?)
Can collect information using scales (e.g. On a
scale of 1 to 7 how important is system speed?
so called closed-ended questions which direct the
person answering the question to provide direct
response to only that question, and do not invite
discussion or elaboration) Less useful for
collecting other types of qualitative information
(e.g. system usability, user-interface needs,
learn about processes, workflows or techniques)
May obtain only a very limited number of
open-ended questions which encourage discussion
and elaboration Figure 4-5 is a sample
questionnaire showing three types of questions.
The first part has closed-ended question to
determine quantitative information. The second
part consists of opinion questions (where
respondent is agree or disagree with the
statement). The final part requests an
explanation of a procedure or problem.
14
FIGURE 4-5 A sample questionnaire.
15
Review Existing Reports, Forms and Procedure
Descriptions Reviewing serves two purposes
Can help get a preliminary understanding of
processes involved in a company Can be useful
in conjunction with interviews Can be used to
develop interview questions Can be used in
interviews themselves (as visual aids and as
working documents for discussion see Figure
4-6) Review of documentation helps to identify
business rules that may not come up in the
interview Helps to discover discrepancies and
redundancies Can be extended to looking at
other types of documents like emails, memos,etc.
16
FIGURE 4-6 A sample order form for RMO.
17
Conducting Interviews and Discussions with
Users Interviewing stakeholders is one of most
effective ways to understand business functions
Can be time-consuming and resource expensive A
number of members of the project team meet with
individuals (or groups of users) List of
detailed questions is prepared and discussion
continues until all the processing requirements
are understood May involve multiple sessions
with each of the users or user groups Can
involve new approaches (critical incident method
and cognitive task analysis not mentioned in
text) To be effective should be organizes in
three areas (1) preparing for the interview
(2) conducting the interview (3) following
up the interview Figure 4-7 is a sample
checklist that summarizes the major points and is
useful for preparing and conducting an interview.
18
FIGURE 4-7 A sample checklist to prepare for user
interviews.
19

• Preparing for the Interview
• Must establish objective what do you want to
  get out of it?
• Determining users
• Could interview users with different levels of
  experience, computer expertise, bank expertise
• Good to have at least two project team members
  at the interview
• Can compare notes in order to ensure accuracy
• Prepare detailed questions
• Good to structure the questions
• Can include both open-ended (e.g. how do you do
  this function?) and closed-ended questions (how
  many times a day do you do this?)
• Last step in preparing make the interview
  arrangements (where to meet and when good to
  pick a quiet room). Each participant should know
  the objective of the meeting, have a chance to
  preview the questions or materials to be reviewed

20

• Conducting the Interview
• See text for variety of tips, like dress well,
  be polite and arrive on time!
• Limit the time of the interview (plan for about
  an our and a half if it is required more time to
  cover all questions, schedule another session).
  It is better to have several shorter interviews
  than one long marathon
• Look for error or exception conditions e.g.
  get them to describe when things go wrong (What
  if it doesnt arrive?, What if the balance is
  incorrect?)
• In critical incident method can ask to describe
  an easy case, as well as a scenario from hell
• What ifs can be explored as well as probing
  about real incidents
• The ability to think of the exceptions is very
  important it couldnt be learned from a
  textbook, but only from experience
• Probe for details
• In addition to looking for exception conditions,
  the analyst must probe to get a complete
  understanding of procedures and rules
• It is easier to get general overview than details
  on how it works and what information is used
• Take careful notes (it provides the basis for
  the next interview)
• Try to follow some logical agenda during the
  interview (it helps to prod your memory on issues
  and items that should be discussed in an
  interview). Figure 4-8 is a sample agenda for an
  interview session

21
FIGURE 4-8 A sample interview session agenda.
22
Following Up the Interview The first task is to
absorb, understand and document the information
collected from the interview Can write it up as
text and also document by constructing
diagrammatic models of business processes
Review results with others who attended the
interviews (within a day or at most two) Make a
list of questions that need further elaboration
(open-items list) Figure 4-9 is an example
open-items list from RMO. Make a list of new
questions based an areas that need more
elaboration or that are missing information
Send a thank-you note or email to the users who
participated in the interview
FIGURE 4-9 A sample open-items list.
23

• Observing Business Procedures and Workflows
• Early in the investigation activities, time
  should be scheduled to observe the business
  procedures in the organization that the new
  system will support
• Excellent way to learn
• how people do their jobs
• what problems they may have
• how to improve any systems they are using
• Can consist of
• Quick walkthrough of the office or plant
• Scheduling several hours to observe a user doing
  a real task (day in the life)
• Doing the task yourself to see what is involved
• More involved methods e.g. Videotaping the
  workplace and using methods from social science
  to analyze (not discussed in text)
• Should attempt to be unobtrusive, so you dont
  change the users behavior because you are
  watching them!
• May require consent to do this (e.g.
  videotaping)

24

• Building Prototypes
• Prototype is an initial working model of a
  larger, more complex system
• They used for many purposes
• To test feasibility
• To help identify processing requirements
• To compare different design and interface
  alternatives
• Different names to describe different uses
• Throwaway prototypes
• Discovery prototypes used in the analysis phase
  for a single discovery objective and then
  discarded once the concept has been tested
• Design prototypes used in the design phase to
  test various design alternatives
• Evolving prototypes a prototypes that grow and
  evolve and may be used as the final, live system
• Characteristics of Prototypes
• Operative a prototype should be a working
  model, with some real functionality (if not
  working, but just shows what it looks like, its
  called a mock-up-e.g. screen)
• Focused a prototype should be focused on a
  single objective (to test a specific concept or
  verify an approach)
• Quick the prototype should be built and modified
  quickly (so can validate an approach, and if it
  is wrong, fix it fast in an iterative process)

25

• Conduct Joint Application Design (JAD) Sessions
• JAD is a technique to define system
  requirements or design a system in a single
  session by having all the necessary people
  participate together
• Normal interview and discussion approach takes
  a lots of time and effort (meet with users,
  document the discussion, build models, review and
  revise them, place unresolved issues on an
  open-items list all of those on iterative
  basis!)
• May require many meetings (months)
• JAD idea is to compress all these activities
  into a shorter series of meetings with users and
  team members
• An individual JAD session may last from a day to
  a week
• Try to have all the stakeholders present to make
  decisions a critical factor in a successful JAD
  session
• All of the fact-finding, model-building, policy
  decisions and verification activities are done in
  the JAD session for a particular aspect of the
  system (or for the entire system, if it is small)

26

• JAD Participants
• JAD session leader
• Trained in group dynamics and facilitating group
  discussion
• Must ensure agenda and objectives are met
• Often system analyst appointed as leader but
  better if someone actually trained to lead group
  decision making
• May not be the expert in the business area though
• Users
• Managers are good to have at the meeting since
  important decisions have to be made
• If executives cannot be at the meeting, they at
  least should be contactable (or visit once a day)
• Technical staff
• A representative from the technical support group
  should be present (e.g. for info. regarding
  things like networks, operating environments
  etc.)
• Project team members
• System analysts
• User experts
• Assist in discussion, clarify points, build
  models and document the results
• Members of the project team are the experts on
  ensuring the objectives are met

27
Setting for JAD sessions Usually conducted in
special rooms Off-site location may be
necessary (or post a notification that
interruption are not welcome) An access
(phone etc.) is required to executives and
technical staff not presented Resources
Overhead projector Black or white
board Flip chart Adequate
workspace (Figure 4-10 shows a standard JAD
facility)  
FIGURE 4-10 A standard JAD facility.
28
Advances to Support JAD sessions Electronic
support Participants may have laptops
connected in a network That way models
and descriptions can be shown to everyone
Often a CASE tool is provided to assist in
visualization of screen and report layouts and
file design. The CASE tool provides a central
repository for all requirements developed during
the session. Group Support Systems (GSSs)
System that enables multiple people to
participate with comments at the same time, each
on his or her computer Allows for sharing of
information and collaborative work Runs on
networked computers Can include chat
features to allow posting to participants
Allows inclusion of shy participants Can
store results of discussion and decisions made
Also allows for connection with participants at
distant locations end up with a virtual
meeting (could include video hookup)
29
Other forms of electronic support
Electronic white boards Computer support
for collaborative work (CSCW) software
Would allow for participation at remote sites who
could work on documents at same time (shared
files etc.) Figure 4-11 shows a room with
electronic support (it has workstations available
to develop model diagrams and prototypes during
the JAD sessions.
FIGURE 4-11 A high-tech JAD facility.
30
Limitations of JAD   Can be risky Since
done very fast may end up with sub-optimal
decisions Details may be inappropriately
defined or missed However, JAD can be
effective if it is done carefully with the result
of shortening the schedule IV. Structured
Walkthroughs Structured walkthroughs is one of
effective techniques to implement quality control
early on the project In software development,
each project is unique, so each set of system
requirements should be reviewed and tested as
much as feasible In system analysis jargon it
is called verify and validate (VV) the system
requirements Verification means determining
that the requirements are internally consistent
(test whether the field definitions are
consistent throughout all of the subsystems of a
system) Validation means ensuring that the
requirements are complete and correctly express
users needs
31
In programming we can proof the accuracy of
the code using tests (i.e. by executing the
program on a computer by entering appropriate
input data and observing the resultant output. We
cannot test the requirements that way
Structured Walkthrough is a technique to verify
and validate requirements. It consists of
Reviewing of the findings from your
investigation Reviewing of the models based
on those findings This approach is structured
because analysts formalize the review process
into a set procedure Objective to find
errors, omissions and problems by documenting the
requirements as the analysts understand them and
then reviewing them with the project team
It is not a performance review! What and When
First item to review is documentation that was
developed as part of the analysis phase. It can
be A narrative describing a process A flow
chart showing a workflow or model diagram
documenting an entire procedure Better to
conduct several smaller walkthroughs every week
or two, than bigger ones with reviewing a number
of documentation Very important to be
scheduled as soon as documents have been created!
32
Who Two main parties involved in
walkthroughs Person (or persons) who need
their work to be reviewed Group who reviews
it It is best to have experienced analysts
involved in the walkthrough who reviews the
documentation especially for verification since
they have seen lots of problems before! For
validation good to have stakeholders involved
Could also include technical staff, or even
external users whoever is best for validating
the work How Requires the same steps as an
interview (i.e. preparation, execution and
follow-up) Preparation The analyst whose work
is to be reviewed should Get materials
ready for review Identify appropriate
participants and provide them copies of the
material Schedule a time and place and
notify all participants
33
Execution During the walkthrough analyst
presents material point by point Walks
through each diagram or section of a document
explaining each component (one effective
technique is to define a sample test case and
process it through the defined flow) The
reviewers look for inconsistencies or problems
and point them out A librarian (helper for
presenter) documents the comments, errors and
suggestions Corrections and solutions are
not made during the walkthrough If there is
a complex error may reschedule for another
meeting Reviewer should only provide focused
feedback Presenter can integrate feedback
later on when gets entire set of comments
Follow-up Consists of making required
corrections Additional walkthrough may be
needed Figure 4-12 is a sample review form used
at RMO. The materials reviewed in this case is
simply a list of business rules for community
rates (not shown are several attached sheets
including the flow charts of procedures).The
reviewers are senior managers from the user
community
34
FIGURE 4-12 A structured walkthrough evaluation
form.
35
V. Business Process Reengineering (BPR) Popular
buzzword over last ten years Due to global
competition many companies have had to completely
rethink their assumptions about how to do
business Old rule of business If it isnt
broken, dont fix it Newer way of thinking
There is always a better way to do it, lets
improve it Business process reengineering
extends this new approach even further Lets
question basic assumptions to find a completely
new way to do it that will bring dramatic and
profound improvement Objective to use IT in
novel ways to achieve dramatic improvements in
efficiencies and level of service BPR and IT
are closely aligned Many systems analysts
must also become business analysts To assist
in the process of rebuilding all internal
business procedures based on new in innovative
information technology
36
Readings
Todays lecture Chapter 4 Investigating
System Requirements For next lecture Chapter 5
Modeling System Requirements Events and
Things