Requirements Analysis Using Event/Response and Use Cases: Business Events

Planning

For the purpose of this analysis approach, “Business Events” are anything that occurs that causes your “business” to initiate a business process. Defining all of the Business Events in scope will lead to discovery of the business process in scope.

There are three main types of Business Events:

  1. External: These come from outside of your business and you have little or no control as to when or how often these events occur. Examples are “Customer purchases Product” or “Associate requests time off”.
  2. Temporal: These events happen at regular predetermined intervals. These intervals are required, they are not a business or design decision. Don’t let technology limitations determine the interval. Good Example: “It is time to file quarterly taxes”. Bad Example: “Every two hours the HR system sends employee information to the Financial System”.
  3. Data/System State: Occur when the data or system reaches a predetermined condition. These are usually Business Rules or Policy decisions. Example: “Product is re-ordered when the inventory level reaches 5”.

The input arrows on the Context Diagram are the starting point for event discovery. In the next post I will define the elements of the “Event List”.

Advertisements

Requirements Analysis Using Event Response / Use Cases: The Event Model

Planning

The Event Model looks at the scope of your project as if this business function is being outsourced to a third party business and your Executive Sponsor is the CEO of that business. This is the new way of thinking about requirements that I referred to in the Overview post.

The Event Model consists of the following elements:

  • The Context Diagram – shows your business boundary as a circle in the center of the diagram with your suppliers, customers and information flows surrounding the center circle. I will present this in detail in the next post.
  • The Event/Response Model – this contains the detail of the events that “wake up your business” and requires the business to have a planned response. It is progressively elaborated in conjunction with the Context Diagram. More on this in a future post.
  • Use Cases – are derived from the Event/Response Model and show the specific steps required for each business response. At the end of the requirements analysis, this becomes (or is the basis for) your “Business Standard Operating Procedures Manual”. Functional Requirements are derived from the Use Cases.

An important thing to remember when creating the Event Model is to keep it independent of technology. It needs to address “what we do” and not “how we do it”. Doing this will help you envision more design alternatives than you would if you locked in a solution at the requirements level.

In the next post I will give you a closer look at how to create a Context Diagram and utilize it to get the requirements discovery rolling.

Requirements Analysis Using Event/Response and Use Cases: Analysis Sequence

Planning

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.

Requirements Analysis Using Event Response and Use Cases: Overview

Initiation

This is the start of a multi-part series on my favorite requirements elicitation technique: the Business Event/Response Analysis. Early versions of this methodology were developed in the late 1980’s by some of the great system development minds of that era. Since then it has evolved and I have adapted it to meet the needs of whatever organization for which I am working.

There are some that think you can gather requirements by just asking the sponsors and users “what do you want?”. Needless to say, this method will generate incomplete requirements and tends to start and end with functional requirements. In the latter half of the project when large requirements gaps are discovered, the sponsors/users blame the analyst and vice versa.

When I teach on this topic, I tell the analysts it is their responsibility to gather complete requirements. Given this, we need a method that will (1) generate the appropriate questions to ask, (2) ensure that we have the complete set of requirements, and (3) allow us to derive the functional requirements from the model.

The Business Event/Response method meets these desired outcomes. The advantages are:

  • It helps the Business Analyst create the questions needed to draw the requirements from the Business Owner, even if the Analyst has no knowledge of the business area.
  • It organizes the requirements in the context of Business Processes and Usage to promote better understanding.
  • The output serves as a starting point for defining the testing scope and scenarios.

In the upcoming posts I will describe this method in detail.

Requirements Elicitation Techniques Part 5 – Data Modeling

Planning

Data modeling is a complex topic. Becoming a professional data modeler takes months or years of education plus practical experience. It is not my intent to teach data modeling in this brief post, but to show how it related to requirements elicitation.

I introduced some of the concepts of data modeling in Part 4 of this series, “Business Rules Analysis”. The relationships between entities are the business rules and they are fixed in the structure of the data. Examples of these rules are “A Customer lives at one or more Addresses” and “An Address may contain one or more Customers”.

