Author: Elizabeth Larson

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is a consultant and advisor for Watermark Learning/Project Management Academy, and has over 35 years of experience in project management and business analysis. Elizabeth’s speaking history includes keynotes and presentations for national and international conferences on five continents. Elizabeth has co-authored five books and chapters published in four additional books, as well as articles that appear regularly in BA Times and Project Times. Elizabeth was a lead author/expert reviewer on all editions of the BABOK® Guide, as well as several of the PMI standards. Elizabeth enjoys traveling, hiking, reading, theater, and spending time with her 6 grandsons and 1 granddaughter.

A PM’s Guide to Use Cases – Part 3: Use Case Narratives

Written by Elizabeth Larson on December 8, 2015. Posted in Articles. 6 Comments on A PM’s Guide to Use Cases – Part 3: Use Case Narratives

As promised, this is the fifth article in our modeling series and the third on use cases. We’ll start with a short summary of the main concepts covered previously.

Summary of previous articles

Here are the highlights of the requirements modeling articles written to date:

To get good requirements, we need to ask the right questions. We need to ask both high-level consultative questions to determine the true business need, as well as questions about the features, characteristics, and functionality needed to develop the end product (solution). Modeling helps uncover requirements related to these product features and functions. Asking questions enables us to model the requirements. Modeling requirements, in turn, uncovers gaps that lead to further questions and ultimately helps us deliver the product that our stakeholders want and expect. See previous article at: http://www.projecttimes.com/elizabeth-larson/a-project-managers-guide-to-requirements-modeling.html
A model is a representation of reality, like a model car, airplane prototype, or graphical design (e.g., a CAD drawing) of a house. As they relate to requirements, models usually consist of text, graphics representations, or both. See http://www.projecttimes.com/elizabeth-larson/a-project-managers-guide-to-requirements-modeling.html
As PMs we might not do business analysis work ourselves, but we need to ensure that work is done. So it’s important for us to be able to have enough understanding of these models to ask the right project questions of the resources who will be doing the elicitation and modeling. Refer to http://www.projecttimes.com/elizabeth-larson/a-pms-guide-to-requirements-modeling-part-2-concurrent-requirements-modeling.html
There are different categories of requirements, including data and process. Use cases describe a third category—interaction. When we use any kind of user interface, such as a mobile phone app or enter any information into any screen or web page, we are interacting with the “system.” Use cases describe this interaction between us (actors) and the system. See http://www.projecttimes.com/elizabeth-larson/a-pms-guide-to-use-cases-part-1-what-is-a-use-case-and-why-should-pms-care.html
In other words, a use case describes the conversation back and forth between actors and a system. The system contains all the work we want to do on the project, and a use case diagram is useful in helping us determine this scope of work as it relates to the final product. Actors always interact directly with the system, but are always outside the system. They can initiate a use case, provide input to it, and/or receive outputs from it. Actors can be people, other systems, time triggers, or event triggers. http://www.projecttimes.com/elizabeth-larson/a-pms-guide-to-use-cases-part-1-what-is-a-use-case-and-why-should-pms-care.html
Use cases help our projects in two very different ways. Use case diagrams are immeasurably helpful in understanding scope and the use case narrative is invaluable for getting the detail needed to build the product or service. Although used primarily in software development, use cases are also helpful when creating processes and developing equipment. They work wherever there is interaction between people and what those people need to do. Refer to: http://www.projecttimes.com/elizabeth-larson/a-pms-guide-to-use-cases-part-1-what-is-a-use-case-and-why-should-pms-care.html
Use case models contain the use case diagram that we described in the last article and a textual description of each use case shown on the diagram. We have described the diagram in great detail in the last two articles. Here we will describe the purpose of the use case narrative, the five questions these narratives help answer, and how invaluable this information is to both the business stakeholders and development team.

Use Case Narratives

The use case diagram shows the use cases, which are the features contained in the system. Each use case is shown as an oval and named as a-process with a verb to describe the action, such as Request Item or Ship Item. Use case narratives describe the process steps inside each use case. The narratives are needed because while it is great to see the features at a glance, no one really understands what these process names mean until we describe the detailed steps. If we told a developer to build a feature and all we gave them was the name “Request Item,” they would have to ask tons of questions and/or make lots of assumptions about how people would interact with the system when they wanted to request items from a website. We have found that those developers who actually read them love these narratives because they save so much time.

