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:

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.