However, Worksoft's Hayes said unrealistic expectations and the pressures under which most projects begin, tend to torpedo requirements management processes before the tools ever get installed.
"The phenomenon is this," she said. "The schedule for the project is never based on the amount of work to be done. In my experience, it's based on some kind of external factor. We have a competitive need. We have a customer need. We have a corporate announcement. We're going public. There's some sort of market-driven need for whatever this solution is. So, typically, that's what's driving the schedule."
And this is where the perceived need for speed kills the requirements management process.
. . .
[T]he end user should be the focus of the requirements document. "Fundamentally, one of the approaches that we think is important is a technique called use cases. Basically, that's a fancy word for telling the story of how the user is going to interact with the application. And we keep them short and simple."
. . .
"In a typical project environment -- very fast-paced, keep things going, get it out, get it right -- they write the documents with everything but the kitchen sink in there. They hand it over to engineering and [engineers] can't really see what the most important things are because they probably can't do it all," he said. "[Also,] they can't communicate effectively with the end user and other stakeholders because they've thrown everything into one or two documents. We believe you should break it down into user-oriented areas -- What is it that the user is trying to accomplish? -- and from there you'll capture a smaller portion in that given document of an area and write the story from the user perspective of what's going to happen. From there, you'll actually capture the requirements in the context of that story."
Previous Topic
