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.
books by alvin
 |
 |
 |
 |
