Welcome!

Professor of Project Management General ,

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.

PMprocess

Advertisements

Requirements Elicitation Techniques Part 2 – Acceptance Criteria

Professor of Project Management Project Planning, Requirements Analysis ,

Planning

If you search the Internet for “Acceptance Criteria” you will see definitions like this: “Acceptance Criteria are the conditions that a software product must satisfy to be accepted by a user, customer or external system.” There are no shades of grey, the condition either satisfies the criteria or not. There are no “90% satisfies”.

Acceptance Criteria should be established before development begins. The reason for this is that the criteria needs to guide the development. If you write them during or after the development, you will just be verifying what was built and not the customer intent.

Like all good business requirements, the criteria should be “what” not “how”. For example, you might state “Upon submission of the completed application a notification is sent to the Director”. You don’t want to state “Upon clicking ‘Submit’ an email is sent to the Director”. Avoiding implementation specifics opens up new possibilities for a design solution.

In many ways, the “Event/Response method” (see my prior posts on this topic) and “Acceptance Criteria” are very similar. With Event/Response, we document a triggering event, the data sent and who sends it, what we do with it, the outputs and who receives them. With Acceptance Criteria, many use the format “Given some precondition, when I do some action, I expect some result”. These are essentially the same things although Acceptance Criteria can be at a lower level (the Use Case and Functional Requirements level).

You do not approach your user or customer and ask “What are your acceptance criteria?”. This will mostly elicit blank stares. You will want to use other elicitation methods such as Event/Response and Use Cases, and the derive the Acceptance Criteria from there. You can do this by prioritizing your requirements (e.g. “priority 1 = must have or cannot go live, priority 2 = can go live without it but must have within 1 month of go live, priority 3 = nice to have if it fits within the budget and schedule”). In this case, priority 1 requirements are the acceptance criteria for go live and priority 2 requirements are the acceptance criteria for project completion.

Some examples of Acceptance Criteria:

  • If I am a System Administrator, I can add, update or delete accounts.
  • I can search for users by last name and can enter a partial string and receive the results of all that qualify
  • I can filter my staff by availability for a given shift

Requirements Elicitation Techniques Part 1 – Overview

Professor of Project Management Project Planning, Requirements Analysis

Planning

In the previous series of posts I introduced my favorite requirements elicitation technique, “Business Event/Response”. Of course there are many other techniques which can act either as complementary to or in place of “Business Event/Response”. The techniques you choose depend on many factors including the type of project, knowledge depth of the Subject Matter Experts (SME), the availability of documentation, time constraints, etc.

A skilled Project Manager that is also a seasoned Business Analyst is a very valuable commodity. I encourage all PM’s to increase their BA ability by reading books, attending webinars and seminars, and putting their new knowledge to practice. There is no substitute for actual work experience in this realm.

Here are the topics I will address in the series:

  • Part 1 – Overview
  • Part 2 – Acceptance Criteria
  • Part 3 – Benchmarking
  • Part 4 – Business Rules Analysis
  • Part 5 – Data Modeling
  • Part 6 – Document Analysis
  • Part 7 – Interviews
  • Part 8 – Non-functional Requirements
  • Part 9 – Observation
  • Part 10 – Prototyping
  • Part 11 – Root Cause Analysis
  • Part 12 – Surveys and Questionnaires
  • Part 13 – SWOT Analysis
  • Part 14 – Summary

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

Professor of Project Management Project Planning, Requirements Analysis , ,

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 & Execution

Professor of Project Management Project Planning , , ,

Planning

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:

  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 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, the system was very well tested and only experienced minor problems after implementation.

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

Professor of Project Management Requirements Analysis , , ,

Planning

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.

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

Professor of Project Management Requirements Analysis , ,

Planning

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.

Requirements Analysis Using Event/Response and Use Cases: Validating the Model

Professor of Project Management Requirements Analysis , ,

Planning

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 opporunity
  • 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.