Below is an example of a use case narrative that describes the process steps involved in reserving an item in inventory in an Order system. To create the narrative we include the following:

A number and name that identify the use case. These are often assigned according to the organization’s standards, templates, and/or requirements processes.
The pre-and post-conditions describe the scope of each use case. Since each use case begins and ends, we need to tell it where to begin and when to end.
A matrix with what the actor does and how the system responds to each actor request.
Primary, alternate, and exception flows, which we explain below.

Below is an example of a use case narrative. The numbers on the use case narrative correspond to five important questions that use case narratives answer and which are listed below the narrative example.

Figure 1 – Example of a Use Case Narrative

At what point is the use case ready to begin? That is, what has to occur before the use case process can begin? Our example is about what the system does to reserve an item in inventory after it has been requested by a customer. When does this use case begin? Is the customer already logged in? Can they reserve items without being identified as a customer? These are business rules that have to be answered by stakeholders. Is the system available? Which user interface (screen/web page) are they on? The use case pre-condition answers this important question and if it is not known when the developers start working on it, they will struggle and lose time arguing about it.
When is the use case complete? In other words, when is done “done?” What do we mean by complete? That’s another tricky question to answer. The use case narrative answers this question in the post-condition(s). The post-condition(s) together with the pre-condition set the boundaries of the use case. Again using our example, is the use case done when the item is shipped to the customer? When the item information is sent to the warehouse for packing and shipping? We don’t know and we should not assume. If the use case is about reserving items in inventory, shipping the item to the customer is clearly out of scope for this use case, although in scope for a different use case, one relating to shipments.
What is the most common way of getting from the beginning of the use case to the end? That is, from the pre- to the post-condition. This is our primary path, sometimes known as the happy path. Let’s have a quick peek at the happy path. We always start with the actor action and always end with the system response, or how the system responds to the actor request. The system response lists all the process steps in response to an actor action until another actor, if any, triggers another response from the system. These steps continue until the post-condition is reached.
What other ways can we get from the beginning to the end? These are our alternate paths. We’ll reach our post-condition, but not in the most routine way. That is, we’ll take a different route. Sometimes we return to the main path, sometimes not. In the above example, we return to the primary path.
What might prevent us from reaching our post-conditions? These are our exceptions. Exceptions take us off the path entirely and terminate the use case.

To better explain this example, let’s use the example of getting home from work—in this case by car. Let’s say that our pre-condition is that we have left our office building. Our post-condition is that our car is parked in our garage at home. Our routine way to get home is to drive on the interstate. Some days, however, the traffic is so bad that we take side roads. We still get to our post-condition, just in a different way. This path, then, is the alternate path. However, let’s say that we try to start the car and the car won’t start and has to be towed some place for repairs. That is an exception that prevents us from reaching the post-condition.

Test scenarios, acceptance criteria, and “Given-When-Then”

The three narrative flows are similar to test case scenarios. One of the advantages of taking the time to create use case narratives is that test scenarios will be pretty much complete as well. In addition, the post-condition(s) will help us determine the acceptance criteria. Finally, many Agile projects use a “given-when-then” format to help with testing. The use case narratives provide this information. The “given” is the pre-condition(s), the “when” are the actor actions, and the “then” are system responses. Let’s refer to our use case narrative example.

Given that the system is available, the customer is logged on, and that the customer has navigated to the page to enter line items, when the customer enters the item number, then the system verifies the number with a digit check verification, and so forth.

Summary

Use case narratives take time to create. However, it’s not creating the model that takes the most time. It’s the thought process about the interactions between actors and the system that take the most time. The time that it takes to think through these interaction steps is time that has to happen regardless of what format is used to document it. Use case narratives provide a structured way to get us through the thought process, helping us ask the necessary questions, and giving us complete interaction requirements, which are needed to build a solution that works for our stakeholders.

A PM’s Guide to Use Cases Part 2 – : Use Case Diagrams Explained

Written by Elizabeth Larson on November 10, 2015. Posted in Articles. 5 Comments on A PM’s Guide to Use Cases Part 2 – : Use Case Diagrams Explained

As promised, this is the third article in our modeling series and the second one on use cases. We had promised that in future articles we would show examples of use case diagrams, explain how to build them, and describe why we should create use case narratives. And yes, we’ll explain how use cases provide the same information as the Given—When–Then format. So here we go!

