team-based development isys321 determining object- oriented systems requirements

24
Team-Based Development Team-Based Development ISYS321 ISYS321 Determining Object- Determining Object- Oriented Systems Oriented Systems Requirements Requirements

Upload: julius-singleton

Post on 31-Dec-2015

220 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements

Team-Based DevelopmentTeam-Based DevelopmentISYS321ISYS321

Determining Object-Determining Object-Oriented Systems Oriented Systems

RequirementsRequirements

Page 2: Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements
Page 3: Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements
Page 4: Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements

How to Determine RequirementsHow to Determine Requirements

Page 5: Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements

What Is Interviewing?What Is Interviewing?

Dialogue with user or manager to obtain Dialogue with user or manager to obtain their requirementstheir requirements

Gather facts, opinions, speculation, body Gather facts, opinions, speculation, body language and emotionlanguage and emotion

Two forms:Two forms:– Open-endedOpen-ended – conversational, questions – conversational, questions

with no specific answers in mind with no specific answers in mind (USE: To (USE: To probe)probe)

– Closed-endedClosed-ended – structured, questions with – structured, questions with limited range of possible answers limited range of possible answers (USE: When major answers are well known)(USE: When major answers are well known)

Page 6: Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements

How to Conduct InterviewsHow to Conduct Interviews

Page 7: Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements

What Are Questionnaires?What Are Questionnaires?

A written set of questions, sometimes with A written set of questions, sometimes with answers to select from, that is distributed to answers to select from, that is distributed to a cross-section of stakeholders in order to a cross-section of stakeholders in order to obtain system requirementsobtain system requirements

A more cost-effective method than interviewsA more cost-effective method than interviews

Page 8: Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements

Choosing Questionnaire Choosing Questionnaire RespondentsRespondents

Goal: obtain a representative sample of Goal: obtain a representative sample of stakeholdersstakeholders

Sampling Methods:Sampling Methods:– Convenience – Convenience – i.e. local site, willing to be i.e. local site, willing to be

surveyedsurveyed

– Random –Random – i.e. every nth person i.e. every nth person

– Purposeful –Purposeful –meet certain criteria, i.e. power meet certain criteria, i.e. power usersusers

– Stratified – Stratified – random set from various random set from various categoriescategories,, i.e. users, managersi.e. users, managers

Page 9: Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements

Designing QuestionsDesigning Questions

Avoid ambiguity, especially in closed-ended Avoid ambiguity, especially in closed-ended questionsquestions

Pretest questions before usePretest questions before use Closed-ended questions: true/false, multiple Closed-ended questions: true/false, multiple

choice, rating, rankingchoice, rating, ranking Open-ended questions: for discovering Open-ended questions: for discovering

potential probing questionspotential probing questions

Page 10: Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements

Interviews vs. QuestionnairesInterviews vs. Questionnaires

Page 11: Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements

Other ApproachesOther Approaches

ObservationObservation Watching users do their jobsWatching users do their jobs More accurate than self-reporting of More accurate than self-reporting of

questionnaires and interviewsquestionnaires and interviews Hard to get unbiased data Hard to get unbiased data

(people work differently when being watch)(people work differently when being watch)

Page 12: Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements

Other ApproachesOther Approaches

Analyzing Procedures and DocumentsAnalyzing Procedures and Documents Review of existing business documents and Review of existing business documents and

proceduresprocedures Historical and “formal” view of system Historical and “formal” view of system

requirementsrequirements Beware: Procedures/documents are often Beware: Procedures/documents are often

out-of-date. Verify assumptions with users out-of-date. Verify assumptions with users and managersand managers

Page 13: Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements

Other ApproachesOther Approaches

Analyzing Procedures and DocumentsAnalyzing Procedures and Documents Types of information to be discovered:Types of information to be discovered:

– problems with existing systemproblems with existing system– opportunity to meet new needopportunity to meet new need– organizational directionorganizational direction– names of key individualsnames of key individuals– organizational values (aids in prioritization)organizational values (aids in prioritization)– special information processingspecial information processing– rules for processing datarules for processing data– why system was designed the way it waswhy system was designed the way it was

Page 14: Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements

Observations vs. Document Observations vs. Document AnalysisAnalysis

Page 15: Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements

Work Procedureis a business

document that formally describes

work processes. Provides useful

information regarding system functionality and

logic.

Page 16: Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements

Business formis a document that

contains useful information regarding data organizations and possible screen layouts.

Page 17: Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements

Other Business DocumentsOther Business Documents

Report Report (generated by current systems)(generated by current systems)

– Often contains pertinent summary Often contains pertinent summary information, and possibly screen layout information, and possibly screen layout ideasideas

Existing system documentationExisting system documentation– Gives descriptions of use and inner Gives descriptions of use and inner

workings of current information systemworkings of current information system– flowcharts, data dictionaries, user flowcharts, data dictionaries, user

manuals, etc.manuals, etc.

Page 18: Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements

Joint Application Design Joint Application Design (JAD)(JAD)

Intensive group-oriented requirements Intensive group-oriented requirements determination techniquedetermination technique

Team members meet in isolation for an Team members meet in isolation for an extended period of timeextended period of time

Highly focusedHighly focused Resource intensiveResource intensive Started by IBM in 1970sStarted by IBM in 1970s

Page 19: Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements

JAD Team MembersJAD Team Members

Session leaderSession leader - - coordinatorcoordinator Users Users - - information sourceinformation source ManagersManagers - - information sourceinformation source Sponsor Sponsor - - championchampion Systems analysts Systems analysts - - listenerslisteners Scribe Scribe - - recorderrecorder IS staff IS staff - - listenerslisteners

Page 20: Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements
Page 21: Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements

PrototypingPrototyping

A repetitive process in which analysts and A repetitive process in which analysts and users build a rudimentary version of an users build a rudimentary version of an information system based on user feedbackinformation system based on user feedback

Repeated cycle: build, use, evaluateRepeated cycle: build, use, evaluate

Page 22: Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements
Page 23: Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements

When to Use PrototypingWhen to Use Prototyping

Prototyping is good when:Prototyping is good when:– Users are unclear about their Users are unclear about their

requirements.requirements.– The system affects a relatively small The system affects a relatively small

number of users.number of users.– Designs are complex.Designs are complex.– Communication between users and Communication between users and

analysts needs to be strengthened.analysts needs to be strengthened.– Rapid application development tools are Rapid application development tools are

available.available.

Page 24: Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements

Any Questions?Any Questions?