Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements

How to Determine Requirements

What Is Interviewing? Dialogue with user or manager to obtain their requirements Dialogue with user or manager to obtain their requirements Gather facts, opinions, speculation, body language and emotion Gather facts, opinions, speculation, body language and emotion Two forms: Two forms: –Open-ended – conversational, questions with no specific answers in mind (USE: To probe) –Closed-ended – structured, questions with limited range of possible answers (USE: When major answers are well known)

How to Conduct Interviews

What Are Questionnaires? A written set of questions, sometimes with answers to select from, that is distributed to a cross-section of stakeholders in order to obtain system requirements A written set of questions, sometimes with answers to select from, that is distributed to a cross-section of stakeholders in order to obtain system requirements A more cost-effective method than interviews A more cost-effective method than interviews

Choosing Questionnaire Respondents Goal: obtain a representative sample of stakeholders Goal: obtain a representative sample of stakeholders Sampling Methods: Sampling Methods: –Convenience – i.e. local site, willing to be surveyed –Random – i.e. every nth person –Purposeful – meet certain criteria, i.e. power users –Stratified – random set from various categories, i.e. users, managers

Designing Questions Avoid ambiguity, especially in closed-ended questions Avoid ambiguity, especially in closed-ended questions Pretest questions before use Pretest questions before use Closed-ended questions: true/false, multiple choice, rating, ranking Closed-ended questions: true/false, multiple choice, rating, ranking Open-ended questions: for discovering potential probing questions Open-ended questions: for discovering potential probing questions

Interviews vs. Questionnaires

Other Approaches Observation Watching users do their jobs Watching users do their jobs More accurate than self-reporting of questionnaires and interviews More accurate than self-reporting of questionnaires and interviews Hard to get unbiased data (people work differently when being watch) Hard to get unbiased data (people work differently when being watch)

Other Approaches Analyzing Procedures and Documents Review of existing business documents and procedures Review of existing business documents and procedures Historical and “formal” view of system requirements Historical and “formal” view of system requirements Beware: Procedures/documents are often out-of- date. Verify assumptions with users and managers Beware: Procedures/documents are often out-of- date. Verify assumptions with users and managers

Other Approaches Analyzing Procedures and Documents Types of information to be discovered: Types of information to be discovered: –problems with existing system –opportunity to meet new need –organizational direction –names of key individuals –organizational values (aids in prioritization) –special information processing –rules for processing data –why system was designed the way it was

Observations vs. Document Analysis

Work Procedure is a business document that formally describes work processes. Provides useful information regarding system functionality and logic.

Business form is a document that contains useful information regarding data organizations and possible screen layouts.

Other Business Documents Report (generated by current systems) Report (generated by current systems) –Often contains pertinent summary information, and possibly screen layout ideas Existing system documentation Existing system documentation –Gives descriptions of use and inner workings of current information system –flowcharts, data dictionaries, user manuals, etc.

Joint Application Design (JAD) Intensive group-oriented requirements determination technique Intensive group-oriented requirements determination technique Team members meet in isolation for an extended period of time Team members meet in isolation for an extended period of time Highly focused Highly focused Resource intensive Resource intensive Started by IBM in 1970s Started by IBM in 1970s

JAD Team Members Session leader - coordinator Session leader - coordinator Users - information source Users - information source Managers- information source Managers- information source Sponsor - champion Sponsor - champion Systems analysts - listeners Systems analysts - listeners Scribe - recorder Scribe - recorder IS staff - listeners IS staff - listeners

Prototyping A repetitive process in which analysts and users build a rudimentary version of an information system based on user feedback A repetitive process in which analysts and users build a rudimentary version of an information system based on user feedback Repeated cycle: build, use, evaluate Repeated cycle: build, use, evaluate

When to Use Prototyping Prototyping is good when: Prototyping is good when: –Users are unclear about their requirements. –The system affects a relatively small number of users. –Designs are complex. –Communication between users and analysts needs to be strengthened. –Rapid application development tools are available.

Any Questions?