Systems Analysis and Design Chapter 3

Questionnaire

set of written questions used to obtain information from individuals; often used when there is a large number of people from whom information and opinions are needed; may be paper based or electronic - typical response rates: < 50% (paper); < 30% (web) Common uses: - large numbers of people - need both information and opinions - when designing for use outside the organization

Interviews

the most commonly used requirements-gathering technique; it is natural - if you need to know something, you usually ask someone 5 steps: - selecting interviewees - designing interview questions - preparing for the interview - conducting the interview - post interview follow-up

System Proposal (end)

brings together into a single comprehensive document the material created during planning and analysis

Behavioral Models

a set of sequence diagrams, communication diagrams, behavioral-state machines, and a CRUDE matix that describes the internal behavior of the to-be system; this may include behavioral models of the as-is system that will be replaces

Requirements Definition

a straight-forward text report that simply lists the functional and nonfunctional requirements in an outline format - The most obvious purpose of this is to provide the information needed by the other deliverable in analysis, which include functional, structural, and behavioral models, and to support activities in design - The most important purpose of the requirements definition, however, is to define the scope of the system

Functional Model

an activity diagram, a set of use case descriptions, and a use-case diagram that illustrate the basic processes or external functionality that the system needs to support

Concept mapping

an educational psychology technique that has been used in schools, corporations, and health-care agencies to facilitate learning, understanding, and knowledge creation

Joint Application Development (JAD)

an information-gathering technique that allows the project team, users, and management to work together to identify requirements for the system Joint user-analyst meeting hosted by a facilitator - 10 to 20 users - 1 to 2 scribes as needed to record the session - Usually in a specially prepared room Meetings can be held electronically and anonymously - Reduces problems in group settings - Can be help remotely Sessions require careful planning to be successful - Users may need to bring documents or user manuals - Ground rules should be established

Informal Benchmarking

analyzes similar processes in other successful organizations; this helps the organization by introducing ideas that employees may never have considered but that have the potential to add value

Open-Ended Questions

are those that leave room for elaboration on the part of the interviewee; designed to gather rick information and give the interviewee more control over the information that is revealed during the interview

Closed-Ended Questions

are those that require a specific answer; used when an analyst is looking for specific, precise information; enables analysts to control the interview and obtain the information needed

Story Cards and Task Lists

associated with the agile development approaches; both are considered to be lightweight approached to documenting and gathering requirements; advantages to both of these are that they are very low tech, high touch, easily updated, and very portable

Electronic JAD or e-JAD

attempts to overcome these problems by using groupware; in these meeting rooms, each participant uses special software on a networked computer to send anonymous ideas and opinions to everyone else

Executive Summary

can be thought of as a summary of the complete proposal; provides all critical information in a very concise form; its purpose is to allow a busy executive to quickly read through it and determine which parts of the proposal he or she needs to go through more thoroughly

Task Lists

created for the requirement (story). If the requirement is deemed to be too large—for example, there are too many tasks on the task list—the requirement is split up into multiple story cards and the tasks are allocated across the new stories

Interview report

describes the information from the interview

The 5 most used techniques for gathering requirements are

interview, JAD sessions (a special type of group meeting), questionnaires, document analysis, and observation. A combination of techniques may be used

Structured Interviews

interviews in which specific sets of questions are developed before the interviews; there usually are more closed-ended questions

Unstructured Interviews

interviews that seek broad and roughly defined information; these are the most challenging interviews to conduct because they require the interviewer to ask open-ended questions and probe for important information on the fly

Observation

the act of watching processes being performed, it is a powerful tool for gathering information about the as-is system because it enables the analyst to see the reality of a situation, rather than listening to others describe it in interviews or JAD sessions Behaviors may change when people are watched: - Workers tend to be very careful when watched - Keep a low profile - Try not to interrupt or influence workers

Document Analysis

project teams use this to understand the as-is system - Review technical documents when available - Review typical user documents: ---- Forms ---- Reports ---- Policy manuals - Look for user additions to forms - Look for unused form elements

System Request

provides general ideas for the to-be system, defines the project's scope, and provides the initial work plan

Probing Questions

questions that follow up on what have just been discussed in order to learn more, and they often are used when the interviewer is unclear about an interviewee's answer

Nonfunctional Requirements

