ITEC 3010

1
ITEC 3010 Systems Analysis and Design,
I LECTURE 4 Investigating System Requirements
Prof. Peter Khaiter
2
Lecture Outline

• The Analysis Phase
• System Requirements
• Models and Modeling
• Stakeholders
• Information Gathering
• Prototypes
• Joint Application Design Sessions
• Structured Walkthrough

3
The Analysis Phase in More Detail

• Gather information (from people who will be using
  the system)
• by interviewing them
• by observing their work
• by reviewing documents and policy
  statements (e.g. at a bank)
• Define system requirements
• Functional and nonfunctional
• Prioritize requirements
• Prototype for feasibility and discovery
• Generate and evaluate alternatives
• Review recommendations with management

4
The Activities of the Analysis Phase
5
The Analysis Phase

• Gather Information
• System analyst needs to become an expert in the
  business area the system will support or should
  even actually do some or part of the task to get
  a feel for what is done (e.g., in order to
  automate order-entry, may need to know how orders
  are processed)
• Gathered information involves
• Understanding the existing system
• Identifying all current and future
  users, locations, system interfaces (inside and
  outside the organization)
• Identifying possible software package
  solutions that might be used

6
The Analysis Phase

• Prioritize Requirements
• Establish which functional and technical
  requirements are most critical
• Why? Since resources are always limited and
  you want to address the most important things
• Unless evaluation priorities, system
  requirements tend to expand as users make more
  suggestions (called scope creep)
• Prototype for Feasibility and Discovery
• If system involves new technology, the team
  may need to get experience working with it.
  Creating prototypes can be very valuable
• Prototyping helps to understand possibilities
  and limitations of the technology
• Good idea for projects where requirements are
  hard to define beforehand
• By showing prototypes to end users can get
  feedback into what is really needed
• Prototypes help users (and analysts) to
  discover requirements they might not thought
  about otherwise, i.e. think creatively

7
The Analysis Phase

• 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
• 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 the project as an option
• Possible reasons
• May have found costs were too high
• May have found benefits were lower than
  thought
• Business environment may suddenly change
  making the project less important

8
Activities of the Analysis Phase and Their Key
Questions?
9
System Requirements

• System requirements specifications that define
  the functions of the new system
• Two sets of requirements
• Functional requirements
• Nonfunctional requirements?

10
Functional requirements

• Functional requirements
• Activities system must perform (use cases)?
• Based on procedures and business functions
• Documented in analysis models
• E.g. reduce fuel costs by calculating where is
  it best to fuel up

11
Nonfunctional requirements

• Nonfunctional requirements
• Technical requirement hardware and software
• Performance requirement workload measures
• Usability requirement user interface, workflow
• Reliability requirement outages, error
  detection
• Security requirement access protection
• E.g. the new system must be run in a
  client-server environment with Windows NT, must
  have one second response time

12
Models and Modeling

• Requirements are describes by a collection of
  models
• Complex systems require more than one type of
  model
• Models represent some aspect of the system being
  built
• Process of creating models helps analyst clarify
  and refine design
• Models assist communication with system users

13
Reasons for Modeling
14
Types of Models

• Different types of models are used in information
  systems development
• Mathematical formulas that describe technical
  aspects of the system (e.g., processing rules)
• Descriptive narrative memos, reports, or lists
  that describe aspects of the system
• Graphical diagrams and schematic
  representations of some aspect of the system

15
Some Descriptive Models
16
Overview of Models Used in Analysis and Design

• Analysis activities named define system
  requirements
• Logical models
• Provide detail without regard to specific
  technology (perfect technology assumption)
• Design models
• Physical models
• Provide technical details (non-perfect technology
  assumption)
• Extend logical models

17
Models Created During Analysis
18
StakeholdersThe Source of System Requirements

• People with interest in successful system
  implementation
• Three primary groups of stakeholders
• Users (use system)?
• Clients (pay for and owe system)?
• Technical staff (ensure system operation)?
• Every type of stakeholder is identified by
  analyst - 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.

19
Stakeholders Interested in New System Development
20
Users as Stakeholders

• Horizontal users (i.e., across departments)
• Vertical users or hierarchy within a department
  (i.e., clerical staff, middle management, and
  senior executives)
• Business users perform day-to-day operations
  (transactions) provide information about daily
  operations and how system supports them
• Information users - who need current information
• Management users who need summary information
• Executive users who need strategic information
• External users may have access to system (e.g.,
  via Internet)

21
Clients and Technical Staff as Stakeholders

• Client Stakeholders
• They pay for the project so they are
  important!
• Project team must provide project status
  reviews to the clients
•  
• Technical Stakeholders
• The technical staff includes 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.

22
RMO Stakeholders
23
Techniques for Information Gathering

• Analysis phase done to understand business
  functions and develop system requirements
• Original structured approach
• Create physical and logical models of existing
  system
• Derive requirements from existing system model
• Create physical and logical models of new system
• Current approach
• Identify logical requirements for new system
• Balance the review of current business functions
  with new system requirements

24
Traditional Approach to Identifying System
Requirements
25
Current Approach to Identifying System
Requirements
26
The transition from information gathering to
model building
27
Methods of Information Gathering

• Distribute questionnaires to stakeholders
• Review existing reports, forms, and procedure
  descriptions
• Interview and discuss processes with users
• Observe and document business processes
• Build prototypes
• Conduct joint application design (JAD) sessions
• Research vendor solutions

28
Just For Fun
29
Question Topics