Summary of previous article

Use cases help our projects in two very different ways. Use case diagrams are immeasurably helpful in understanding scope and the use case narrative is invaluable for getting the detail needed to build the product or service. Although used primarily in software development, use cases are also helpful when creating processes and developing equipment. They work wherever there is interaction between people and what those people need to do.

Use case diagrams are one of several techniques we use to help with both the project and product scope. We find that the use case diagram structures our thinking and helps us remember functionality we might otherwise have forgotten.

In the last article we said we would explain the terms reference in this example use case diagram.

Figure 1 – Use Case Example

Summary of Five Key Terms

In use case diagram example above, there are terms labeled with five numbers. Each one of these numbers represents five questions, the answers to which help us understand requirements, as well as create use cases.

What is our solution? Usually, projects begin with a business need (problem or opportunity) to be addressed, and that need is addressed by a solution. In the world of use cases, this solution becomes our system, and it contains all the work we want to do on the project related to the end product. In other words, the “system” on the use case diagram represents the product scope. In our example, the scope of the banking system includes features and functions that we want to include as part of the solution scope. Let’s keep in mind that the scope of the project is directly related to the scope of the product, so the more complex the solution, the larger the project scope.
Which stakeholders will interact with our system? Using use case lingo, the stakeholders using the system are designated as actors on our diagram. Actors are always outside the system but always interact directly with the system. They can initiate a use case, provide input to it, and/or receive outputs from it. Actor to actor interaction is not described by use cases and can be thought of as business processes, not use cases.
What other systems interact with our system? These are also actors since Actors can be people, other systems, time triggers, or event triggers. Actors, again, whether they are people or other systems, for example, can provide input to our system and receive outputs from the system. For example, a process is kicked off at a particular time, like month-end, it is a time actor. If it is triggered by an outside event, such as the outside temperature causing a change in the thermostat, it is an event actor.
How do these stakeholders want to use the system? These are our use cases, which describe how actors want to use the system. Use cases are high-level processes and are shown on the use case diagram as a process name surrounded by an oval shape. The use case name describes the process at a very high level. In our example diagram, we know that customers and internal banking stakeholders want to have the functionality to perform banking transactions. But unless we examine the steps involved in these processes, we will not be able to understand the real requirements related to the desired functionality. That is, we can see the birds-eye view of the functionality needed, but we will know nothing about each process itself. That is why use case diagrams ae wonderful for an understanding of product scope, but do not provide the detail we need to build the requested features.
Interfaces. The lines between actors and use cases, sometimes known as associations, allow actors to talk to the system and the system to talk back to the actors. For software, these represent user interfaces. User interfaces are screens used to allow data to be both input and displayed. The use case diagram, by showing these interfaces, provides a nice picture of work that needs to be done, since each line, or interface, means a screen or series of screens that needs to be built. Notice that the lines do not have any arrow tips. Interfaces do no show whether the data is input (comes from the actor) or is displayed (comes from the system). Arrows denote dependent relationships, which we will discuss in a future article.

Naming the actors and use cases

Actors. As obvious as it sounds, the user role or function, and not names of individuals are preferred for the actors in the use case. For example, use “Accounting” instead of “Erik.” Although we know that we should not use names, we sometimes forget because everyone knows “Erik.” But what happens after “Erik” has left the organization? Not everyone will remember what his function was.

Use Cases. Remember that use cases are processes. Accordingly we name our use cases as we would any other process, with a strong verb and a noun, that is, an action and an object of the action. Instead of naming the use case “Deposit Function” or “Deposits,” for example, we would label it “Make Deposit” or “Deposit Funds.”

Expect the use case diagram to change

Expect your diagram to change over time. Eliciting requirements, regardless of the model used to record the requirements, is an iterative process. Not only will requirements change, but details of the elicited requirements emerge as we know more. Therefore, it is helpful to use stickies for actors, use cases, and interfaces during elicitation until your diagram stabilizes. It is far less frustrating to move stickies than to redraw the entire diagram every time a change occurs. Similarly, do not spend energy trying to align actors with use cases. That alignment will change as the diagram changes. If is far easier to group actors after the diagram stabilizes. Also, there are tricks for simplifying the diagram when the model becomes complex and with the use of dependent relationships, which we’ll discuss in a future article.

