1. Chapter 6 Requirements Determination
Traditional Methods, JAD, and RAD
Sumber dari :
academic.udayton.edu/MIS380/ch6lec.ppt

2. Agenda Summary 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

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

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

5. Hiring Exercise
Imagine 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?

6. “Traditional” Analysis and Design
What are the pros and cons of the following traditional methods?
Interviews
Questionnaires
Observation
Analyzing existing procedures and documents

7. Interviews Funnel Approach What are the advantages?
Start with broad, open-ended questions
Follow with more specific questions
What are the advantages?

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

9. Observation How are people affected by being observed?
What can you do to overcome these effects?

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

11. Interview Plan Review Team Assignment Review Clients
What lessons about interviewing do you take away from reviewing the example of requirements?

12. Figure 1-11: The Prototyping Methodology
No Formal
Design
Document

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

14. Types of Prototypes Simulation, or slide-show Proof-of-concept
screens only
Proof-of-concept
limited
Partial-function
Pilot

15. 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 !

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

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

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

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

20. Role of Automated Tools Within JAD?
CASE?
Others?

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

22. 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).

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

24. Spiral Development -- RAD
Design
High-level
Requirements
Analysis
Detailed
Requirements
Many variations have been developed (see Chapter 19)
All methodologies include many of the same skills plus some unique ones
Many methodologies in organizations are combinations of several pure methodologies
Customer Review

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

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

27. When Apply RAD (System Characteristics)?
(e.g., see Bourne, 1994, “Putting Rigor Back in RAD,” Database Programming and Design, Vol. 7, No. 8, pp )

28. Summary
What data collection methods may be used to determine requirements?