Chapter 7 : Analysis: Detrmining System Requirements

Objectives
  1. Describe options for designing and conducting interviews and develop a plan for conducting interview to detrmine system requirements.
  2. Design, distribute, and analyze questionnaires to determine system requirements.
  3. Explain the advantages and pitfalls of observing workers and analyzing business documents to determine system requirements.
  4. Explain how computing can provide support for requirements determination.
  5. Participate in and help plan a Joint Application Design session.
  6. Use prototyping during requirements determination.
  7. Select the appropriate methods to elicit system requirements.


Chapter Overview

The purpose of this chapter is to acquaint students with some of the many methods systems analysts use to collect information about information system requirements. The chapter begins with a discussion of the more traditional requirements gathering techniques, such as interviews, questionnaires, and obtaining information from organizational documents. The latter part of the chapter is devoted to more recently developed techniques and tools, such as Joint Application Design (JAD), group support systems, prototyping, and CASE tools. This chapter concludes with a discussion of business process reengineering. From their study of this chapter, students should take with them an appreciation of the different types of requirements information analysts collect and the different methods they can use to collect these requirements. However, reading about and discussing how analysts collect requirements is no substitute for direct hands-on experience with the techniques. Most of the classroom suggestions listed below involve some type of hands-on experience for students. You probably won't have time to do all of these in class, but even one or two of these exercises will give students a much better insight into the requirements collection process.

  1. Introduction.

  2. Performing Requirements Determination.

  3. Traditional Methods for Determining Requirements.

  4. Modern Methods for Determining Requirements.

  5. Radical Methods for Determining Requirements.


Introduction.
In this chapter, you will learn about the begining subphase of analysis-determining system requirement. Techniques used in requirements determination have evolved over time to become more structured and current methods increasingly rely on the computer for support. We will study the more traditional requirements determination methods including: interviewing, using questionnairs, observing users in their work environment, and collecting procedures and other written documents. The first of these methodsis Joint Application Design (JAD). Next, you will read about how analysts rely more and more on information systems to help them perform analysis.

Analysis is divided into :
  1. Requirements Determination
  2. Requirements Structuring.
    • Process Modeling. (Chapter 8)
    • Logic modeling. (Chapter 9)
    • Conceptual Data Modeling. (Chapter 10)
  3. Alternative Generation & Selection. (Chapter 11)



Return

Performing Requirements Determination:
You gather information on what system should do from many possible source: from users of the current system, from observing users, and from documentations and procedure. (Sherlock Holmes) Enjoy solving puzzles:
  • Some characterisics for a good systems analyst:
    • Impertinence: question everything, Are transactions processed the same way ? ...
    • Impartiality: your role is to find the best solution to a business problem or oportunity.
    • Relax constraints: assume anything is possible and eliminate the infeasible.
    • Attention to details: Every fact must fit with every other facts.
    • Reframing: analysis is, in part, a creative process. You must challenge yourself to look at the organization in new way.
  • Deliverables and Outcomes:
    • Information collected from conversations with or observations of users: transcripts of interviews, questionnaire responses, notes from observation, meeting minutes.
    • Existing written information: business mission and strategy statements, sample business forms and reports and computer displays, procedure manuals, job descriptions, training manuals, flow charts and documentation of existing systems, consultant reports.
    • Computer-based information: results from Joint Application Design Sessions, transcripts or files from group support system sessions, CASE repository contents and reports of existing systems, and displays and reports from system prototypes.
  • So, you need to understand the following components of organization:
    • The business objectives that drive what and how work is done.
    • The information people need to do their jobs.
    • The data (definition, volume, size, ... etc.) handled within the organization to support the jobs.
    • When, how, and by whom or what the data are moved, transformed, and stored.
    • The sequence and other dependencies among different data-handling activities.
    • The rules governing how data are handled and processed.
    • Policies and guidelines that describe the nature of the business and the market and environment in which it operates.
    • Key events affecting data values and when these events occur.
Return

