Requirements Analysis Using Event/Response and Use Cases: Event Discovery Part 7

Planning

The posts in this series so far have covered identifying External Events, which in most cases will constitute the majority of your Events. There are two other types of Events you also need to identify:

  • Time-based Events
  • System State Events

To identify Time-based Events you can simply ask your SME’s (Subject Matter Experts) if there are any processes that run based on time (e.g. “every X hours/days/weeks/months”, “First Monday of every month”, “Every other Friday”, etc). Some Events that run based on time are only done so due to technical limitations, either real or perceived. You do not want to classify these Events as time-based. For example, if they say “We run an interface from our HR system to our Time-Keeping system every two hours”, that is a choice, not a requirement. In an ideal world, those two systems would always be instantaneously in sync. Do not let technical limitations limit your requirements.

An example of a good time-based requirement is “We submit monthly tax reports to state and local governments”. The timing is a requirement of External Entities and must be honored.

System-State Events can be identified when you are reviewing the relevant data elements. You can ask if any change in the value of an element automatically triggers a process. For example, in an inventory system a System-State Event might be “When the on-hand quantity reaches 5, a reorder is triggered”. In an HR system, a promotion would trigger events related to pay, benefits, organization, etc.

Once you have added the Time-based Events and the System-State Events to the External Events in your Event Model, it is time to validate the model. That will be the subject of Part 8 in this series.

Requirements Analysis Using Event / Response and Use Case: Event Discovery Part 6

Planning

For those of you that are familiar with Data Modeling, there is a technique you can use involving the Entity Relationships that can help you discover events you may have missed. Entity Relationships are part of the Business Rules and are expressed in terms such as “A Customer may purchase one or more Products” and “A Product may be purchased by zero, one or more Customers“.

Whenever the term “zero” is expressed in an Entity Relationship, that is of special interest to the Business Analyst looking to discover events. In the above example, where a Product does not necessarily have to be purchased, that could lead you to questions such as “Is there an expiration date? If so, what then?”, or “Is there a point which the price is reduced to induce sales?”.

Also in the example above, the Customer-to-Product relationship did not have the “zero” (at least on the first pass at the model). Event Analysis may help you discover zero relationships where one was not initially defined. For example, you could ask the SME’s (Subject Matter Experts) “Can a Customer be someone who has not purchased a product?”. That goes to the very heart of what the organization considers a “Customer”. One answer might be “Well, we allow people to sign up for our mailing list even if they haven’t purchased anything yet”. In this case, that person is a Customer, so the relationship is revised to state “A Customer can purchase zero, one or many Products“.

Once you know the events that define that zero relationship you can ask follow up questions such as “Is creating and maintaining a mailing list in the scope of this project?”. I have found exploring these zero relationships very valuable in real world projects.

Requirements Analysis Using Event Response / Use Cases: Event Discovery Part 5

Planning

This is Part 5 in my series of posts on Event Discovery. The technique I present in this post is very effective in cases where you know little or nothing about the business area under study.

Using the methods presented in my prior posts, you are able to discover Entities (e.g. “Customer”, “Sale”, “Store”, etc.) for which you need to store persistent data. As you flesh out the data needs for each Entity, here are some powerful questions that enable you to discover more events:

  • For new data elements (i.e. data that is not currently being captured in the existing system), ask “Why do you need this data? What will it enable you to do?”. The answers will be business processes that can be entered on the Event List. Once you have at least one cell of information for a row on the Event List, you can fill in the rest of the row with the relevant questions. For example, if the new piece of data is “Customer Mobile Phone #”, your business partners may say “We want to conduct text message marketing campaigns”. That answer leads you to the questions on the Event List such as “What Event starts a campaign”, “What is the input data and who/what provides it”, “What are the business processes”, “What are the outputs and who/what receives them”.
  • For existing data elements (i.e. data that is currently captured by the existing system) ask “If I took this data away from you, what will it prevent you from doing?”. This is a question that will get your business partners to think deeply about the answer, as the thought of losing something usually heightens awareness. For example, if the data element in question is the Employee Address, this may prompt your business partners to reveal all of the direct mail items sent to an Employee (an example would be “Start or open enrollment for benefits), and these would have corresponding events that initiate them.

The Event Discovery series continues in the next post.

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

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.