requirement

The best UML “Use Case” definition I know

Every time I read an article or book about UML “Use Cases” I cringe a little bit. Every author says something like “Jacobson left the definition of a Use Case too open,” and then they try to work through some elaborate scheme of what a Use Case means to them. IMHO, the best use case definition was created in the early 1980s, long before Jacobson mentioned the term.

One thing a business analyst should ask about any requirement

As a business analyst (or any person interested in writing software requirements and quality), there is one thing you should always ask yourself whenever you write a business requirement:

Is this software requirement testable?

I’ve seen some business analysts write some crazy things and call them requirements, but IMHO, if you can’t test it, it’s not a requirement.

Use cases, requirements, and state (Fri, Jan 21, 2005)

One of the things I learned (or was reminded of) is that -- properly done -- Use Cases really bring out some state-related issues that you can't get from plain old requirements.

I'm working with a client on fixed price software development (and have been doing so for nearly two years now), and this brings a lot of risk to my side of the table, so I'm very careful that we all understand exactly what's being developed.