In the next article, we will discuss the importance of a use case narrative and how to create one.

No PowerPoint Slides? How Can I Communicate?

Written by Elizabeth Larson on August 21, 2015. Posted in Articles. 3 Comments on No PowerPoint Slides? How Can I Communicate?

Recently we attended a Small Business Leaders conference in Washington, DC. Our speakers included US senators, cabinet secretaries and undersecretaries, under-undersecretaries, and a few associate assistant deputies thrown in for good measure. It wasn’t until one of these associate assistants told us that we were his first group not to be treated to a PowerPoint slide show that we realized that there had not been one PowerPoint slide in two days—no slides, not one bullet point or photo, no multi-media—just words. To be sure, some of the speakers referred to their notes from time to time, but these were people all knowledgeable about issues confronting small businesses in the United States.

At this point we could make jokes about politicians being too wordy, or government technology being old and broken so they had to rely on old-fashioned notes on index cards, but we had just spent two days talking, in part, about the latest technical advancements. So when the speaker alluded to the lack of PowerPoint slides, we realized in the first place that not one of the speakers had used slides, and in the second that as far as we knew no one missed them.

These speakers talked to us about what they knew, often with humor, always with enthusiasm and earnestness. There were no gimmicks, no extraordinary efforts to be entertaining– just an understanding that we wanted them to share their knowledge, and they, in turn, wanted to learn about the issues that affected us. To put things in perspective, all the presentations were short, with most 15 minutes or less.

Don’t get us wrong–there is nothing wrong with PowerPoint slides, Prezi, or other presentation tools. They help keep us and our audience focused on the session objectives. However, such tools, when improperly used, can also stifle creativity and limit discussion. When we rely on such tools as the primary communication vehicle, we run the risk of telling too much and learning too little. For those of us who facilitate meetings, give presentations, act as mentors and consultants, or train others, to be effective we need to be prepared to address the topics of interest to our audience. We need to make sure that participants participate, and we need to leave time for participant interaction and questions. Let’s look at each one of these in more detail.

Prepare to address topics of interest to our audience. It was clear to those of us at the Small Business conference that most of the speakers prepared (or their staff had) enough to know some of the big topics facing the audience and were able to weave their messages into our issues.

As a project manager that is not always the case. For example, Elizabeth “ran” many meetings with business stakeholders. She says, “I often had an agenda that I felt needed to be completed. I knew what I wanted to get from these stakeholders, and I drove towards that end. Because I was focused on what I needed for the project and not what the stakeholders needed for their end product, the meetings did not always go well.” Preparing means spending the time to talk to stakeholders in advance of a meeting to find out the topics of interest to the participants. We may discover issues that would take the project in unexpected directions. It does not mean that we have to act on all these diversions, but we do need to ensure that our participants feel that they are heard. We need to bring these topics to our sponsors and business owners and let the participants know that we have done so. Parking lots (topics to be discussed at a later time) are often a useful way to capture these digressions, not only during meetings but our prep work as well.

Help participants participate. We found it interesting that there was a great deal of discussion with the conference attendees. This discussion was often lively but took place in a respectful, encouraging environment.
Of course creating that kind of environment is not always easy. There are many things we can do to discourage participation in meetings and workshops. For example, when we go into a meeting with a list of ground rules and view our job as enforcers of these ground rules, we discourage participation. When we require “only one voice at a time,” or dictate that a participant raise their hand before speaking, we can pretty well guarantee that participants will at best forget what they wanted to say or worse yet, shut down. Some of the latest meeting and workshop trends include providing participants with stickies to jot down their ideas as they think of them, setting up easel pads around the room so participants can jot down their ideas at any time, encouraging participants to get up and write or create a visual design on a whiteboard, and when meeting virtually, devising creative ways to ensure that all voices are heard.

Leave time for interaction. At the conference, most of the speakers mentioned the importance of hearing from us. They set aside time for lots of Q & A. In addition, there were several panels and each panelist encouraged questions and comments.

In our experience, agendas are generally too tightly packed. We try to cover more than is possible because we know that the stakeholders’ time is limited. Moreover, when the agenda is presented on a PowerPoint slide, it can give the impression of being unchangeable. This formality increases the risk of trying to cover too much in too short a time and decreases the chance that participants will interact with each other.

