Determining System Requirements

You should question everything.

Impertinence

Your role is to find the best solution to a business problem or opportunity.

Impartiality

Assume that anything is possible and eliminate the infeasible.

Relax constraints

Every fact must fit with every other fact.

Attention to detail

You must consider how each user views his or her requirements.

Reframing

(Deliverables) From interviews and observations

Interview transcripts, observation notes, meeting minutes

(Deliverables) From existing written documents

Business mission and strategy statements, sample business forms and reports and computer displays, procedure manuals, job descriptions, training manuals, flowcharts and documentation of existing systems, consultant reports

(Deliverables) From computerized sources

JAD session results, CASE repositories, system prototype displays, and reports

Traditional Methods for Determining Requirements

 Interviewing and Listening

 Interviewing groups

 Directly observing users

 Analyzing procedures and other documents

Dialogue with users or managers to obtain their requirements.

Interviewing

Two forms of Interviewing

1. Open-ended: conversational, questions with no specific answers in mind.

2. Closed-ended: structured, questions with a limited range of possible answers.

Guidelines for Effective Interviewing

 Plan the interview.

–Prepare interviewee: appointment, priming questions.

–Prepare agenda, checklist, questions.

 Listen carefully and take notes (record if permitted).

 Review notes within 48 hours.

 Be neutral.

 Seek diverse views.

Is a document for developing, planning and conducting an interview.

Interview Guide

Interview several key people together.

Interviewing Groups

A facilitated process that supports idea generation by groups.

Nominal Group Technique

Watching users do their jobs. Can provide more accurate information than self-reporting (like questionnaires and interviews).

Direct Observation

Review of existing business documents. Can give a historical and “formal” view of system requirements.

Document Analysis

Types of information to be discovered:

–What problems exist with the existing system?

–Are there opportunities to meet new needs?

–What’s the organizational direction?

–Who are the “key stakeholders?

–What are the values of the organization?

–Are there any special information processing circumstances?

–What’s the history of the current system design?

–Are there rules for processing data?

Four types of useful documents

1. Written work procedures

2. Business forms

3. Reports

4. Descriptions of current information system

Describes how a job is performed. Includes data and information used and created in the process of performing the job or task.

Written work procedures

Explicitly indicate data flow in or out of a system.

Business forms

It enables the analyst to work backward from the report to the data that generated it.

Reports

The official way a system works is described in the organization’s documentation. Procedure documents describe the formal system.

Formal

The way a system works in practice. Interviews and observation reveal an informal system.

Informal

Brings together key users, managers, and systems analysts. Purpose: collect system requirements simultaneously from key people. Conducted off-site

Joint Application Design (JAD)

Facilitate sharing of ideas and voicing of opinions about system requirements.

Group Support Systems

Used to analyze existing systems. Help discover requirements to meet changing business conditions.

CASE tools

Iterative development process. The rudimentary working version of the system is built. Refine understanding of system requirements in concrete terms.

System prototypes

Quickly converts requirements to a working version of the system.

Prototyping

Search for and implementation of radical change in business processes to achieve breakthrough improvements in products and services.

Business Process Reengineering (BPR)