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 everyone picks a different person, [...]

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 tests” document for my client, and I [...]

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 unintelligible to the development [...]

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 not the task. The [...]

“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.

I attended training on making compelling presentations last year - and one thing that was stressed was the use of imagery to drive points home. Although there have been images in my posts to date, they have been utilitarian - not sources of imagery. I need to do better with my writing.
Thanks to [...]

Without good communication skills, you won’t understand what the stakeholders want. And you won’t structure and describe the requirements in a way that the developers will implement what you intend.

For a given project, there are three sets of requirements - the requirements you are given, the requirements you document, and the requirements that are interpreted by the delivery team.

Tom Chi, has a new article at OK/Cancel about the needs and challenges of having a detailed functional spec.  He throws open the floor for folks to comment on what works for them.  As a long time reader of OK/Cancel, I can tell you that they will get a bunch of great responses - they [...]

Object oriented analysis and design (OOA/OOD) is a technique used to gather requirements and develop software, as an alternative to more traditional text-based techniques.

OOA allows for clarity of communication, by creating descriptive and unambiguous documentation of requirements. It comes with a great big giant caveat –