ITEC 3010

Lecture 4

Investigating System Requirements

1
 The Activities of the Analysis Phase

Figure 4-3 2
Systems Analysis and Design in a Changing World, 5th Edition 2
 Analysis Phase Activities

• Gather Information
– Involves gathering lots of information
– Can get information from people who will be using the
system
• By interviewing them
• By observing them
– Can get other information by reviewing documents and
policy statements (e.g. At a bank)
– Can involve the analyst actually doing some or part of
the task to get a feel for what is done
• In order to automate order-entry you may need to become an
“expert” on the task (knowing how orders are processed)
– Need to understand current and future users, locations, 3
system interfaces, possible solutions, etc.
• Define System Requirements
– Involves modelling
• Logical Model
– Any model that shows what the system is required to do
without committing to any one technology – requirements
model is logical
• Physical Model
– Any model that shows how the system will actually be
implemented
• Models are often graphical in nature
– Data flow diagrams (DFDs)
– Entity-relationship diagrams (ERDs)
• Natural Language is ambiguous

4
5
• Prioritize Requirements
– Important to establish which functional and technical
requirements are most critical
– Why? Because resources are always limited and you
want to address the most important things
– If not addressed can lead to “scope creep”, where the
scope of the project just seems to expand over time

6
• Generate and Evaluate Alternatives
– Could include considering more than one method to
develop system
– Could involve in-house development or outsourcing to
a consulting firm
– Might be able to use “off the shelf” software package
– Each alternative has costs and benefits to be considered
– Also must consider technical feasibility

7
• Review Recommendations with Management
– Usually done when all the above are completed
– Must decide if project should continue at all
– Must decide on which alternative is best (if you are
going ahead with the project)
– NOTE – at this point should include
CANCELLATION of project as an option
• May have found costs were too high
• May have found benefits were lower than thought
• Maybe the business environment suddenly changed making
the project obsolete
– Detailed documentation has been collected
• System requirements
• Proposed solution
8
9
 Requirements Specification

• Requirement specification results from Analysis

phase
• What is a requirement?
– A feature of the system or description of something the
system is capable of doing to fulfill the system’s purpose
– It addresses the purpose of the system (i.e. What it is
supposed to do) and not how it will be implemented
(However, Non-Functional requirements might require
the analyst to look closer to how it will be implemented)

10
 Functional and Technical Requirements
• Functional Requirements
– A system requirement that describes a function or process
that the system must support
– E.g. “system will calculate tax amounts, report year end tax
deductions”
• Non-Functional Requirements / Technical
Requirements
– A system requirement that describes an operating
environment or performance objective. Describe constraints
on functional requirements
– E.g. Tax amounts should be accurate, Calculate Tax amount
should be easy to use
– Security
– Safety
– Privacy
11
 Summary of Types of Requirements

PHYSICAL INTERFACES USER AND HUMAN

ENVIRONMENT FACTORS

QUALITY
ASSURANCE
Requirements FUNCTIONALITY

SECURITY

RESOURCES DATA DOCUMENTATION

12
 Types of Requirements/Questions Asked

• Physical Environment
– Where is the equipment to function?
– Is there one location or several?
– Are there any environmental restrictions such as
temperature, humidity or magnetic interference?
• Interfaces
– Is the input coming from one or more systems?
– Is the output going to one or more systems?
– Is there a prescribed way in which the data must be
formatted?
– Is there a prescribed medium that the data must use?
13
• Users and Human Factors
– Who will use the system?
– Will there be several types of users?
– What is the skill level of each type of user?
– What kind of training will be required for each type of
user?
– How easy will it be for a user to understand the system?
– How difficult will it be for a user to misuse the system?

14
• Functionality
– What will the system do?
– When will the system do it?
– How and when can the system be changed or
enhanced?
– Are there constraints on execution speed, response
time, or throughput? (Non-Functional Req. frequently
associated with FR)
• Documentation
– How much documentation is required?
– To what audience is the documentation addressed?

15
• Data
– For both input and output, what should be the format of
the data?
– How often will it be received or sent?
– How accurate must it be?
– To what degree of precision must the calculations be
made?
– How much data flows through the system?
– Must the data be retained for any period of time?
• Resources
– What materials, personnel or other resources are
required to build, use and maintain the system?
– What hardware is required?
– What software is required? (e.g.. Databases?)
16
• Resources (continued)
– What skills must the developers have?
– How much physical space will be taken up by the
system?
– Is there a prescribed timetable for development?
– Is there a limit on the amount of money to be spent on
development or on hardware and software?

17
• Security
– Must access to the system or to information be
controlled?
– How will one user’s data be isolated from other’s?
– How will user programs be isolated from other
programs and from the operating system?
– How often will the system be backed up?
– Must the backup copies be stored at a different
location?
– Should precautions be taken against fire or theft?

