5-1 © Prentice Hall, 2007 Chapter 5: Determining Object-Oriented Systems Requirements...

5-1© Prentice Hall, 2007

Chapter 5:Chapter 5:Determining Object-Oriented Determining Object-Oriented

Systems RequirementsSystems Requirements

Object-Oriented Systems Analysis and Design

Joey F. George, Dinesh Batra,

Joseph S. Valacich, Jeffrey A. Hoffer

Chapter 5 5-2© Prentice Hall, 2007

Chapter ObjectivesChapter Objectives– Describe options for and develop plans for designing and

conducting interviews to determine systems requirements– Explain advantages and pitfalls of observing workers and

analyzing business documents to determine systems requirements

– Participate in and help plan Joint Application Design (JAD) sessions

– Use prototyping during requirements determination– Describe agile approaches to requirements determination– Select the appropriate methods to elicit system requirements


Characteristics for Successful Characteristics for Successful Requirements DeterminationRequirements Determination

ImpertinenceImpartialityRelaxing of constraintsAttention to detailsReframing


How to Determine RequirementsHow to Determine Requirements


What Is Interviewing?What Is Interviewing?

Dialogue with user or manager to obtain their requirements

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

no specific answers in mind– Closed-ended – structured, questions with

limited range of possible answers


How to Conduct InterviewsHow to Conduct Interviews


Interview Guide is a document for developing, planning, and conducting an interview.


Each question in an interview guide can include both verbal and non-verbal information.


What is Direct Observation?What is Direct Observation? Watching users do their jobs

Purpose – obtain firsthand, objective measures of employees’ interactions with the information system

Can provide more accurate information than self-reporting in interviews

Pitfalls – observed employees may change their behavior; time limitations make observation more difficult


What is Document Analysis?What is Document Analysis?

Review of existing business documents

Can give a historical and “formal” view of system requirements

Relevant documents – mission statements, business plans, organizational charts, policy manuals, job descriptions, correspondences, reports from organizational studies


Formal vs. Informal SystemsFormal vs. Informal Systems

Formal system – the official way a system works as described in organizational documentation

Informal system – the way the system actually works


Written 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.


Observations vs. Document Observations vs. Document AnalysisAnalysis


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

Intensive group-oriented requirements determination technique

Team members meet in isolation for an extended period of time

Highly focusedResource intensiveStarted by IBM in 1970s


JAD Team MembersJAD Team Members

Session leader coordinatorUsers information sourceManagers information sourceSponsor championSystems analysts listenersScribe recorderIS staff listeners


What Is Prototyping?What Is Prototyping?

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


When to Use PrototypingWhen to Use PrototypingPrototyping 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.


Pitfalls of PrototypingPitfalls of Prototyping Prototyping has the following drawbacks:

– Tendency to avoid creating formal systems requirement documentation

– Prototypes may be indiosynchratic to the individual user and difficult to adapt for others

– Prototypes are designed as standalone systems, so do not address data sharing and integration

– Checks in SDC are bypassed, so issues like security, controls and standardization may be ignored


What are Agile Methodologies?What are Agile Methodologies?

Techniques for eliciting user requirements that encourage continuous user involvement and adapt to incremental changes in system design over time

Two approaches:– Agile user-centered design (similar to JAD)– eXtreme programming


Steps in Steps in Agile User-Centered DesignAgile User-Centered Design

1. Gather stakeholders together in sequestered environment2. Give everyone a chance to vent complaints and record

them3. Determine and list most appropriate user roles4. Determine tasks for each user role5. Group tasks by similarity, into “interaction context”6. Write a description for each task in an interaction context7. Treat each interaction context as a single user interface

screen, and sketch the user interface8. List all the steps of the user interface, and make sure these

can be accomplished in the prototype


eXtreme ProgrammingeXtreme Programming Typically involve 2-person programming teams Fusion of planning, analysis, design, and

implementation Characterized by:

– Short development cycles– Incremental planning– Focus on automated tests for monitoring development

process– Reliance on evolutionary development


eXtreme Programming eXtreme Programming Planning GamePlanning Game

Players – business and development Three phases:

– exploration– commitment– Steering

Three stacks of story cards– Essential features– Value-added features– Noce-to-have features

Story cards are replaced by task cards during Iteration Planning Game

5-1 © Prentice Hall, 2007 Chapter 5: Determining Object-Oriented Systems Requirements...

Documents

Transcript of 5-1 © Prentice Hall, 2007 Chapter 5: Determining Object-Oriented Systems Requirements...