Almost everything I’ve read about use cases focuses on describing what needs to be added to your product. Agile development says “get it working first, make it better second.” That means changing the way the software enables a user to do something they can already do. How do you manage requirements for incremental improvement?
Engagement – that’s what this whole product management blogging thing is about. Check out what Tyner Blain readers found to be the most engaging articles in 2009.
Design-Free requirements are important for two reasons, and hard for two other reasons.
Design-free requirements are hard because you “know what you want” when you should be documenting “why you want it.” Writing design-free requirements can be hard when you don’t trust your development team to “do the right thing” even though it is not your job to design the solution.
Concise requirements give your team a useful, easy to read and easy to change understanding of what must be done. Great requirements exist to do three things:
- Identify the problems that need to be solved.
- Explain why those problems are worth solving.
- Define when those problems are solved.
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.
Continue reading Use Case To Actor Mapping
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!
Continue reading Cockburn Affirms: Use Cases Rule for Agile!
Learning how to write use cases can be tough, but it is simple compared to the balancing act of determining which use cases to write and how to manage the expectations of all the stakeholders that are involved. It can be a difficult balancing act to prioritize use cases to assure that you meet the goals of the business while satisfying the needs of the users.
Continue reading Use Case Management is a Tough Balancing Act
We’ve written before about the importance of separating rules from requirements, particularly in use cases. We wrote that with the goal in mind of reducing the costs of system maintenance. Low-level rules like decision, calculation and inference rules tend to change frequently – and independently of other requirements. So a documentation approach that separates these rules from requirements can both reduce implementation costs (by encouraging separated implementation) and reduce the time required to manage and approve changes.
There are also benefits to abstracting high-level, or procedural rules, when dealing with global business requirements.
Continue reading Global Processes and Business Rules
Business rules are not requirements. Yet they are often gathered at the same time as requirements, from the same sources, by the same business analysts. And unfortunately, often documented in the same artifacts. In this article we look at some of the ways that business rules are commonly hidden inside use cases.
Continue reading Business Rules Hidden in Use Cases
What is the right level of detail for writing requirements? What about for writing specifications (functional, non-functional requirements, etc)? The answer is that there is no one answer. But there are guidelines, and reasons to write more detail, or less detail – for any given product or project, and any given team. The reason we write requirements is so that they can be read. Understanding the readers is the key to determining which details to include in the requirements.
Continue reading Requirements Details – How Much is Enough?