discovering business requirements

  • Distinctions among the user's (business) requirements, the system/software/product requirements, and use cases.
  • Using the powerful Problem Pyramid™ tool to define clearly the REAL problem and requirements.
  • Methods for discovering and understanding what the REAL requirements are.
  • Formats for documenting and communicating business requirements.

Inadequately defined requirements impact many different types of project participants. Developers don't know what to develop, testers don't know what to test, and the business doesn't get what it needs on time or in budget. Recent books, along with widespread adoption of techniques such as use cases and eXtreme Programming, have focused greater attention on requirements clarity; but creep persists despite these advances. Much of creep is due to conventional approaches' failure to adequately understand and address the REAL, business requirements content . This interactive workshop reveals the critical role of business requirements and their important differences from what people conventionally assume are the requirements. The workshop also describes ways to discover what the business really needs , including use of the powerful Problem Pyramid™ tool that keeps efforts on track so requirements in fact produce value for the customer/user. Using real examples, participants experience first-hand appreciation of what business requirements are and learn ways to discover and document them that can speed development, reduce maintenance, and delight customers.

COURSE AGENDA

  • Relation of requirements to value
  • Who needs to know the requirements
  • How and when they usually find them out
  • Common definition approaches
  • Management commandment
  • Typical tester involvement, after-the-fact
  • Use cases, business events
  • Seldom recognized use case weaknesses
  • Business rules
  • Quality factors
  • Conventional view of business requirements
  • Major cause of scope/requirements creep
  • REAL, business requirements are differentRelation of requirements to value
  • Who needs to know the requirements
  • How and when they usually find them out
  • Common definition approaches
  • Management commandment
  • Typical tester involvement, after-the-fact
  • Use cases, business events
  • Seldom recognized use case weaknesses
  • Business rules
  • Quality factors
  • Conventional view of business requirements
  • Major cause of scope/requirements creep
  • REAL, business requirements are different
  • Do users really not know what they want?
  • How attitudes unwittingly hide user needs
  • Who should do it: business or systems?
  • Why requirements must be discovered
  • "As is" and "should be" processes
  • Finding the value
  • Problem Pyramid™ tool to get on track
  • Guidelines to identify the REAL problem
  • From problem to REAL requirements
  • Horizontal processes and vertical silos
  • Data gathering techniques
  • Surveys and questionnaires
  • Joint Application Development (JAD)
  • Research and existing documentation
  • Observing/participating in operations
  • Prototyping and proofs of concept
  • Interviewing
  • Formats to aid understanding of the data
  • Business rules, structured English
  • E-R, data flow, flow, organization diagrams
  • Data models, process maps
  • Performance, volume, frequency statistics
  • Sample forms, reports, screens, menus
  • Formats for communicating requirements
  • 7 guidelines for documenting requirements
  • Top-level requirements and project scope
  • Iterating to avoid analysis paralysis
  • Conceptual system design solutions
  • Expanding to detailed deliverables