|
Each technique has advantages and disadvantages. I would not say one technique is better than another. In fact, any project should probably use several of the techniques.
Methods that involve visualization of the requirements, such as prototypes, storyboards, scenarios, and to a certain extent use cases are beneficial when you have a business user who may not be concerned with the ins and outs of the technical solution or have a very long attention span for validating the requirements in a long-winded document. Using visual methods to gather and eventually validate the requirements with the user allows the analyst to drive the discovery more effectively than simply reading through a document with a prospective user.
|
|
 |
A combination of methods will almost always be required. Certain types of requirements lend themselves to a textual representation. It is difficult to storyboard that the system must respond in less than 1 second, but it's fairly easy to write a textual requirement stating that a certain type of transaction has an expected performance requirement. In that very same project, a storyboard might be very useful for drawing out (eliciting) a desired usage scenario from a customer service representative who will use the system every day to accept orders for your company.
Think about your audience and who will be validating that you have the correct requirements, then select the method that will provide the highest level of clarity for that audience.
|
