Archive of Requirements Models Articles

Just Plain BadLameAverageGoodGreat (2 votes, average: 4.50 out of 5)
Loading ... Loading ...
February 19th, 2009

Failure To Launch (Your Product)

Jump forward in time to the day of your next big product launch (first release, new features, new market segment, etc).  And your site/application crashes due to the “unexpected” demand.  All you can do now is look for a bucket of water to put out the fire.  What could you have done to prevent this disaster?  Jump back to today and start doing it!

Read the rest of the article…

Just Plain BadLameAverageGoodGreat (4 votes, average: 4.50 out of 5)
Loading ... Loading ...
February 10th, 2009

Agile Non-Functional Requirements

Just because your requirement is not a user story does not mean you have to throw it out when planning your next sprint.  See one way (that is working) for managing non-functional requirements with an agile team.

Read the rest of the article…

Just Plain BadLameAverageGoodGreat (24 votes, average: 4.71 out of 5)
Loading ... Loading ...
February 2nd, 2009

User Stories and Use Cases

User Stories are one of the key agile artifacts for helping implementation teams deliver the most important capabilities first.  They differ from use cases in some important ways, but share more commonalities than you might think.

Read the rest of the article…

Just Plain BadLameAverageGoodGreat (1 votes, average: 5.00 out of 5)
Loading ... Loading ...
October 1st, 2008

Agile Product Management: Providing Context

Agile development methodologies succeed because they help development teams be as effective as possible.  Development teams do not, however, work in complete isolation.  The company they work for has a strategy.  The company manages a portfolio of products, and targets a particular product at specific market problems.  Within that context, an agile team can thrive.  What’s the best way to provide that context?

Just Plain BadLameAverageGoodGreat (1 votes, average: 5.00 out of 5)
Loading ... Loading ...
June 23rd, 2008

Defining Problems at ProductCamp Austin 1

productcamp austin logo

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.

Just Plain BadLameAverageGoodGreat (2 votes, average: 5.00 out of 5)
Loading ... Loading ...
June 9th, 2008

Use Case To Actor Mapping

map

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.

Just Plain BadLameAverageGoodGreat (5 votes, average: 4.40 out of 5)
Loading ... Loading ...
May 27th, 2008

Defining Problems With Cause And Effect Diagrams

fish head

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!

Just Plain BadLameAverageGoodGreat (4 votes, average: 5.00 out of 5)
Loading ... Loading ...
March 19th, 2008

Uncovering Requirements With UML Class Diagrams Part 5

digging

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.

Just Plain BadLameAverageGoodGreat (3 votes, average: 5.00 out of 5)
Loading ... Loading ...
March 17th, 2008

Uncovering Requirements With UML Class Diagrams Part 4

dozer

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.

Just Plain BadLameAverageGoodGreat (3 votes, average: 5.00 out of 5)
Loading ... Loading ...
March 13th, 2008

Uncovering Requirements With UML Class Diagrams Part 3

digging

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.