It is important for all meetings, and particularly when stakeholders are participating virtually, that all of us take the time to get to know each other. This is even more important when we are planning a series of meetings with the same stakeholders. It is equally important to remember that regardless of the topic or the nature of the meeting, each participant is important and will have questions. We need to learn from the participants, and the best way to do that is by encouraging their questions. Sure, some stakeholders will ask questions that are not directly related to the topic at hand, while others will “grandstand.” Even though their “questions” will be opinions and statements rather than questions, we need to provide an environment and the necessary time where everyone is heard.

Some of the speakers at the Small Business Leaders conference freely admitted that our issues were outside their domain of expertise or authority. Others refocused the group on the conference objectives. But in each instance we felt that we were in a safe environment and were taken seriously. We need to do the same in project meetings.

Next month we will get back to our Modeling Series as promised.

About the Authors:

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is Co-Principal and CEO of Watermark Learning and has over 30 years of experience in project management and business analysis. Elizabeth’s speaking history includes repeat presentations for national and international conferences on five continents.

Elizabeth has co-authored three books: The Practitioner’s Guide to Requirements Management, CBAP Certification Study Guide, and The Influencing Formula. She has also co-authored chapters published in four separate books.

Elizabeth was a lead author on the PMBOK® Guide – Fourth and Fifth Editions, PMI’s Business Analysis for Practitioners – A Practice Guide, and the BABOK® Guide 2.0, as well as an expert reviewer on BABBOK® Guide 3.0.

Richard Larson, PMP, CBAP, PMI-PBA, President and Founder of Watermark Learning, is a successful entrepreneur with over 30 years of experience in business analysis, project management, training, and consulting. He has presented workshops and seminars on business analysis and project management topics to over 10,000 participants on five different continents.

Rich is a frequent speaker at Business Analysis and Project Management national conferences and IIBA® and PMI® chapters around the world. He has contributed to the BA Body of Knowledge version 2.0 and 3.0, the PMI BA Practice Guide, and the PM Body of Knowledge, 4th edition. He and his wife Elizabeth Larson have co-authored three books, The Influencing Formula, CBAP Certification Study Guide, and Practitioners’ Guide to Requirements Management.

A PM’s Guide to Use Cases Part 1: What is a Use Case and Why Should PMs Care?

Written by Elizabeth Larson on May 22, 2015. Posted in Articles. 9 Comments on A PM’s Guide to Use Cases Part 1: What is a Use Case and Why Should PMs Care?

Use case models have been around for decades. Long after Information Engineering was all the rage and through object-oriented analysis and design they hung around. They threatened to disappear when Agile methods gained popularity, but here they are–discussed, dissected, and the subject of many blogs. Aren’t they “old school” and not needed in today’s Agile world?

They are still needed and are, in our opinion, among the most useful tools/techniques practitioners have in their business analysis toolkit. Without going into the historyⁱ, use case models, both the diagram and the narrative text, provide a structured way to think about our work, work that we’ve always had to do in software development, but which has been simplified with use case models.

Although project managers who are not business analysis practitioners do not need to create use cases, they should know what use cases are, be familiar with key terms, and understand why they are important to getting the requirements right.

This series of articles will focus on these key points.

Why use cases?

Use cases help our projects in two very different ways. Use case diagrams are immeasurably helpful in understanding a project’s scope and the use case narrative is invaluable for getting the detail needed to build the product or service. And although used primarily in software development, use cases are also useful when creating processes and developing equipment. They work wherever there is an interaction between people and what those people need to do.

Terms, terms, and more terms

A rose by another name, as we know, would probably smell the same, and use cases if called something else would serve the same purpose. Use cases are so named because they describe how people want to use their software or equipment.

However, it does sound a bit technical. It sounds like the kind of technique that a project manager could easily leave in the hands of more technical resources and forget about. And that would be too bad, because use cases help projects in many ways, as we’ll describe below.

Years ago Elizabeth gave a presentation on use cases. She remembers saying that despite how useful they were, if it had been up to her, she would have called them something else, something less technical and more accessible to business stakeholders. She remembers one upset participant who said that it was a good thing no one listened to her! That’s probably true, but it still seems to us that use case terms are a bit arcane for most PMs and business stakeholders. So here are the key terms explained:

