Getting requirements right is a process. Your business stakeholders will rarely (if ever) be able to give you all of their requirements without some method of generating relevant questions to draw the requirements from them. What I am going to present in this and the following posts on this topic is NOT a new way to document your old thinking. It is a new way to think about requirements.

The deliverables created from this approach are:

• Identification of all processes in scope
• Documentation of the specific Use Cases for each process
• Identification of all of the stakeholders that interact with the business processes
• Creation of a framework with which you can generate and execute your test cases

Many analysts start and end their requirements elicitation with “functional requirements” (e.g. “I need to search by Last Name” or “Requests for time off need to be approved by the manager”). In the Event/Response/Use Case approach, functional requirements are derived from the Use Cases at the end of the analysis process.

The analysis sequence is as follows:

• Business Objectives
• Project Objectives (1st cut)
• Event Model
• Project Objectives (verified)
• Use Cases
• Functional Requirements

In the next post, I will discuss how the Business and Project Objectives are defined and used in the Event/Response methodology.