Entities can be found in the nouns in your requirements. They are people, places and things about which the organization wishes to store data. In the example above, “Customer” and “Address” are entities and are therefore capitalized in the rules statements.

Attributes are the elemental pieces of data that are associated with each Entity. In the logical data model, each attribute must be stored with one and only one Entity. The logical data model represents the business Entities, Attributes and Relationships without regard to physical implementation.

The physical data model represents how the logical data model will be implemented in a relational database. Here are two examples of the differences between the logical and physical data models:

  • In the logical model, you can have “many to many” relationships as in the Customer / Address example above. In the physical model you cannot implement many-to-many relationships, so there would need to be an additional table to store each Customer / Address combination.
  • In the logical model,  Attributes belong to one and only one entity. In the physical model, attributes can be included in multiple entities due to inclusion on table keys or for performance reasons.

The data is an important part of requirements gathering. It is an important tool in Event Discovery, as you will ask data related questions such as “What does having this data allow you to do?” and “If I took this data away, what would it prevent you from doing?” I would recommend all Project Managers at least be able to read and understand an Entity-Relationship diagram.

Requirements Analysis Using Event/Response and Use Cases – Final Summary

Planning

In the preceding posts, I gave you some guidance on how to execute the Event/Response methodology for scope and requirements analysis. In this last of the series of posts on this topic, I will take the 5,000 foot view and put it all together in a summary of steps.

  • Step 1 – Define the Business Objectives (the measurable benefits realized after implementation). These will be used to verify the scope and requirements.
  • Step 2 – Define the Project Objectives (the products, services and/or results delivered at project implementation). These will also be used to verify scope and requirements.
  • Step 3 – The Context Diagram. Look at the area under study as an outsourced business, with Suppliers (of data) and Customers (recipients of data/information/results).
  • Step 4 – The Event List. This represents your “business model”. You define all of the events that “wake up” your business and require a planned response. In the prior posts, I presented a variety of techniques for fleshing out these events. Included in the Event List are your business processes and stakeholders.
  • Step 5 – Validate the Event Model. Compare your event scope with the Business and Project Objectives and verify with the Project Sponsor that all objectives are covered by this scope.
  • Step 6 – Construct Use Cases. Use the defined business processes in the Event Model as the starting point for creating Use Cases.
  • Step 7 – Test Planning and Execution. The Event Model is a wonderful framework in which to define your test scenarios and cases. Take advantage of all the work you did in the requirements phase to make your test planning and execution easier.

That’s it for this topic. I hope you found it informative and useful. I have used this technique successfully in many real-world projects.

Requirements Analysis Using Event/Response and Use Cases – Test Planning and Execution

Planning

In addition to being a great way to elicit the complete scope of a project, the Event/Response methodology delivers a framework for test planning and execution. When using this methodology, what many call “User Acceptance Testing” can be replaced by the term “Event Testing”.

In my prior posts on this topic, I identified the primary deliverables of the Event/Response methodology as (1) the Event List (containing the event that triggers the response, the origin and data content of the information flow into your “business”, the named processes, the outputs of the processes and the destinations of the outputs) and (2) the Use Cases. You can plan to test by simulating the actual Events, creating the data flows, executing the processes and examining the outputs. The Use Cases give you a good start on creating the data and usage variations for each Event. Doing this yields a direct mapping of the scope and requirements to the test cases and execution.

Note that since the Event List also contains the roles of the actors initiating the events, as well as the roles receiving the outputs, security testing is also built into this framework.

Another major plus of planning and executing the tests this way is that you are testing the system as it will actually be used in context, as opposed to functional testing which tests bits of functionality in isolation.

A recent project of mine used this methodology and yielded 180 Events and over 1,600 test cases. Because of this comprehensive approach, the system was very well tested and only experienced minor problems after implementation.