Requirements Modeling—Time Waster or Time Saver?

How often do we hear “We don’t have time for analysis—let’s just get the project done!” Or “Modeling?! That’s so 1990s.” Or “Modeling is the developer’s job. Yours is to get the requirements.” Or “We’re doing Agile. Requirements evolve, so let’s not waste time with use cases or process models.” We have often heard every argument under the sun why spending time modeling requirements wastes time. However, we believe that modeling actually saves time.

This article opens a series on requirements modeling. It provides an introduction to requirements modeling and will be followed by several articles on specific modeling topics. In this series of articles we tackle modeling questions, issues, and arguments and present our view of why modeling requirements is still not only relevant, but essential.

Terms, Terms, and More Terms

What is a requirement? While a requirement has been defined as a need, or the “as-is” or not defined because “there’s no such thing as a requirement--everything is part of design,” we say it is a description of the features and functions, capabilities, and characteristics of the end product, service, or result of the project, one that helps the organization solve its business problem or seize an external opportunity. There are many different types of requirements, such as data or process requirements. There are various levels of requirements, such as high-level and detailed. There is a classification of requirements, distinguishing business objectives from functional and non-functional requirements. Nevertheless, each of these describes a need and the associated features or capabilities of a product or service that will satisfy that need.

What is a model? 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 analysis, models usually consist of text, graphical representations, or both. In software development there are several complementary models that help elicit requirements. Most models have both diagrams and textual components. Text can be sentences (user stories), tables or matrixes (interaction matrix or data dictionary) or lists, but words are the primary component. Diagrams (process models and entity/relationship diagrams to name a few) are usually visual methods of representing requirements, although they may be supplemented with words, such as an entity/relationship diagram (ERD) supported with a data dictionary, or a use case diagram with use case narratives.

Models can be developed using a variety of techniques. An advantage of models is that they can reduce the ambiguity when only text is used. Models typically represent the data, process, interface, and interaction views of requirements. We will review each of these views in subsequent articles. Each modeling technique helps the analyst ask the clarifying questions needed to uncover hidden requirements. These techniques are interdependent and each is usually completed iteratively throughout the process of gathering requirements.

Modeling and elicitation. Elicitation is about asking questions, so to get information we need to build our end product, we need to ask both high-level consultative questions to determine the true business need as well as questions about the characteristics and functionality needed for the end product. Although helpful, we need to go beyond the “who, what when, where, why.” If we’re building software we need to ask questions related to the requirement views of data, process, interaction, and interface. Below are just a few sample questions related to the four categories. In future articles we will do a deeper dive into how modeling helps elicitation, as well as the categories of questions to ask.

Sample questions in each of the four requirements views:

• Data questions.

  • What is the information that your business stakeholders care about, like customers, orders, and line items on orders?
     
  • What are the facts about that information and are those facts required or not? For example, is a ship date required on each line item on an order?
     
• Process.

  • Should the screen navigation follow and support a business process or force a new business process?

  • Where does the business process begin and end?

• Interaction/Interface.

  • How does an end user interact with the system or end product?
     
  • Who else and/or what other systems interact with it?
     
  • What kind of errors can occur and what messages should appear?

Concurrent Requirements Modeling

One proven approach for eliciting quick and complete requirements is what we call “concurrent requirements modeling.” This approach 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

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

Authors:  Elizabeth Larson, PMP, CBAP, CSM & Richard Larson, PMP, CBAP, Watermark Learning

Elizabeth Larson, CBAP, PMP, CSM and Richard Larson, CBAP, PMP are Co-Principals of Watermark Learning, a globally recognized business analysis and project management training company. With over 30 years of industry experience each, they have used their expertise to help thousands of BA and PM practitioners develop new skills. Their speaking history includes repeat appearances at IIBA and PMI Global Congresses, chapter meetings, and professional development days, as well as BA World conferences.

They have co-written the acclaimed CBAP Certification Study Guide and The Practitioners’ Guide to Requirements Management. They have been quoted in PM Network and CIO magazine. They were lead contributors to the BABOK Guide® Version 2.0, as well as the PMBOK Guide® – Fourth edition.