18
• Quality Assurance
– What are the requirements for reliability?
– How the characteristics of the system must be
demonstrated to others?
– Must the system detect and isolate faults?
– What is the prescribed mean time between failures?
– Is there a maximum time allowed for restarting the
system after a failure?
– How can the system incorporate changes to the design?
– Will maintenance merely correct errors, or will it also
include improving the system?
– What efficiency measures will apply to resource usage
and response time?
– How easy should it be to move the system from one
location to another or from one type of computer to
another? 19
 Stakeholders – The source of system
requirements
• Stakeholders: People who have an interest in the
success of the new system
– The users: who actually use the system
– The clients: who pay for and own the system
– The technical staff: who ensure the system runs

• Must identify stakeholders

• Cannot forget an important group – e.g. users!

20
 User Stakeholders
• Can identify users horizontally – i.e. Across
departments
• Can also identify users vertically – i.e. Hierarchy
within a department (e.g. lower, middle and upper
managers)
• Type of users
– Business operations users – use the system daily to
perform operations (transactions – a piece of work)
– Query users – could be business people or customers –
request info
– Management users – want reports, performance stats,
want to know volumes of transactions etc.
– Executive users – want information to help with strategic
issues, e.g. compare improvements in resource utilization
21
22
23
 Stakeholders at Rocky Mountain Outfitters

• Operational users of the new order system

– Inside sales representatives (who take orders)
– Clerks (who process order)
– Warehouse workers
• Each type of user has their own needs and
preferences
• Project funded from internal cash flow
• Since the system involves new technology (Internet)
need involvement from technical staff

24
 Identifying System Requirements

• Main Objective of Analysis Phase

– To understand the business functions and develop
system requirements
– Question of studying existing systems first or not
– Using structured approach, analyst first documents
the existing system then extrapolates the
requirements of the new system
– Approach
1. Develop current system physical models
2. Extract the current system logical models
3. Develop new system logical model
4. Develop new system physical model
25
• Faster approach
– Identify current system procedures immediately (as
much as needed, don’t necessarily define specific
processes)
– Develop requirements and models for new system (i.e.
develop logical model)
• In either approach, need to balance investigation
of old procedures with need to focus on
requirements of the new system

26
 Questions asked (overall)

• What are the current business processes and

operations?
– Ask the users, “What do you do ?”
– 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 should
be followed? (using the new system)”. How else ?
• What information is needed?
– Specific information requirements, e.g. Databases needed

27
 Skills Needed and Methods Used
• Understanding of user needs
• Ability to analyze and solve business problems
– Being able to identify and capture business rules
• Methods
– 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 28
 Review Existing Reports, Forms and
Procedure Descriptions

• Review of existing documents very useful

– Can help you get a preliminary understanding of
processes involved in a company
– Can be used in conjunction with interviews
• Can be used to develop interview questions
• Can be used in interviews themselves
– As visual aids
– Working documents for discussion
– Review of forms helps to identify business rules
– Helps to discover discrepancies and redundancies
– Can be extended to looking at other types of documents
like emails, memos etc.! 29
30
 Conducting Interviews and Discussions with
Users
• Interviewing stakeholders is one of the 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 (often does)
• Can involve new approaches (Protocol analysis,
Ethnography etc. – ITEC 4040) 31
 Prepare

Carry out

Follow up

32
 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, but not more than three
– Can compare notes
• 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?”)
33
• Last step in preparing: make the interview arrangements
(where to meet and when – good to pick a quiet room)

Conducting the Interview

• Have to limit time of interview

– Avoid “marathon” interviews
• Look for error or exception conditions – e.g. get them
to describe when things go wrong
– 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

34
• Probe for details
– In addition to looking for exception conditions, the
analyst must probe to get a complete understanding of
procedures and rules
• Take careful notes
• Recording?
• Try to follow some logical agenda during the
interview
• Semi-structured interviews often useful
(unstructured interviews can often get out of
control)

35
36
 Following Up the Interview

• Have to absorb, understand and document the

information collected from the interview
• Should write it up as text and also document it by
constructing diagrammatic models
• Review with others who attended the interviews

37
 Observing Business Procedures and
Workflows
• Early (but not too early) in the investigation
should observe the activities in the organization as
they really occur
• 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”)
– More involved methods – e.g. Videotaping the
workplace and using methods from social science to
analyze 38
• When observing
– Should attempt to be unobtrusive, so you don’t change
the users’ behaviour because you are watching them!
– May require consent to do this (e.g. videotaping
intensive care unit in a hospital)
– May require repeated or extended observation periods
to really understand what is going on
– If you are observing (and not recording) then best to
have more than one observer go along
– As text mentions, common sense and sensitivity to
needs and feelings of the users is VERY important!

