Collecting requirements

Mon, 1 Oct 2007 21:31:53 -0500

In working with business clients, it is often a challenge to get a good requirements process in place. Many issues challenge this, but that will be the topic of another post.

In general, a requirements process bridges the gap between the business identifying that a system is needed and the I/S folks being able to implement it. That being said, there can be a number of steps to get across this gap. Some of these steps may yield a document that is useful to communicate with certain stake-holders in the project.

T. Laux (PM), S. Abbott (BA), and I came up with a diagram to help our business clients “bridge the gap” and understand what parts play a role at what stages.

In a nutshell:
• Identify your high-level business events that will drive your system needs (e.g. processing orders, receiving customer inquiries, etc.) A business model (a high level flow of how your business does its business, in the area of interest to the system) provides excellent inputs for business events.
• Identify your needs (why is the system needed?)
• Brainstorm the features the system will provide to satisfy the needs. (what will the system do?)

Once features are identified, you’re well on your way to use case specifications. High-level business events (and the actors involved with them) provide the necessary inputs to create a basic use case model. The features start providing the necessary detail to dig into use case specifications for each of the use cases identified from the business events.

Additional inputs fit in along the path, such as usability and system constraints. These start to feed into the requirements as non-functional or supplementary requirements, and really are detailed in the use case specifications.

Requirements Engineering

Collecting requirements