CRUD (Create, Retrieve, Update, Delete) is an acronym used to refer to a set of mundane, important, and indirect (if not implicit) requirements or use cases. To create a report on orders, you have to first create the orders and retrieve them. Further, the ability to update (edit) and delete […]
Why We Should Invest in Requirements Management
Need to convince someone in your management chain why they should invest in managing requirements? There are some great arguments…
Managing requirements conversations
In Documents vs. Conversations, on the Pyre blog, Greg Wilson does that thing that we so rarely do – he takes a step back, and thinks from an entirely different perspective about managing requirements. He proposes the idea of managing requirements as conversations, instead of as documents. Greg makes the […]
Use case series: UML 2.0 use case diagrams
The UML way to organize and manage use cases. Pros Provides a high level view of the use cases in a system, solution, or application. Clearly shows which actors perform which use cases, and how use cases combine to form business processes Cons Presents an “inside-out†view of the sytem. […]
Top Five Use Case Blunders
The five most common use case mistakes. The list has grown to ten, but check out these top five – the worst of the worst.
Communicating a delivery schedule with use cases
Use cases are a great tool for establishing the scope of a project. They provide a framework for defining what needs to be implemented (if it doesn’t support a use case, we don’t need to implement it). They also set expectations with stakeholders (here’s what you can do with the […]
Use case series: Informal Use Case
The informal use case is the tool of the Agile Requirements Manager. It is a paragraph describing the user’s goals and steps. Also referred to as a basic use case.
Stay away from my users!
We’ve dealt with user representatives who believed that they knew better than the users. We’ve dealt with people afraid to let consultants talk to the users, because the consultants might mis-set expectations and create bad will when the development team fails to deliver. We’ve dealt with over-protective information-hogs, who don’t want to telegraph their moves, for risk that they might lose control of the project, or lose credit for the project to someone else. How do we get past these barriers?
Use Case Series: Formal Use Case
This is the classic use case as described by someone who talks about Software Engineering. All of the training classes (other than Agile classes) that I’ve been to teach formal use case development as a component in a system of requirements management.