• What kind of information are we looking for
  during information gathering?
• We need to obtain information that will enable
  us to build the logical model of the new IS
• What Are the Business Processes? i.e.
  understanding of business functions, building a
  comprehensive list of all the business processes
  (focus on the current system).
• How is the Business Processes Performed?
  i.e., focus on how the new system should support
  the functions (visualize new and more efficient
  approaches to performing the business processes
  by new system)
• What Information is required? i.e.,
  elaboration of the second information in terms
  of defining specific information that the new
  system must provide

30
Themes for information-gathering questions
31
Review Existing Reports, Forms, and Procedure
Descriptions

• Serves two purposes
• Provides 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
• 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

32
Sample Order Form for RMO?
33
Conduct Interviews and Discussions with Users

• One of the most effective ways to understand
  business functions and rules
• Can be time consuming and resource expensive
• Team members meet with individuals or groups of
  users
• May require multiple sessions to
• Meet all users
• Understand all processing requirements
• List of detailed questions prepared
• Can involve new approaches (critical incident
  method and cognitive task analysis not
  mentioned in text)
• To be effective should be organized in three
  areas
• (1) preparing for the interview
• (2) conducting the interview
• (3) following up the interview

34
Sample Checklist to Prepare for User Interviews
35
Preparing for the Interview

• Must establish objective what do you want to
  get out of it?
• Determine 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

36
Conducting the Interview (1 of 2)

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

37
Conducting the Interview (2 of 2)

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

38
Sample Agenda for Interview
39
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)
• 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

40
A Sample Open-Items List
41
Observe and document business processes (1 of 2)

• Varies from office walkthroughs to performing
  actual tasks
• Not necessary to observe all processes at same
  level of detail
• May make users nervous, so use common sense
• Can document workflows with UML activity diagrams

42
Observe and document business processes (2 of 2)

• 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

43
Documenting

• A workflow (sequence of processing steps that
  completely handles one business transaction) is
  an effective way to capture information
• Activity diagram is a type of workflow diagram
  that describes the user activities and their
  sequential flow
• Synchronization bar symbol to control splitting
  or merging of a path on an activity diagram
• Swimlane bounded area that contains activities
  of a single agent
• Sample
• It represents a customer requesting a quote from
  a salesperson
• If it is a simple request, the salesperson can
  enter the data and create the quote
• If it is a complex request, the salesperson
  requests assistance from a technical expert to
  generate the quote
• In both cases, the computer system calculates the
  details of the quote

44
Activity Diagram Symbols
45
Activity Diagramthat Models a Workflow
46
Activity Diagram with Concurrent Paths
47
Building Prototypes

• Prototype is an initial working model of a
  larger, more complex system
• 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 prototypes that grow and
  evolve and may be used as the final, live system

48
Prototypes

• 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)
• 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)
• Built and modified rapidly with CASE
  tools

49
Distribute and Collect Questionnaires

• Have a limited and specific use
• Allow to collect information from a large number
  of stakeholders
• Can be used to get a preliminary insight on the
  information needs of the various stakeholders
• Not well suited for gathering detailed
  information
• Three groups of questions
• Quantitative (e.g., How many customers a day?)
• Closed-ended (express opinion on a predetermined
  scale On a scale of 1 to 10 rate system
  performance ) - direct respondent, simple and
  short answer is assumed easy to tabulate and
  process
• Open-ended - encourage discussion and
  elaboration, no predetermined answer

50
quantitative
Sample RMO Questionnaire
Closed-ended
open-ended
51
Conduct Joint Application Design Sessions

• Expedites investigation of system requirements
• JAD is a technique to define system requirements
  in a single session by having all the necessary
  people participating together
• Compare 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)
• Critical factor is to have all important
  stakeholders present

52
Joint Application Design 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
  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

53
Joint Application Design Facilities

• Conducted in special room
• Limit interruptions
• May be off-site
• Resources
• Overhead projector, white board, flip charts,
  work material
• Electronic support (laptops)?
• CASE tools
• Group support systems (GSS)?

54
A JAD Facility
55
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 a virtual meeting (could
  include video hookup)
• 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.)

56
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, can be effective if it is done
  carefully with the result of shortening the
  schedule

57
Research Vendor Solutions

• Many problems have been solved by other companies
• Positive contributions of vendor solutions
• Frequently provide new ideas
• May be state of the art
• Cheaper and less risky
• Danger
• May purchase solution before understanding problem

58
Useful Techniques in Vendor Research

• Technical specifications from vendor
• Demo or trial system
• References of existing clients
• On-site visits
• Printout of screens and reports

59
Validating the Requirements

• Make sure gathered information is correct (fixing
  a requirements error later in SDLC can cost
  hundreds of times more than it would have cost to
  fix it during the requirements definition!)
• In software development, each project is unique,
  so each set of system requirements should be
  reviewed and tested as much as possible
• In programming we can proof the accuracy of the
  code using tests (i.e. by executing the program
  by entering appropriate input data and observing
  the resultant output. We cannot test the
  requirements that way
• 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
• Structured walkthrough is effective means of
  implementing quality control early in project

60
Structured walkthrough

• 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
• Objectives 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!

61
Structured walkthrough

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

62
Structured walkthrough

• 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

63
Structured walkthrough

• 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
• Making required corrections
• Additional walkthrough may be needed

64
Structured Walkthrough Evaluation Form
65
Readings
Todays lecture Chapter 4 Investigating
System Requirements For next lecture Chapter 5
Modeling System Requirements
Thank you !!!