Chapter 6 Requirements Determination

1. Chapter 6Requirements Determination Traditional Methods, JAD, and RAD

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

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 • 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 • screens only • Proof-of-concept • limited • Partial-function • Pilot

15. Joint Application Design (JAD) COMMUNICATION ! • 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

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 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)?

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