Requirements JAD - Joint Application Development

• technique that unites development, management and customer groups

• JAD sessions are used in the PLC (Product Life Cycle)

• best method for collecting requirements from users, customers, or customer advocates

• collect requirements and resolve issues early on through a series of meetings

• JAD team = mixture of customer functional experts (2~3) to systems professionals (1)

• 93% of all times projects slide into cost/time overruns stems from misunderstanding

Benefits

• saves time; eliminates delay; removes misunderstandings;
  improves quality
• reduces function creep
• cultural risk is mitigated in the case that transition managers are properly used
• avoids bloated functionality
• avoids too specific/vague requirements

Principles

• involve all stakeholders (incl. sponsor, manager, tech writer, subject matter experts)
• support from the upper management (to allow time and effort and to be acceptive of results)
• a facilitator who can speak both languages of customer and developer
• stakeholders must have empowered representatives (mid-level managers > executives)
• rotate in special workers: subject context experts; members of line of staff
• users drive the speed of the project; weekly meetings are recommended but users can decide this
• sessions should be about 2 hours; rush projects can be up to 4 hours; fatigue drops off after 2 hours
• no more than 15 people

Tasks

• Technical Analyst
  • group facilitation
  • systems analysis
  • collecting requirements
  • speaks both language of users and tech groups
• TA must produce deliverables:
  • identify stakeholders
  • scope general requirements form each user perspective (business abstract)
  • reconcile each user's view into a summary (project abstract)
  • define interaction between products/systems/users/organisation (context diagram)
  • calculate time/cost box for project (preliminary business plan)
  • define use cases; collect desired inputs and outputs
  • prioritise the use cases by user preference and risk
  • validate and review the use case scenarios
  • organise the use cases, constraints, assumptions and requirements into a SRS (Software Requirements Specification)
  • design the screen and report layouts

Other Tasks

• review the final business plan (high level design and cost/benefit analysis)
• develop release/acceptance test plan
• review project plan
• acceptance testing / incremental releases
• user documentation
• monitor defects and resolve issues and propose changes
• sign off on project when the product is completed/released