Software product success.
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.
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?
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.
Use cases can be difficult to talk about, because they immediately invoke so many different preconceptions and prejudices. High school English teachers know that some words aren’t just words – they are symbolic, and represent ideas. They had us write essays like “Who do I think is a hero†and […]
In a previous post, we mentioned a link to the first in a series of articles by Marc Clifton at The Code Project, a .NET resource site. Here are the links to all 5 of the articles in Marc’s series.
OK, you have to go download Watson, which provides contextual search (of the web, from your desktop). The context that it uses is whatever application is open on your desktop – specifically MS Word, Powerpoint, Outlook, IE and Firefox. This morning I was working on a “How to design unit […]
I’m having a little trouble reading the spec – I left my secret decoder ring at home! Ever hear that before? A set of requirements that makes perfect sense to one team member can be completely unintelligible to others. Requirements written in business-speak, or full of accounting jargon may be […]
Kathy Sierra writes a great post in her blog, Creating Passionate Users, that talks about the requirement to make things interesting. The driving objective is to accelerate the user adoption curve – which Kathy calls the Kick Ass Curve. Any user is initially forced to focus on the tool, and […]
“WHY?†is the central theme, the underlying cause, and the most important element to developing a successful product. And it plays an important role in documenting requirements. Without knowing why a product is valuable or why people will use it, or why it needs to be done in 3 months instead of 6, you aren’t likely to make the right decisions about what to include, when to include it, or how to market it.