Let’s begin with a working definition of what a use case is. We like to think of it as the conversation back and forth between actors and a system. Which is all well and good if we know what actors are and what the system is. Let us explain.

The system contains all the work we want to do on the project. We like to use the microwave as an example. As a microwave user when I heat up leftovers, for example, I am outside or external to what the microwave does, so I am not part of the systemⁱⁱ. I am an actor who interacts with the microwave system, telling it what I want done and getting heated leftovers as a result. Which brings us to actors.
Actors are always outside the system and always interact directly with the system. They can initiate a use case, provide input to it, and/or receive outputs from it. Actors can be people, other systems, time triggers, or event triggers.

Let’s practice on a couple of examples. If actors are always external to the system and always interact directly with the system, in the following two examples, am I an actor?

Example 1. The system in this first example is an automated banking deposit application. I walk by a bank lobby on my way to work. One day I decide to take a cheque to deposit it in the bank. I stand in line with the deposit, and finally when it’s my turn I hand it to a teller who enters the transaction into the automated deposit system. Am I an actor?ⁱⁱⁱ
Example 2. The next time I have a cheque to deposit I don’t want to stand in line, or even go to an ATM to deposit the cheque. Instead I scan the check using my bank’s app on my smart phone. Am I an actor?

Why PMs Should Care About Use Case Diagrams

Below is an example of a use case diagram. We will explain all the pieces in our next article.

Figure 1 – Use Case Example

Use case diagrams are one of the several techniques we use to help with both the project and product scope. We find that the use case diagram structures our thinking and helps us remember functionality we might otherwise have forgotten. The use case diagram has some key benefits:

It’s an easy way to engage business stakeholders. If we explain use cases using business terms, they can visualize what their system will include, helping get a big picture of the scope.
Because it’s a useful visual, our stakeholders are more inclined to be specific about their desired featured and functionality,
Use cases are almost universally appreciated by the development team, so that there is less time spent translating the business requirements into technical specifications.
Use cases become test cases with acceptance criteria. Whether the team prefers the “Given-When-Then format or the components of a use case, as odd as it sounds, the result is the same.

Stay tuned for future articles on use cases. We will show examples of use case diagrams, explain how to build them, describe why we should create use case narratives, and yes, we’ll explain how use cases provide the same information as the Given—When–Then format.

Don’t forget to leave your comments below.

References

i Elizabeth saw an Ivar Jacobson presentation on use cases about 10 years ago. Jacobson, of course, is one of the ‘three amigos” (with Grady Booch and James Rumbaugh) who founded Rational Software and the Unified Modeling Language. “I had been working with use case models for several years at the time of his presentation. If I remember right, one of the things I learned was that the idea for use cases was rattling around Jacobson’s mind since his work at Ericsson, many decades before this presentation.”
ii Theoretically the microwave system might include all interactions with the microwave, including our processes, but that does not make much sense. It is cleaner and simpler to think of ourselves as an actor interacting with the microwave system.
iii Be careful. We need to define what the system is. In the first example we said it was an automated banking deposit application. In this example I do not interact directly with the system as we’ve defined it, so I am not an actor. The teller, however, is an actor because they do. In the second example we have not defined the boundaries of the system so we do not know who the actors are. It is quite possible that a user scanning a check for deposit is an actor since they are interacting directly with a system. It is also possible that the system is the back end and the user does not interact directly with the system. These examples show the importance of defining the system in order to understand our scope.

About the Authors:

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is Co-Principal and CEO of Watermark Learning and has over 30 years of experience in project management and business analysis. Elizabeth’s speaking history includes repeat presentations for national and international conferences on five continents.

Richard Larson, PMP, CBAP, PMI-PBA, President and Founder of Watermark Learning, is a successful entrepreneur with over 30 years of experience in business analysis, project management, training, and consulting. He has presented workshops and seminars on business analysis and project management topics to over 10,000 participants on five different continents.

A PM’s Guide to Requirements Modeling Part 2: Concurrent Requirements Modeling

Written by Elizabeth Larson on March 30, 2015. Posted in Articles. 3 Comments on A PM’s Guide to Requirements Modeling Part 2: Concurrent Requirements Modeling