Traditional Methods for Determining Requirements:
The traditional methods of collecting system requirements are:
  • Individually interview people informed by the operation and issues of the current system and needs for systems in future organization activites. Open-ended questions: are questions in interviews/questionnaires that have no pre-specified answers. Closed-ended questions: are questions in interviews/questionnaires that ask those responding to choose from a list.
    • Plan the interview.
      • Prepare interviewee, appointment, priming questions.
      • Prepare checklist, agenda, and questions
    • Listen carefully and take notes (tape record is permitted).
    • Review notes within 48 hours of interview.
    • Be neutral.
    • Seek diverse views.
    Interview Outline
    Interviewee: Name of person being interviewed Interviewer: Name of person leading interview
    Location/Medium:
    Office, conference room, or phone number    		 Appointment Date:
    Start Time:
    End Time:
    Agenda:
    • Introduction
    • Background Project
    • Overview of Interview
      • Topics to be covered
      • Permission to Tape Record
    • Topic 1 Questions
    • Topic 2 Questions
    • Summary of Major Points
    • Questions from Interviewee
    • Closing
    		Approximate Time:
    General Observations:
    Interviewee seemed busy - probably need to call in a few days for follow-up questions since he gave only short answers. PC was turned off- probably not a regular PC user.
    Unresolved Issues, Topics not covered:
    He needs to look up figures of previous years. He raised the issue of how to handle the problem, but he did not have to discuss.
    When to ask question, if conditional
    Question number 1
    Have you used current system ? If so, how often ?

    If yes, go to Question number 2.     		Answer
    Yes, I ask for report weekly

    Observation
    Seemed anxious - may be over-estimating usage frequency
    Question 2

    What do you like least about this system ?    		 Answer
    Using wrong units


    Observations:
    Optins determine thne right units, but user chose the wrong one.
  • Survey people via questionnaires to discover issues and requirements.
    • Choosing Questionnaire Respondents (Sampling- Avoid: How to Lie with Statistics).
    • Designing Questionnaire - less expensive- close-ended questions, few open-ended questions (extremely clear in meaning and logical in sequence).
    Comparison between Interviews and Questionnaires
    Characteristics InterviewsQuestionnaires
    Information Richness High (many channel) Medium to low (only responses)
    Time Required Can be extensive Low or moderate
    Expense Can be high Moderate
    Confidentiality Interviewee is known to interviewer Respondent can be unknown
    Chance of Follow-up & Probing Good: probing and clarification questions can be asked by either interviewer or interviewee Limited: probing and follow-up done after original data collection
    Involvement of Subject Interviewee is involved and committed Respondent is passive, no clear commitment
    Potential Audience Limited numbers, but complete responses from those interviewed Can be quite large, but lack of response from some can bias results
  • Interview groups of people with diverse needs to find synergies and contrasts among system requirements-core of JAD One drawback of to using interviews and questionnaires to collect systems requirements is the need for the analyst to reconcile apparent contradictions in the information collected. Clearly, gathering information about an information system through a series of individual interviews and follow-up calls is not an efficient process. Another option is the group interview (several key people at once (important information is collected, more effective use of time, hearing openions of other key people resolves many conflicts). Disadvantages: difficult to schedule it (video conferences, chating can minimize the geographical dispersion factor).
  • Observe workers at selected times to see how data are handled and what information people need to do their jobs.
  • Study business documents to discover reported issues, policies, rules, and directions as well as concrete examples of the use of data and information in the organization.
Example of a business form (Generated from Microsoft Access)
Analyzing of organizational documents and observation, along with intervieweing and questionnaires, are the methods for gathering system requirements.
Comparison between Observation and Document Analysis
Characteristics InterviewsQuestionnaires
Information Richness High (many channel) Medium to low
Time Required Can be extensive Low or moderate
Expense Can be high Low to Moderate
Confidentiality Observee is known to interviewer Depends on nature of document; does not change simply by being read
Chance of Follow-up & Probing Good: probing and clarification questions can be asked by either interviewer or interviewee Limited: probing and follow-up done after original data collection
Involvement of Subject Interviewees may or may not be involved and committed depending on whether they know if they being observed None, no clear commitment
Potential Audience Limited numbers and limited time (snapshot) of each Potentially basis by which documents were kept or because document not created for this purpose
Return

Modern Methods for Determining Requirements:
Even though we called interviews, questionnaires, observation, and document analysis traditional methods for determining a system's requirements, all of these methods are still very much used by analysts to collect important information.
Today, however, there are additional techniques to collect information about the current system, the organizational area requesting the new system, and what the new system should should be like.
Modern methodsfor Collecting System Requirements:
  • Bringing together in a Joint Application Design (JAD) session users, sponsers, analysts and others to discuss and review system requirements.
  • Using group support systems to facilitate the sharing of ideas and voicing openions about system requirements.
  • using CASE tools to analyze current systems to discover requirements to meet changing business conditions.
  • Iteratively developing system prototypes that refine the understanding of system requirements in concrete by showing working versions of syetm features.
JAD is similar to a group interview; a JAD, however, follows a particular structure of roles and agenda that is quite different from a group interview during which analysts control the sequence of questions answered by the user. The primary purpose of using JAD in the analysis phase is to collect systems requirements simultaneously from the key people involved in the system. The result is an intense and structured, but highly effective process.

The idea behind JAD sessions is to keep participants away from as many distractions as possible so that they can concentrate on systems analysis.
Illustration of typical room layout for a JAD:


The Typical Participants in a JAD are:
  • JAD session leader: plans, organizes, and runs the JAD.
  • Users: The key users of the system under construction are vital participants in a JAD.
  • Managers: Managers of the worker groups who use the system in question provide insight into new organizational directions.
  • Sponsor: (attends at the beginning and at the end).
  • Systems Analysts: Members of the systems analysis team attend the JAD (not to run or domenante the process).
  • Scribe: The scribe takes notes during the JAD sessions.
  • IS staff: Besides systems analysts, other IS staff (programmers, database analysts, IS planners, and data center personnal, may attend to learn from the discussion and possibly contribute their ideas on the technical feasibility of proposed ideas or on technical limitations of current systems.

CASE tools during JAD:The CASE tools most useful to analysis during a JAD are those referred to as upper CASE.

Supporting JAD with GSS:The JAD process is typically not well supported by computing. Group Support Systems (GSS)can be used to support group meetings (JAD suffers from many of the problems as any group meeting, time for everybody to speak, some people try to speak all the time, other afraid to speak out for fear they will be criticized, most people are not willing to criticize or challenge their bosses).
GSS designed to help allivate some of the problems with group meetings (it gives everybody the same chance to contribute, group members type their comments into computers rather than speak them, the GSS is set up so that all members of the group can see what every other member has been typing - so nobody can dominate the meeting).

Using Prototyping During Requirements Determination:Prototyping is an iterative process involving analysis and users whereby a rudimentary version of an information system is built and rebuilt according to user feedback. Prototyping can replace the SDLC or augment it. Prototyping will allow you to quickly convert basic requirements into a working, though limited, version of the desired information system. Converting verbal descriptions of requirements into a physical system.
Prototyping is possible with several 4GLs and with CASE tools. Prototyping is most useful for requirements determination when:
  • User requirements are not clear or well understood.
  • One or a few users and other stakeholders are involved with the system.
  • Possible designs are complex and require concrete form to fully evaluate.
  • Communication problems have existed in the past between users and analysts and both parties want to be sure that system requirements are as specific as possible.
Prototyping has the following drawbacks:
  • A tendency to avoid creating formal documentation of system requirements.
  • Prototypes can become very idiosyncratic to the initial user difficult to diffuse or other potential users.
  • Prototypes are often built as stand-alone systems, thus ignoring issues of sharing data and interactions with other systems.
  • Checks in the SDLC are bypassed on that some or more subtle, but still important, system requirements might be forgotton (e.g., security, some data entry controls, or standardization of data across systems).
Return

Radical Methods for Determining Requirements:
Business Process Reengineering (BPR): The search for, and implementation of, radical change in business processes to acheive breakthrough improvements in products and services.
Identify Processes to Reengineer: A first step in any BPR effort relates to understanding what processes to change. You must first understand which processes represent the key business processes for organization.
Key business processes The structured, measured set of activities designed to produce a specific output for a particular customer or market. After identifying key business processes, the next step is identify specific activities that can be radically improvedthrough reengineering. We have to answer these questions:
  1. How important is the activity to delivering an outcome ?
  2. How feasible is changing the activity ?
  3. How dysfunctional is the activity ?

Disruptive Technologies Once key business processes and activities have been identified, information technologies must be applied to radically improve business processes. To do this, Hammer & Champy suggested that organizations think "inductively" about information technology. Induction is the process of reasoning from the specific to the general, which means that managers must learn the power of new technologies and think of innovative ways to alter the way work is done. This is contrary to deductive thinking wher problems are first identified and solutions are then formulated.
Disruptive technologies: Technologies that enable the breaking of long-held business rules that inhibit organizations from making radical business changes.


Return

Hosted by www.Geocities.ws

1