The University of Akron Summit College Department of Business Technology Computer Information System

1
The University of AkronSummit CollegeDepartment
of Business TechnologyComputer Information
Systems

• 2440 241 Systems Analysis and Design
• Chapter 4 Beginning the Analysis Investigating
  System Requirements
• Instructor Enoch E. Damson

2
The Analysis Phase in More Detail

• Six activities must be accomplished during the
  analysis phase of the SDLC
• Gather information
• Define system requirements
• Prioritize requirements
• Prototype for feasibility and discovery
• Generate and evaluate alternatives
• Review recommendations with management

3
1. Gather Information

• Systems analysts obtain information by
• Interviewing or watching users work
• Reviewing planning documents and policy
  statements
• Looking approaches and procedures of other
  organizations to solving similar business needs
• Key question do we have all of the information
  (and insight) needed to define what the system
  must do?

4
2. Define System Requirements

• Some of the information to be recorded describes
• Technical requirements facts about needed
  system performance or expected number of
  transactions
• Functional requirements models are created to
  help record and communicate requirements
• Two types of models are developed
• Logical model showing what the system is
  required to do without committing to any one
  technology
• Physical model showing how the system will
  actually be implemented
• Difference between the two models
• Systems analysis uses detailed logical model
• Systems design uses detailed physical model
• Key question what (in detail) do we need the
  system to do?

5
3. Prioritize Requirements

• It is important to determine which of the
  function and technical requirements are most
  crucial for the system
• Unless the analyst carefully evaluates
  priorities, system requirements tend to expand
  with more suggestions (scope creeping)
• Key question what are the most important things
  the system must do?

6
4. Prototype for Feasibility and Discovery

• Discover prototypes are built to check the
  feasibility of certain approaches to the business
  need
• If the system involves new technology, it is
  important to assess whether the new technology
  will provide the capabilities to address the
  business need
• Key questions
• Have we proven that the technology proposed can
  do what we think we need it to do?
• Have we built some prototypes to ensure the users
  fully understand the potential of what the new
  technology can do?

7
5. Generate and Evaluate Alternatives

• Lots of alternatives are open to the project team
• Each alternative needs to be described or modeled
  at a high (summary) level
• Each alternative has its own costs, benefits, and
  other characteristics that must be carefully
  measured and evaluated before a choice is made
• Key question what is the best way to create the
  system?

8
6. Review Recommendations with Management

• Making a recommendation to senior executives is a
  major management checkpoint in the project
• Every alternative must be explored
• Good project management techniques always require
  continual reassessment of the feasibility of the
  project and formal management reviews
• Key question should we continue with the design
  and implement the system we propose?

9
Business Process Reengineering (BPR) and Analysis

• A fundamental strategic approach to organizing a
  company to streamline internal processes and make
  them as efficient and effective as possible
• In a BPR project, an analyst is much more likely
  to venture beyond the initial scope of the
  project to pursue information about system
  requirements and potential improvements and
  efficiencies

10
System Requirements

• Specifications that define the functions to be
  provided by a system
• Analysts generally divide system requirements
  into two categories
• Functional requirement describes an activity or
  process that the system need to perform
• Nonfunctional requirement characteristics of
  the system and other than activities it must
  perform or support

11
System Requirements

• Types of nonfunctional requirements include
• Technical requirements describe operational
  characteristics related to the environment,
  hardware, and software of the organization
• Performance requirements describe operational
  characteristics related to measures of workload
  like response time
• Usability requirement describe operational
  characteristics related to users, such as user
  interface, documentation, etc
• Reliability requirements describe the
  dependability of a system how often a system
  exhibits behavior such as service outages and how
  it recovers from it
• Security requirements describe which users can
  perform what system functions under what
  conditions

12
Stakeholders The Source of System Requirements

• Primary source of information for system
  requirements is the various stakeholders
• Stakeholders all the people with an interest in
  the success of a new system
• Three main categories of stakeholders include
• Users those who actually use the system on a
  daily basis
• Clients those who pay for and own the system
• Technical staff people who must ensure that the
  system operates in the computing environment of
  the organization

13
1. Users as Stakeholders

• User roles should be identified in two
  dimensions
• Horizontally the analyst looks for information
  flow across business departments or functions
• Vertically information needs of clerical staff,
  middle management, and senior executives

14
Users as Stakeholders

• Users on the vertical dimension and their
  characteristics and information needs include
• Business users people using the system to
  perform transactions (a piece of work done in an
  organization) - provide information about their
  transactions
• Information users people needing current
  information about the system provide what kind
  of information should be available periodically
  in what convenient format
• Management users managers provide statistical
  and summary information
• Executive users top executives provide
  information about overall improvements in
  resource utilization
• External users customer and suppliers

15
2. Client Stakeholders

• The client may be the same group as executive
  users or a separate group like board of trustees
  or executives in a parent company
• The project team must provide periodic status
  review to the client throughout development

16
3. Technical Stakeholders

• Although not a true group, the technical staff
  affects many system requirements
• Include people who establish and maintain the
  computing environment of the organization
• They provide guidance in such areas as
  programming language, computer platforms, and
  other equipment

17
Techniques for Information Gathering

• The objective of systems analysis has not changed
  but the approach to developing system
  requirements has improved
• Analysts use an accelerated approach by balancing
  review of current business functions with new
  system requirements
• The current focus of analysis is to develop a set
  of logical system requirements for the new system
  immediately
• The current system is reviewed only when there is
  the need to understand the business needs but not
  to get caught up in old inefficient methods
• Analysts develop a logical mode of the new system
  as they gather information
• The project team creates the physical model (how
  system will be built) later as part of systems
  design
• Analysts focus on certain themes and use various
  techniques to develop the logical model of the
  system

18
Question Themes

• Three major themes to guide analysts obtain
  information are as follows
• What are the business processes? focus is on
  understanding the business functions
• Question
• What do you do?
• How is the business process performed? focus on
  how the new system should support the function
  rather than on how it does now
• Questions
• How do you do it?
• What steps do you follow?
• What information is required? focus is on
  defining specific information to be provided by
  the new system
• Questions
• What information do you use?
• What forms or reports do you use?

19
Information Gathering Methods

• Below are various proven methods of gathering
  information
• Methods could be combined to increase
  effectiveness and efficiency and provide a
  comprehensive fact-finding approach
• The methods are as follows
• Review existing reports, forms, and procedure
  descriptions
• Conduct interviews and discussions with users
• Observe and document processes
• Build prototypes
• Distribute and collect questionnaires
• Conduct joint application design (JAD) sessions
• Research vendor solutions

20
1. Review Existing Reports, Forms, and Procedure
Descriptions

• There are two sources of information for existing
  procedures and forms
• External to the organization industry-wide
  professional organizations and other companies
  sometimes through journals and magazines
• Existing business documents and procedure
  descriptions within the organization serves two
  purposes
• Help obtain preliminary understanding of the
  processes
• Forms and reports can serve as visual aids for
  the interview, and the working documents for
  discussion

21
2. Conduct Interview and Discussions with Users

• The most time-consuming and resource-expensive
  but most effective way to understand business
  functions and business rules
• To conduct effective interviews, analysts need to
  organize in three areas
• Prepare for the interview
• Conduct the interview
• Follow up the interview

22
Preparing for the Interview

• Steps required to prepare for the interview
  include
• Establishing the objective of the interview
• Determining which users should be involved in the
  interview
• Preparing detailed questions to be used in the
  interview
• Making the final interview arrangements and
  communicating those arrangements to all
  participants give specific time and location

23
Conduct the Interview

• Below are some guidelines to conduct an interview
• Dress appropriately
• Arrive on time
• Limit interview time
• Look for exception and error conditions
• Probe for details
• Take careful notes

24
Follow Up the Interview

• Analysts must
• Absorb, understand, and document (construct
  models) the information obtained
• Results of documentation must be distributed to
  participants of the interview process
• Follow up meetings must be scheduled to explain
  and verify models

25
3. Observe and Document Business Processes

• Observing it is not necessary to observe all
  processes at the same level of detail
• A quick walkthrough may provide an understanding
  of the layout of the office, computer equipment
  needs, and general work flow
• Make users comfortable by working with them or by
  observing several users at the same time
• Documenting with Activity Diagrams one
  effective way to capture information about the
  current and new business workflow is through the
  use of diagrams

26
3. Observe and Document Business Processes

• Workflow sequence of steps to process a
  business transaction
• May be simple or complex (involving several steps
  with several participants from different parts of
  the organization
• Methods used to model workflows include
• Flowcharts designed to represent control flow
  among processing steps without representing data
  flow
• Data flow diagrams capture data flow within the
  a workflow but do not represent control flows
• Activity diagrams workflow diagram that
  describes the user (system) activities and their
  sequential flow
• Ovals represent individual activities in a
  workflow
• Connecting arrows represent sequence between
  activities
• Black circles represent beginning and ending
  points of workflow
• Diamond represents a decision point
• Heavy solid bar represents a synchronization
  bar controls the splitting or uniting of
  sequential paths
• Swimlane represents an agent who performs the
  activities

27
4. Build Prototypes

• Prototype an initial working model of a larger,
  more complex entity
• Types of prototypes include
• Throwaway prototypes
• Design prototype
• Discovery prototypes discarded after the
  concept has been tested
• Evolving prototypes grow and change and may be
  used as the final live system
• Some characteristics of effective prototypes
• Operative must be a working model
• Focused must be focused on a single objective
• Quick CASE tools needed for quick builds and
  modifications

28
5. Distribute and Collect Questionnaires

• Questionnaires
• enable the project team to collect information
  from a large number of stakeholders
• are used to answer quantitative questions
• can be used to determine the users opinions
  about various aspects of the system
• Some questions are
• Closed-ended have simple definitive answer
• Open-ended require discussion and do not
  necessarily have simple, short answers

29
6. Conduct Joint Application Design Sessions

• Joint Application Design (JAD) a technique used
  to expedite the investigation of system
  requirements
• Objective to compress interview activities into
  a shorter series of JAD sessions with users and
  project team members
• During the session, all of the fact-finding,
  model-building, policy decisions, and
  verification activities are completed for a
  particular aspect of the system
• All important stakeholders must be present to
  contribute ideas and make decisions
• The stakeholders include JAD session leader,
  users, technical staff, and project team members
• Group support systems (GSS) could be used to
  enable participants post comments at the same
  time remotely

30
7. Research Vendor Solutions

• Research must be done through the use of the
  internet, company technical library, city
  library, university library, and industry related
  journals and magazines
• Research details of each solution
• Review details of information received

31
Validating the Requirements

• Various techniques can be used to validate the
  information from the users and the requirements
  that are developed from that information
• A structured walkthrough is useful for both
  validating the requirements against the users
  needs as well as verifying internal consistency
• A structured walkthrough is not a performance
  review
• The process of a structured walkthrough include
• What and When review analysis phase
  documentation
• Who the group that review and the people
  needing their work to be reviewed
• How preparation, execution, and follow-up