This article is the second in a series on requirements modeling with the emphasis on why PMs should care about modeling requirements. Last month we spoke generally about models, the benefits of modeling requirements, and introduced the relationship between the iterative nature of eliciting requirements and modeling them. This article discusses the concept of concurrent requirements modeling, a structure that helps us elicit the detail needed for a complete set of requirements.

Quick Review

What is a model and why should we care? A model is a representation of reality, like a model car, airplane prototype, or graphical design (e.g., a CAD drawing) of a house. As they relate to requirements, models usually consist of text, graphical representations, or both. To get good requirements, we need to ask the right questions. We need to go beyond the “who, what when, where, and why” questions and get to the detail we need. Models help us do just that.

Concurrent Requirements Modeling

OK, so models help us ask the right questions. But which models should we use? Is one model better than the others? Sources such as the BABOK® Guide and PMI’s Business Analysis Practice Guide offer dozens of potential models. We certainly don’t have time to use all of them. Of course there is no one answer to the question of which model is best, but we can explore which models are best suited to our projects. When we are involved with improving processes, and there are a myriad of reasons for doing so, one or several process models work well. When we are building business intelligence applications for doing information analytics, or simply developing quick reports, data models are helpful. When we developing applications and need to describe the interaction between people and the software, use cases are appropriate. And prototypes are helpful to a variety of different types of projects. For software applications, all four are important, and when we elicit and model requirements using the appropriate models pretty much at the same time, we can get to detailed requirements more quickly than if we use just one ore even two model types.

We call this approach “concurrent requirements modeling,” which is different from concurrent component engineering, or concurrency, commonly used in developing objects and e-solutions. Concurrent requirements modeling focuses on obtaining business requirements, not on building software. It suggests that by modeling business data, business processes, interactions of users and systems through use cases, and prototyping, hidden requirements will surface more quickly than if we tried to think of questions without modeling or if we tried to build the product and elicited needs in an ad hoc way. In addition, each type of modeling effort supports and enhances the other modeling efforts and encourages analysts to ask their customers the kinds of pertinent questions that drive out hidden requirements.

Figure 1 below describes the interrelationships among the different types of functional requirements. The models are particularly useful for software requirements, but can also be useful for many aspects of business analysis. The models and their interrelationships are shown below.

Figure 1: Concurrent Requirements Modeling

A brief taste of the four model types

Data models. Once thought to be solely the domain of the very technical developers and database administrators, data models help us understand our stakeholders’ information needs, including many of the all-important business rules. Business rules provide consistency by identifying how companies want to operate their business, and supporting these business decisions across projects. Business rules include such things as policies, calculations, sequence of events, limits, and business decisions. We’ll talk more about the business rules related to data in our next article.

Process models. Our projects result in changed processes. Sometimes it’s a big change and sometimes a small one, but every project changes how people do their jobs. In order for us to understand what particular changes mean to our stakeholders, we need to know what they are doing today and how that will be different when our project is completed. Process models help us with this understanding.

Use case models. So much has been written about use cases. Discussions about their usefulness keep surfacing on LinkedIn groups, a few people saying that they are not useful, particularly on Agile projects, while others with equal passion building a solid case for why they have always been useful and still are. The authors side with the latter. Use cases help us answer very important questions about the interaction with software or pieces of equipment, and provide the structure needed to ask the right questions relating to that interaction.

User Interface models provide prototypes. They might be done using sophisticated software or the proverbial back of a napkin or something in-between. The point is that these prototypes help stakeholders see a picture of the end product, enabling them to provide feedback and suggest changes long before it’s developed.

Working together. When building software, data models answer the questions what data do our stakeholders need to input and when they do, what information is displayed on the user interface (screen). Process models give us the screen navigation. The touch point between the data and process is where there is interaction between the end user and the software. Use case models provide us with what we need to know about this interaction. User interface models graphically depict use cases. More about that in a future article.

What does this mean for project managers? As PMs we might not do the work ourselves, but we need to ensure that work is done. So it’s important for us to be able to have enough of an understanding of these models to ask the right project questions of the resources who will be doing the elicitation and modeling. We also think it is important to understand the value of each model type and why using multiple models will yield better project outcomes. Last, we can be far more helpful in discussions about elicitation activities, tasks, estimates, risks, etc. when we have an understanding about the subject at hand.

In the next article we will examine the benefits of data modeling and what data questions surface when we model our information requirements.

Don’t forget to leave your comments below.

About the Authors: