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.

To this end, simple requirements are usually not enough. I need something that prods all of us to think about the variables in our equations, and how those variables interact during a process. If you're making proper note of the variables, you can catch these things in a use case; but you won't catch them all sitting around a table and talking about requirements. Things happen; variable state changes, and variable state affects what can happen. You get this with use cases ... but not so much with plain old requirements.

 

Add new comment

Anonymous format

  • Allowed HTML tags: <em> <strong> <cite> <code> <ul type> <ol start type> <li> <pre>
  • Lines and paragraphs break automatically.