Wherein we try some requirements development techniques and see what happens.
Traditionally, requirements analysts have often opened an interview or workshop by asking users, "What do you want?" This is the least useful question you can ask when exploring requirements. A related nearly useless question is "What are your requirements?" People aren't sure just how to answer these vague questions, and often they yield random bits of important, but unorganized, information. We don't want to fall into that same trap on this project, so we need a better way to hunt the elusive and secretive requirement.
Several members of our IT groups routinely attend technical conferences on software development. The conference attendees then present summaries of the talks they heard at our weekly group meeting and we all contemplate how we might apply new techniques to our own projects. I recall that one of my colleagues recently attended a conference presentation on a requirements elicitation technique called use cases. This sounds like a potentially useful method so I borrow his copy of the presentation slides.
As I pore over his notes on the use case method, I get the feeling this just might work for the Chemical Tracking System. We don't have much information about use cases available, and none of us has any experience with them, but the concept surely makes sense. The main theme of the use case technique is to focus requirements discussions on ...