Month: September 2018

Requirements Analysis Using Event/Response and Use Cases: Elements of the Event List

Professor of Project Management Requirements Analysis ,

Planning

I recommend setting up the Event List using Excel. Remember, when I refer to your “business” it means the scope of the area under study. Here are the columns you will need along with their descriptions:

  • Event ID – use a numbering system for your Events so they will be easy to track thru design and testing. I use a scheme where the main number puts the event in context and a number after the decimal point is just a sequential number within that context. For example, Event ID 3.1 where “3” represents sales events and “.1” is the first event in that context.
  • “When This Happens” – this is a brief description of the event that causes your “business” to react with a planned response. For example, “Customer initiates check out”.
  • “This Source” – one or two nouns describing the entity responsible for directly providing data/information to your “business”. Examples are “Associate” or “Customer”. This will match your “Suppliers” on the Context Diagram.
  • “Gives us This” – a brief description of the data/information being provided. Examples are “Time off request” or “Product ID”. This will match the input arrows on your Context Diagram.
  • “Then we do this” – the name of the business process(es) you will execute to respond to this event. For example “Time off request approved/denied” or “Record Sale”.
  • “Which Creates This” – the permanent output(s) of the business process(es). For example “Time off approval” or “Product Inventory Update”. This will match your output arrows on the Context Diagram.
  • “And is Given to…” – The recipients of the output(s). These could be systems, departments, roles, or vendors. This will match the “Customers” on your Context Diagram.

Remember to keep the event items free of technical and implementation jargon. Note my example “Customer Initiates Check Out”. This could be in a store, online or some other means. The “How” will be decided later, in design, and not here.

In the subsequent posts I will show how to do Event Discovery to elicit a complete set of requirements.

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

Professor of Project Management Requirements Analysis , ,

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 Context Diagram

Professor of Project Management Project Planning, Requirements Analysis ,

Planning

The Context Diagram is the place to start when doing your analysis. It should be done in conjunction with the stakeholders that are most knowledgeable about the business processes for the domain under study. The initial list of Business Events will be derived from the Context Diagram.

Start with a circle in the middle of the diagram. This represents the area of the business in the scope of the project. All of the processes within this circle are in scope and are able to be modified or added to as part of the project scope. Think of it as if this business function were outsourced to a service provider and the Executive Sponsor of the project is the CEO of this service provider. What would they need to know to create a business model?

First, you would want to define “who are my Customers?”. Your Customers are recipients of your business’s outputs (in most projects, these are flows of information and data). Ask the key stakeholders “who are the current recipients of information your business function?”. Draw the Customers as rectangles on the right hand side of the diagram. It is not important at this time that you have the complete list of Customers, only that you have some. We will complete the list of Customers in an iterative process in conjunction with the Event/Response Model.

Next, define the types of information that flow to each Customer. Draw these as arrows from the center circle and connecting to the Customer rectangle. Have a short, high level description of the flow on each arrow.

After that you need to define “who are your Suppliers?”. The Suppliers are providers of the business’s information and data. Ask the key stakeholders “who are the current providers of information for your business function?”. Draw the Suppliers as rectangles on the left hand side of the diagram. It is not important at this time that you have the complete list of Suppliers, only that you have some. We will complete the list of Suppliers in an iterative process in conjunction with the Event/Response Model.

Next, define the types of information that flows from each Supplier. Draw these as arrows from the Supplier rectangles and connecting to the center circle. Have a short, high level description of the flow on each arrow.

Rules for Suppliers and Customers:

  • They can be individuals, roles, departments, organizations, systems, vendors, etc. Anything that is a net originator or receiver of data or information from your “business”.
  • Some entities can be both Suppliers and Customers. so they will have arrows going in both directions.
  • If you are struggling with whether a Supplier or Customer is inside or outside the circle, the general rule is for entities outside the circle, the project has no control over their processes. The project can only change the nature and content of the information flows to and from these entities.
  • There are no flows represented that go from entity to entity. They may exist but they are of no concern to the project.

Here is an example of a Context Diagram:

Context_Diagram