My Kindle book, “Project Management for the Real World“, is now available in the Kindle Store at
http://www.amazon.com/dp/B089KRDDVN
If you like this blog, you will benefit from reading this book.
Welcome!
The Project Management Institute (PMI) encourages its members to advance the profession. One of the ways to do this is by helping others increase their project management skills. The target audiences for this blog are professional PM’s early in their careers as well as those who manage projects but are not PM’s by title or trade. I will be posting every week or so, offering practical tips and tools on the full range of project management topics. I hope you will find this useful and help you advance your career.
Requirements Analysis Using Event/Response And Use Cases – Test Planning And Execution
In addition to being a great way to elicit the complete scope of a project, the Event/Response methodology delivers a comprehensive 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:
- 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
- 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 and processes, as well as the roles receiving the outputs, security testing can also be 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, this complex system was very well tested and only experienced few minor problems after implementation.
A reminder that my Kindle book “Project Management For The Real World” is available at
Requirements Analysis Using Event/Response And Use Cases – Functional Requirements
In my previous post on the topic of Requirements Analysis, I showed you how to derive your Use Cases from the Event List. I also presented a list of recommended elements to be included in each Use Case. The primary element is the list of steps taken by the Actors and the System they interact with. Within these steps are the Functional Requirements.
In my initial post in this series, I mentioned that starting and ending requirements gathering with functional requirements was not very effective. Why? Because functional requirements are at too low of a level and places the burden on the memories of SME’s (Subject Matter Experts) instead of the analytical questions of the Business Analyst, where the burden really belongs. For large systems, if you start and end with functional requirements you will almost assuredly have an incomplete set of requirements.
Using the Event/Response methodology, we started with Event Discovery, using a wide variety of techniques to generate the questions the Business Analyst needs to ask. We fleshed out the Events, which led to discovery of the business processes in scope. We validated the model to make sure we had the complete list of Events and processes. We used the processes to create our Use Cases. We will now examine the Use Cases to derive the functional requirements. This is an organized, top down approach to requirements that will output as complete a set of requirements as is possible.
Within the steps of the Use Cases are things like “Insert Debit Card”, “Read Card”, “Select Action”, “Browse by Last Name”, etc. These are all functional requirements that must be satisfied by the solution. The system design must address all of these requirements. However, these are low-level capabilities and are not a good source for overall system design. By using the Event Model, the system designer can see the big picture and design a friendlier, more efficient system than is possible using just the functional requirements.
In the next post I will address the advantages of the Event Model when designing and executing tests.
A reminder that my Kindle book “Project Management For The Real World” is available at
Requirements Analysis Using Event/Response And Use Cases – Building Use Cases
Now that you have a complete and comprehensive Event List, you can now use this to create your Use Cases. Before I show you how, let’s first define “Use Case”:
- A Use Case is simply a list of steps to achieve a goal
- It may have multiple paths (for example, the Use Case for getting cash from an ATM has the normal path, plus an alternate path for the case where a user asks for more money than in their account)
- A Use Case Scenario is a specific path thru the Use Case
Column 4 of the Event List (“…Then We Do This”) contains the names of all of the business processes within the scope of your project. Take each of these process names and create the corresponding Use Cases. Here is a collection of data elements which you can include in the Use Cases:
- Use Case Name and ID (you can use a scheme such as capital U + the Event Process ID + decimal point + the Use Case sequential number. For example, U2.1.1)
- Use Case brief description (The process name and perhaps an additional clarifying sentence or two)
- Sub-System Name (e.g. “Accounts Payable”)
- Triggering Event (from the Event List)
- “Actors” (Stakeholders that interact with or are affected by the Use Case; Your Event List is a great starting point for identifying your Stakeholders)
- Pre-conditions: What needs to be true before the execution of this Use Case (for example, “Customer ID has been established”)
- Post-conditions: The state of the system after execution of the Use Case (for example, “Employee has possession of a company credit card”)
- Process Flow. Include a column for the Actors and a column for the steps executed by the Actors and the System. Do this until the process is complete and accomplishes the Post-conditions.
In the next post I will discuss deriving Functional Requirements from the Use Cases.
A reminder that my Kindle book “Project Management For The Real World” is available at
Requirements Analysis Using Event/Response And Use Cases – Validating The Model
In the prior posts on “Event Discovery”, you completed your initial Event Model. I say “initial” because in the process of validating the model, you may discover additional events.
In order to validate the model, you first compare it to your Project Objectives (the implementation deliverables that survive and are maintained after the project is considered complete). For each Project Objective you need to ensure that you have one or more Events and Business Processes that will contribute to reaching that objective. If you don’t find at least one, you are missing at least one event and must cycle back to event discovery to find it or them.
When you are finished validating against the Project Objectives, you will then validate against the Business Objectives. As a reminder, Business Objectives…
- Contribute to the business strategy
- Make or save money
- Take advantage of opportunity
- Provide competitive advantage
- Respond to new laws and regulations
- Are measurable
Compare the Event Model against the defined Business Objectives and ask the Core Team and the Project Sponsor if this scope will directly or indirectly address the objectives. If one or more objectives are not addressed, then you will continue with event discovery until you are satisfied the Business Objectives are satisfied by the model.
In the next post I will present how Use Cases are derived from the Event Model.
Note: My Kindle book “Project Management For The Real World”, is available at
Requirements Analysis Using Event/Response and Use Cases – Event Discovery Part 7
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.
Note: My Kindle book “Project Management For The Real World”, is available at
Requirements Analysis Using Event/Response and Use Cases – Event Discovery Part 6
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.
Note: My Kindle book “Project Management For The Real World”, is available at
Requirements Analysis Using Event/Response And Use Cases – Event Discovery Part 5
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.
Note: My Kindle book “Project Management For The Real World”, is available at
Requirements Analysis Using Event/Response And Use Cases – Event Discovery Part 4
This is Part 4 in my series on Event Discovery techniques. In this post, I will describe how to use the major entities that you have identified as a starting point.
In the course of your requirements analysis you will have identified some entities for which you will be required to keep persistent data (these entities will translate into tables in your database when you are in the Design Phase). For each of these entities, you can discover the life-cycle (and therefore, the Events) by asking these questions:
- What are the Create Events for an instance in this Entity? These are the Events in which your “business” first becomes aware of a specific instance of this Entity, and stores initial data.
- What are the Read Events for an instance in this Entity? These are the Events that trigger usage of the data for this Entity without modifying the data.
- What are the Update Events for an instance in this Entity? These are the Events which cause any of the data elements stored for this Entity to be modified.
- What are the Delete Events for this Entity? These are the Events which cause “end of life” (defined as “there will be no more need to read or modify this instance”) for an instance in this Entity.
An acronym sometimes used for this analysis is “CRUD” (Create, Read, Update, Delete).
Here are some examples:
Let us say the scope of our “business” is to add the selling of refrigerated beverages in retail stores. Some Entities you might have identified are “Store” and “Product”. Let us examine each of these using CRUD.
For “Store”:
- The Create Event might be “Store is opened”. That would lead you to ask questions such as “How do we get refrigerators to new stores?” and “How do we get the initial inventory of product to new stores?”. The answers lead to more Events.
- Some Read Events are “Inventory or Sales requests by Store, Region, or Territory”.
- Some Update Events can be “Store temporarily closed for remodel” or “Store commencing a going out of business sale”. This would lead you to ask questions such as “What do we do with existing inventory of refrigerated product?”.
- A Delete Event would be “Store is closing”. This leads you to questions such as “What do we do with the refrigerators and the inventory contained within?”
For “Product”:
- The Create Event could be “Product is ordered”. This would lead you to ask questions such as “How do you know you need to order product?” and “How do you know how much of each type to order?”. The answers will certainly lead to new Events.
- A Read Event might be “Requests for Sales by product type”.
- Some Update Events are “Product is sold” and “Product is restocked”.
- A Delete Event could be “Specific Product type discontinued”.
Keep doing this for all of your identified Entities. You may be surprised how enlightening this is, revealing many Events that other forms of analysis would miss. Keep in mind, once you have identified new Events and added them to your Event List, you will fill in the detail for each column in the list and do the analysis of the Event Outputs described in a prior post.
In the next post I will describe how to use the data elements in the Entities to discover more Events.
Note: My Kindle book “Project Management For The Real World”, is available at
Requirements Analysis Using Event/Response And Use Cases – Event Discovery Part 3
This is the third part in the series on Event discovery. In the first two parts I covered discovering Events using (1) the Context Diagram and (2) the Outputs listed on the Event List. In this post, I will cover using a technique known as “State-Transition”.
In specific cases of analysis where there is a central entity that moves to a variety of “states” during its life, the State-Transition diagram can be very useful in discovering Events. Let us take the example of a retail product where the project sponsor wishes to track the product in all of its possible states. The following are possible examples of the states of this product:
- Designed
- Ordered
- Manufactured
- Shipped / In-Transit
- Arrived at Distribution Center
- In Inventory
- Allocated to Store
- Packed
- Shipped to Store
- Arrived in Store
- Available for Sale
- Sold
Each of these states has a corresponding Event that causes the product to transition from one state to the next. For example, the transition from “In Inventory” to “Allocated to Store” could be triggered by the data event “Store Inventory Level for this Product drops below reorder point”. Now that you have the Event, you can fill in the rest of the row on the Event List in discussion with the SME’s (Subject Matter Experts).
Note that it is possible and allowed for an Entity in a given State to transition to more than one possible State, depending on the Event. For example, an Employee can transition to a new job (via promotion or transfer) or transition to full-time or part-time, or transition to terminated.
Knowing all of the relevant States of an Entity can be very useful to filling out the Event List in certain analysis situations.
In the next post, I will present another Event discovery technique involving the life cycle of key Entities.
Note: My Kindle book “Project Management For The Real World”, is available at
Requirements Analysis Using Event/Response And Use Cases – Event Discovery Part 2
In the previous post I discussed how to use the Context Diagram for initial Event discovery. In this post I will present how to use the outputs from your Event List to discover more events.
The fifth column in your Event List (the one labeled “Which creates this…”) are the outputs of your business processes. You can use these outputs to discover more Events by asking the following questions for each output:
- Does the output go to a “Customer”? (an entity outside of the center bubble in the Context Diagram). If yes, then that is where the output ends. If no, then that means it must be input to another event or the output has no purpose. Ask your SME’s (Subject Matter Experts) what other business processes use this data. For each identified business process, you can flesh out the Event List row for that process.
- What are the “Create” Events for this output? These are the Events that result in the establishment of a new row (or rows) of data in the output in question. For example, the sale of a product creates a Sales Transaction record. Note there may be more than one Event that creates rows in this output.
- What are the “Change” Events for this output? For this you may need to examine each data element in the output. For each element, ask the SME’s what business processes change this data. Use these answers to continue to build the Event List.
- What are the “Delete” Events for this output? These are the Events that result in the logical or physical removal of a row in the output. For example, if the record retention requirement for the output is 5 years, then the time-based event “Record Retention Limit Reached” will be added to your Event List.
Now that you have added many more rows to your Event List, you will have more outputs to examine. Cycle back thru the Event List outputs and ask the same questions listed above. You will find your Event List grows very quickly!
In the next post I will continue to present additional techniques for Event Discovery.
Note: My Kindle book “Project Management For The Real World”, is available at