39
 Observing Activities: some notes
• Decide what is to be observed
• Decide what level of detail should be looked at (how
concrete the observation should be)
• Create categories that capture key activities
• Prepare materials for observation (forms to fill in for note
taking)
• Decide when to observe and what tools you’ll take (e.g.
camera, tape recorder, or just recording on paper)
• Decide on approach to sampling – e.g. observe three one
hour periods, or by event (e.g. board meetings)
• Should be used in conjunction with other methods (e.g.
interviews)
• Could use forms to structure observations (see next slide)
40
 Organization: Company: Solid Steel Shelving
Analyst: Joe Smith
Scenario: Quality assurance
Date: 9/3/1999
Decision Maker (Actor) Observation of Information-Related
Activity

Quality Assurance Manager - Asks shop floor supervisor for the day’s
production report.

Shop floor Supervisor - Prints out the daily computerized production

report.
- Discusses recurring problems in production
runs with quality assurance (QA) manger.

Quality Assurance Manager - Reads production report.

- Compares current report with other reports from
the same week.
- Observes on-screen results of QA model. 41
 Building Prototypes

• Prototype: A preliminary working model of a

larger system
• Uses:
– To test feasibility
– To help identify processing requirements
– To compare different design and interface alternatives
• Different names
– Throwaway prototypes
– Discovery prototypes – used in analysis phase
– Design prototypes – used in design
– Evolving prototypes
• Prototypes that grow and eventually may end up becoming the
final system 42
 Prototypes as tools during Analysis

• During analysis a discovery prototype

– E.g. use of a prototype to determine screen formats and
processing sequences (then thrown away)
– Can show users or clients ideas early on to refine
requirements (also used later on in design phase a lot)
• Characteristics of Prototypes
– Operative: a prototype should be a working model, with
some real functionality
– Focused: a prototype should be focused on a single
objective
– 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)
43
 Distribute and Collect Questionnaires

• Allows to collect information from large numbers of users

• Can obtain early insight into information needs
• 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?” – closed-ended
questions which do not invite discussion
• Less useful for collecting other types of qualitative
information (e.g. system usability, user-interface needs)
44
45
• Types of Questions in Questionnaires
– Closed-ended questions (to determine
quantitative information (Part I in figure 4-5)
– Opinion questions/Qualitative (Part II in figure
4-5)
– Open-ended questions / Requests for
explanation or problems (Part III in figure 4-5)

• Note – some current use of questionnaires

– Deployment over the WWW is easy
– Can use text entry boxes for explanation or
problems
– Can automatically summarize questionnaire 46
results
 Limitations of Questionnaires

• Not well suited for learning about processes,

workflows or techniques (e.g. to answer “How do
you do this process?” - better to interview or
observe)
• Questions that encourage elaboration are called
“open-ended” – can be put in a questionnaire but if
there are too many of these, questionnaires tend not
to get returned!
• Relies in user’s memory of their use of systems
(researches show this differs from what they actually
do in many cases!)
47
 Joint Application Design (JAD) Sessions

• JAD: a technique to define requirements or design

a system in a single session by having all the
necessary people participating together
• Normal interviews take lots of time and effort
– May require many meetings (months)
• JAD idea: why not compress all these activities
into a shorter series of meetings with users and
team members
– JAD session may last a day to a week
– Try to have all the stakeholders present to make
decisions
– All fact-finding, model-building etc. done in the JAD
session 48
 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)
49
 JAD Participants - continued

• 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
50
 Setting for JAD sessions

• Usually conducted in special rooms

• Off-site location may be good
• But need access (phone etc.) to executives and
technical staff not present
• Resources
– Overhead projector
– Black or white board
– Flip chart
– Adequate work space

51
52
 Advances to Support JAD sessions

• Electronic support
– Participants may have laptops connected in network
– That way models and descriptions can be shown to
everyone (could be done using a CASE tool)
– Group Support Systems (GSSs)
• System that enables multiple people to participate with
comments at the same time, each on his or her computer
• Allow 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) 53
• 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.)

54
55
 Limitations of JAD

• Can be risky
• Since done very fast may end up with suboptimal
decisions
• Details may be inappropriately defined or missed
• However, JAD can be effective if done carefully
with the result of shortening the schedule

56
 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 isn’t broken, don’t fix it”
• Newer way of thinking:
“There is always a better way to do it, lets improve it”
• Business process reengineering approach:
“Let’s question basic assumptions to find a completely
new way to do it that will bring dramatic and profound
improvement”
57
 Business Process Reengineering (cont.)

• 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

58