refer to behavioral properties that the system must have, such as performance and usability; these requirements are primarily used in design when decisions are made about the user interface, the hardware and software, and the system's underlying physical architecture. - operational - performance - security - cultural and political

Functional Requirement

relates directly to a process a system has to perform or information it needs to contain; these requirements flow directly into the creation of functional, structural, and behavioral models that represent the functionality of the evolving system

Concept Maps

represent meaningful relationships between concepts; useful for focusing individuals on the small number of key ideas on which they should concentrate

System Requirments

requirements in design are written from the developer's perspective

Duration Analysis

requires a detailed examination of the amount of time it takes to perform each process in the current as-is system; The analysts begin by determining the total amount of time it takes, on average, to perform a set of business procedures for a typical input; They then time each of the individual steps in the business process. The time to complete the basic steps are then totaled and compared to the total for the overall process. A significant difference between the two indicates that this part of the process is in need of a major overhaul - process integration - process parallelization

Requirement

simply a statement of what the system must do or what characteristic it must have

Technology Analysis

starts by having the analysts and managers developing a list of important and interesting technologies; then the group systematically identifies how every technology could be applied to the business process and identifies how the business would benefit

Critical Thinking Skills

the ability to recognize strengths and weaknesses and recast an idea in an improved form, and critical thinking skills are needed to really understand issues and develop new business processes

Top-Down Interview

the interviewer starts with broad, general issues and gradually works toward more-specific ones; enables the interviewee to raise a set of big-picture issues before becoming enmeshed in details, so the interviewer is less likely to miss important issues

Bottom-up Interview

the interviewer starts with very specific questions and moves to broad questions; this approach is preferred when the analyst already has gathered a lot of information about issues and just needs to fill in some holes with details

Problem Analysis

the most straightforward (and probably the most commonly used) requirement-analysis technique; this technique mean asking the users and managers to identify problems with the as-is system and to describe how to solve them in the to-be system; Improvements from this technique tend to be small and incremental but often is very effective at improving a system's efficiency or ease of use

The Workplan (project plan)

the original workplan, revised after having completed analysis

Operational

the physical and technical environments in which the system will operate

Requirements Determination

the purpose of this is to turn the very high-level explanation of the business requirements stated in the system request into a more precise list of requirements that can be used as inputs to the rest of analysis (creating functional, structural, and behavioral models); this leads to the design of the system

Performance

the speed, capacity, and reliability of the system

Appendices

these contain additional material relevant to the proposal, often used to support the recommended system, this might include results of a questionnaire survey or interviews, industry reports and statistics and so on

Activity Elimination

this is exactly what it sounds like; the analysts and mangers work together to identify how the organization could eliminate each activity in the business process, how the function could operate without it, and what effects are likely to occur

Story Card

typically an index card with a single requirement (functional or nonfunctional) written on it; once the requirement is written down, it is discussed to determine the amount of effort it will take to implement it

Process of Analysis: divided into 3 steps

understanding the as-is system, identifying improvements, and developing requirements for the to-be system

Avison and Fitzgerald provide us with a set of problems that can arise with regard to determining the set of requirements to be dealt with

- First, the analyst might not have access to the correct set of users to uncover the complete set of requirements. This can lead to requirements being missed, misrepresented, and/or over specified. - Second, the specification of the requirements may be inadequate. This can be especially true with the lightweight techniques associated with agile methodologies. - Third, some requirements are simply unknowable at the beginning of a development process. However, as the system is developed, the users and analysts will get a better understanding of both the domain issues and the applicable technology. This can cause new functional and nonfunctional requirements to be identified and current requirements to evolve or be canceled. Iterative and incremental-based development methodologies, such as the Unified Process and agile, can help in this case. - Fourth, verifying and validating of requirements can be very difficult.

3 strategies to determine requirements

- business process automation (BPA): creates small amount of change - business process improvement (BPI): creates a moderate amount of change - business process reengineering (BPR): creates significant change that affects much of the organization

3 BPI Techniques

- duration analysis - activity based costing - informal benchmarking

3 BPR Techniques

- outcome analysis - technology analysis - activity elimination

2 BPA Techniques

- problem analysis - root cause analysis

4 Steps for Questionnaire Process

1. Select the participants - Identify the population - Use representative samples for large populations 2. Designing the questionnaire - Careful question selection - Remove ambiguities 3. Administering the questionnaire - Working to get good response rate - Offer an incentive (e.g. a free pen) 4. Questionnaire follow-up - Send results to participants - Send a thank you

