ITEC 3010 Lecture 4 Investigating System Requirements

1
ITEC 3010Lecture 4Investigating System
Requirements
2
The Activities of the Analysis Phase ?
Figure 4-3
Systems Analysis and Design in a Changing World,
5th Edition
2
3
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, system interfaces, possible solutions,
  etc.

4

• 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

5
(No Transcript)
6

• 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

7

• 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

8

• 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

9
(No Transcript)
10
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 systems 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)

11
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

12
Summary of Types of Requirements
PHYSICAL ENVIRONMENT
INTERFACES
USER AND HUMAN FACTORS
QUALITY ASSURANCE
Requirements
FUNCTIONALITY
SECURITY
DOCUMENTATION
DATA
RESOURCES
13
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?

14

• 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?

15

• 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?

16

• 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?)

17

• 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?

18

• Security
• Must access to the system or to information be
  controlled?
• How will one users data be isolated from
  others?
• 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?

19

• 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?

20
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!

21
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

22
(No Transcript)
23
(No Transcript)
24
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

25
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
• Develop current system physical models
• Extract the current system logical models
• Develop new system logical model
• Develop new system physical model

26

• Faster approach
• Identify current system procedures immediately
  (as much as needed, dont 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

27
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

28
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

29
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.!

30
(No Transcript)
31
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)

32
Prepare
Carry out
Follow up
33
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?)

34

• 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

35

• 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)

36
(No Transcript)
37
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

38
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

39

• When observing
• Should attempt to be unobtrusive, so you dont
  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!

40
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 youll 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)

41
Organization Company Solid Steel
ShelvingAnalyst Joe SmithScenario Quality
assuranceDate 9/3/1999

• Decision Maker (Actor) Observation of
  Information-Related Activity
• Quality Assurance Manager - Asks
  shop floor supervisor for the days
• 
  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.
• 
  

42
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

43
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)

44
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)

45
(No Transcript)
46

• 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 results

47
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 users memory of their use of systems
  (researches show this differs from what they
  actually do in many cases!)

48
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

49
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)

50
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

51
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

52
(No Transcript)
53
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)

54

• 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.)

55
(No Transcript)
56
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

57
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 approach
• Lets question basic assumptions to find a
  completely new way to do it that will bring
  dramatic and profound improvement

58
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