Category Archives: Requirements Models

Different models, or documentation techniques for capturing requirements. Requirements models are the tools in a business analysts toolkit. Product and program managers also rely on requirements models as methods of documenting requirements.

Buyer Personas And User Personas

By Scott Sehlhorst | July 22nd, 2008

A lot of people stand up a variation of “If you build it, he will come” (from Field of Dreams) as a copy-writing hook for whatever they are about to tell you about creating products/services/whatever. We’re no better. We’re going to tell you that there is a big difference between the people who buy your product and the people who use your product.

If you build what he thinks he wants, he will come.

Actually, we need two catchy quotes.

If you build what he actually needs, he will come back.

For good measure, let’s plug my recent article in The Pragmatic Marketer, Maximize Your Word of Mouth Marketing: Turning Users Into Fans with a gratuitous quote.

If you build it right, he’ll bring his friends.

These quotes (the first two) highlight the differences between buyer personas and user personas.

Read the rest of the article …

Posted in Ishikawa Diagram, Marketing, Product Management | Tagged adelle revella, buyer persona, david meerman scott, kadient, personas, product marketing, the new rules of marketing & pr, user persona | 14 Comments

Defining Problems at ProductCamp Austin 1

By Scott Sehlhorst | June 23rd, 2008

Jun 14th was the first productcamp in Austin (and the second one anywhere). It was a great event, and here’s the presentation that I did on how to define the strategic problems that drive our products.

Read the rest of the article …

Posted in Austin TX, Business Analysis, Ishikawa Diagram, Product Management, Requirements, Requirements Models | Tagged cause and effect diagram, fishbone diagram, ishikawa, pca, productcamp, productcamp austin | 1 Comment

Use Case To Actor Mapping

By Scott Sehlhorst | June 9th, 2008

We know the importance of identifying the use cases that enable our business goals. We also know the value of understanding the actors that will use our products. This article shows how to demonstrate a simple but powerful view that maps the use cases to the actors.

Read the rest of the article …

Posted in Business Analysis, Product Management, Requirements, Requirements Models, Uncategorized, Use Cases | Tagged actors, completeness validation, requirements process, Use Cases, use cases | 4 Comments

Defining Problems With Cause And Effect Diagrams

By Scott Sehlhorst | May 27th, 2008

The Cause and Effect diagram is also known as a fish bone diagram, because it resembles the skeleton of a fish. Using a cause and effect diagram can be the most effective way to define the problems that you intend to solve with your product. Get your stakeholders engaged in your program with this compelling visual!

Read the rest of the article …

Posted in Business Analysis, Communication, Ishikawa Diagram, Product Management, Requirements, Requirements Models, Writing | Tagged cause and effect diagram, fish bone diagram, fishbone diagram, ishikawa, problem statement | 8 Comments

Uncovering Requirements With UML Class Diagrams Part 5

By Scott Sehlhorst | March 19th, 2008

In this article, we build on our ability to represent straight forward business relationships in UML class diagrams. These relationships describe how two objects are related to each other. Representing relationships in class diagrams helps us to better understand the domain and helps us to uncover hidden requirements. Occasionally, we have to deal with more complex relationships that involve more than two objects to properly describe. This does not happen as frequently, but when it does, our modeling efforts are more likely to uncover overlooked requirements. In this article we learn how to describe relationships that involve more than two objects.

Read the rest of the article …

Posted in Requirements, Requirements Models, Requirements gathering, UML Modeling | Tagged managing data, modeling requirements, ooa, Requirements, requirements class diagram, Requirements gathering, Requirements Models, uml class diagram for analysis, uml class diagrams, UML Modeling, uml requirements | 4 Comments

Uncovering Requirements With UML Class Diagrams Part 4

By Scott Sehlhorst | March 17th, 2008

The hardest part of gathering requirements effectively is uncovering the requirements that people don’t immediately tell you. You have to ask the right questions. And one of the best ways to find the right questions to build a class diagram of the business domain. This article continues our introduction to class diagrams.

Read the rest of the article …

Uncovering Requirements With UML Class Diagrams Part 3

By Scott Sehlhorst | March 13th, 2008

UML Class Diagrams are very effective at uncovering requirements. They give us insight into how the business thinks about objects and their relationships. And from that understanding, we think to ask questions we might otherwise overlook. In this part of our series, we look at how to represent when one object is made up of other objects. The two types of relationships we explore are composition and aggregation.

Read the rest of the article …

Uncovering Requirements With UML Class Diagrams Part 2

By Scott Sehlhorst | March 10th, 2008

We continue our exploration of UML Class Diagrams with this article that explores how to represent basic business relationships in a class diagram. Drawing these relationships can dramatically clarify requirements documents. Using a class diagram to supplement other requirements documents provides for a centralized reference that enables a shared understanding of the problem domain. That understanding prevents mistakes in interpreting requirements.

Read the rest of the article …

Uncovering Requirements With UML Class Diagrams Part 1

By Scott Sehlhorst | March 6th, 2008

UML Class Diagrams can be used not only for documenting software design, but for documenting software requirements. One of the challenges in writing clear, unambiguous requirements is being precise about what a particular word means. This is especially true with symbolic terms like “quote” or “customer” – where everyone knows what they mean – but they mean different things to different people.

Read the rest of the article …

Posted in Requirements, Requirements Models, Requirements gathering, UML Modeling | Tagged managing data, modeling requirements, ooa, requirements class diagram, uml class diagram for analysis, uml class diagrams, uml requirements | 15 Comments

Cockburn Affirms: Use Cases Rule for Agile!

By Scott Sehlhorst | February 18th, 2008

We’ve been promoting use cases as the right way to approach agile requirements, and in a recent article, Alistair Cockburn stresses the importance of use cases. Over the last three years, he has found that teams that avoid use cases consistently run into the same three problems. We defer, of course, to Alistair as the expert. But we’ve been independently promoting this practice too. So today, we get a cookie!

Read the rest of the article …