Interview notes

information that was collected over the course of the interview and is summarized in a useful format

5 steps for JAD approach

Select participants, design JAD session, preparing for a JAD session, conducting a JAD Session, and post-JAD follow-up

Walkthrough

a meeting at which the concept for the new system is presented to the users, managers, and key decision makers; the goal of this is to explain the system in moderate detail so that the users, managers and key decision makers clearly understand it, can identify improvements, and can make a decision about whether the project should continue

Structural Models

a set of CRC cards, class diagram, and object diagrams that describe the structural aspects of the to-be system; this may also include structural models of the current as-is system that will be replaces

BPA, BPI BPR

enable the analyst to help users create a vision for the new system, they are not sufficient for extracting information about the detailed business requirements that are needed to build it

Root Cause Analysis

focuses on problems, not solutions; the analysts starts by creating a prioritized list of problems; then tries to determine their causes; once the causes are known, solutions can be developed

Outcome Analysis

focuses on understanding the fundamental outcomes that provide value to customers With this approach, system analysts encourage the managers and project sponsor to pretend they are customers and to think carefully about what the organization's products and services enable the customers to do—and what they could enable the customer to do

Determining Requirements

for the requirements definition is both a business task and an information technology task - The most effective approach is to have both business people and analysts working together to determine business requirements; sometimes, however, users don't know exactly what they want, and analysts need to help them discover their needs

System Proposal

includes revised project management deliverables, such as the feasibility analysis and the work plan

Creating a requirements definition

is an iterative and ongoing process whereby the analyst collects information with requirements-gathering techniques (e.g., interviews, document analysis), critically analyzes the information to identify appropriate business requirements for the system, and adds the requirements to the requirements definition report To create a requirements definition, the project team first determines the kinds of functional and nonfunctional requirements that they will collect about the system. These become the main sections of the document. Next, the analysts use a variety of requirements-gathering techniques (e.g., interviews, observation) to collect information, and they list the business requirements that were identified from that information. Finally, the analysts work with the entire project team and the business users to verify, change, and complete the list and to help prioritize the importance of the requirements that were identified.

Activity Based Costing

it examines the cost of each major process or step in a business process rather than the time taken; the analysts identify the costs associated with each of the basic functional steps or processes, identify the most costly processes, and focus their improvement efforts on them

Interview Schedule

it lists all the people who will be interviewed, when and for what purpose; it can be an informal list that is used to help set up meeting times or a formal list that is incorporated into the work plan

Business Requirement

later in design, they evolve to become more technical, and they describe how the system will be implemented

Business Process Automation (BPA)

leaves the basic way the organization operates unchanged and uses computer technology to do some of the work; can make the organization more efficient but has the least impact on the business. Planners in these projects spend a significant time understanding the current as-is system before moving on to improvements and to-be system requirements - Least amount of change to the current system - Use computer technology to automate some portions

Business Process Improvement (BPI)

makes moderate changes to the way the organization operates in order to take advantage of new opportunities offered by technology or to copy what competitors are doing; can improve efficiency and effectiveness; Planners of these projects also spend time understanding the as-is system, but much less time than with BPA projects; their primary focus is on improving business processes, so time is spent on the as-is only to help with the improvement analyses and the to-be system requirements - Moderate amount of change is required - Designed to improve efficiency of the current system

Process integration

means changing the fundamental process so that fewer people work on the input, which often requires changing the processes and retraining staff to perform a wider range of duties

Business Process Reengineering (BPR)

means changing the fundamental way the organization operates, obliterating the current way of doing business and making major changes to take advantage of new ideas and new technology; Planners of these projects pend little time understanding the as-is, because their goal is to focus on new ideas and new ways of doing business - Most amount of change, a complete makeover - Focus is on the to-be system - little time spent on the current system

Process parallelization

means changing the process so that all the individual steps are performed at the same time

The Requirements-Gathering Process

used for building political support for the project and establishing trust and rapport between the project team building the system and the users who ultimately will choose to use or not use the system Challenges of this: - Analyst may not have access to the correct users - Requirements specifications may be inadequate - Some requirements may not be known in the beginning - Verifying and validating requirements can be difficult

Security

who has the authorized access to the system under what circumstances