Chapter 6Requirements Determination

Traditional Methods, JAD, and RAD

Sumber dari :academic.udayton.edu/MIS380/ch6lec.ppt

Agenda Chapter Learning Objectives Hiring Exercise A Few Words on Traditional Design

– Interviews – Observing Users

An Example of Requirements Interview Plan – Review Team

Assignment Prototyping Methodology Joint Application Design (JAD) RAD Summary

Chapter Learning Objectives Describe options for designing and conducting interviews

Develop a plan for conducting an interview Explain advantages and pitfalls of observation Explain how technology can be used to support

requirements determination Participate in and plan JAD sessions Use prototyping for requirements determination Select appropriate requirements determination

method

Deliverables (Artifacts) of Requirements Determination

From interviews and observations– Interview transcripts, observation notes,

meeting minutes From existing written documents

– Mission and strategy statements, business forms, procedure manuals, job descriptions, training manuals, system documentation, flowcharts

From computerized sources– JAD session results, CASE repositories,

system prototype displays and reports

Hiring ExerciseImagine yourself as the head of systems development for a new start up firm. You have a new analyst’s position to fill and dozens of applicants interested in the position.

a. What qualities would you look for in seeking to hire the best analyst?

b. How would you try to determine whether the individuals you interview possessed these qualities?

“Traditional” Analysis and Design What are the pros and cons of the

following traditional methods?– Interviews– Questionnaires– Observation– Analyzing existing procedures and

documents

Interviews

Funnel Approach– Start with broad, open-ended questions

– Follow with more specific questions What are the advantages?

Group Interviews

Interview several key people together Advantages

– More effective use of time– Can hear agreements and disagreements at

once– Opportunity for synergies

Disadvantages– More difficult to schedule than individual

interviews

Observation How are people affected by being

observed?

What can you do to overcome these effects?

Good Requirements Statements

Simple – A one-line statement, or series of related one-line statements, of the requirement attribute. Like the statement of the core requirement itself, this should be positive, explicit, and stated in the future tense

Complete - All items needed for specifying the requirements of the solution to the problem are included.

Correct - Each item in the Business Requirements is free of error. Precise, Unambiguous, and Clear –

– Each Business Requirement item is exact and not vague. – Each Business Requirement item has but one interpretation. – Each item’s meaning is understood, and the specification is easy to read.

Consistent - No Business Requirements item conflicts with another item in the specification. Relevant - Each Business Requirements item is pertinent to the problem and its solution. Testable – It will be possible, during program development and acceptance testing, to

determine whether the Business Requirements item has been satisfied. Traceable - Each Business Requirements item can be traced to its origin in the problem

environment. Feasible - Each Business Requirements item can be implemented with the techniques, tools,

resources, and personnel available within the specified cost and schedule constraints. Free of Unwarranted Design Detail - The Business Requirements are statements of the

requirements that must be satisfied by the problem solution, and they are not obscured by proposed solutions to the problem.

Manageable - Each Business Requirements item is expressed in such a way that it can be changed without having an excessive impact on other items.

– Changes can be controlled. – Each proposed change to the specifications can be traced to an existing requirement. – The impact of the proposed change can be assessed. .– A test may be formulated to determine if the requirement characteristic has been met.

From Guide to Writing Good Requirements

Interview Plan

Review Team Assignment Review Clients What lessons about interviewing

do you take away from reviewing the example of requirements?

Figure 1-11: The Prototyping Methodology

No FormalDesignDocument

Reasons for Prototyping

Demonstrating and selling a concept or idea

Demonstrating feasibility Improving understanding of requirements

and improving communication Determining requirements Changing requirements Evolving requirements

Types of Prototypes

Simulation, or slide-show– screens only

Proof-of-concept– limited

Partial-function Pilot

Joint Application Design (JAD) Multiple group sessions

– users– analysts, technicians– managers/sponsors– scribe, leader -- independent– observers (can’t be involved)

Develop logical specifications Leader/facilitator in charge -- well-

trained, not project leader -- not user in charge, as in prototyping

COMMUNICATION !

Figure 6-6: Illustration of the Typical Room Layout for a JAD (Joint Application Design)

JAD Planning Activities Determine goal of JAD Set agenda and timeframe Identify participants (only

necessary ones) and schedule Obtain sponsorship Assign scribe and facilitator Arrange location and logistics Participants read/prepare

Fill in the blank: For JAD to be successful, participants must _______:

Doing the JAD Kickoff with sponsor -- positive and

creative -- may also want ice-breaker Set ground rules, stick to agenda Manage conflict and fatigue Reach consensus for each

deliverable Clean-up documentation on each

product Products reviewed by participants

Role of Automated Tools Within JAD?

CASE?

Others?

Checking the JAD

Review within 5 days; provide fixes Correct and re-validate Use a CASE tool as repository Group must see last version before

it goes to sponsor Evaluate JAD within 2 weeks

Some JAD Lessons The less structure and control used, the

less consistent the results. The looser the org. culture, the more

structure is needed for JAD. The weaker the development process,

the more structure is needed for JAD. The more time in preparation, the

quicker and more productive the JAD. All participants are equal (not us versus

them; may affect voting methods).

Some JAD Issues May be difficult for facilitator to deal

with dysfunctional behavior Groupthink -- pressure of consensus,

facilitator can’t contribute Risky-Shift -- individuals don’t fear

personal retribution Commitment -- selected to represent

group and must deliver CASE tools can help visualize ideas

Spiral Development -- RAD

High-levelRequirements

Customer Review

DetailedRequirements

Analysis

Design

Agile Methodologies for Requirements Determination Continual user involvement

– Replace traditional SDLC waterfall with iterative analyze – design – code – test cycle

Agile usage-centered design– Focuses on user goals, roles, and tasks

The Planning Game– Based on eXtreme programming– Exploration, steering, commitment

Agile Usage-Centered Design Steps Gather group of programmers, analysts, users, testers, facilitator

Document complaints of current system Determine important user roles Determine, prioritize, and describe tasks

for each user role Group similar tasks into interaction

contexts Associate each interaction context with a

user interface for the system, and prototype the interaction context

Step through and modify the prototype

When Apply RAD (System Characteristics)?

Summary

What data collection methods may be used to determine requirements?