Historically, we have taken the approach of developing requirements through many different mechanisms. We may ask the customer for an initial set. We may conduct Joint Application Design (JAD) sessions where we conduct meetings for multiple days to extract requirements from our customers. These techniques and many others remain a central part of many software development and implementation projects today. Are these techniques still central to the process?
In the late 80's and early 90's, we began to see an interesting dynamic occuring. When asking our customers for their requirements, a couple of results were commonly seen:
- The customers knew how their current system worked but had difficulty articulating what the requirements were and in particular identifying all the requirements. Articulating all the system features was not something they thought about or did everyday so asking them was/is a very difficult task.
- The customers also tended to describe their current system and what it did as opposed to what the business needed the system to do. Customers know their current system so a natural place to start was articulating how they used their current system, a logical conclusion but one that tended to design the solution including potentially unnecessary customizations in commercial software.
The common end result of these sessions was a set of features that did not meet what the customer needed and in many cases were just a subset of what the system needed to do. Lay on top the duration of the activity and length of time to develop resulted in requirements changes and utlimately a dissatisfied customer as the solution did not meet the business needs at the time of production deployment. The end result was projects going overtime and budget due to scope creep from the project team's perspective but necessary features from the business perspective. Both positions were fair and justified.
As these dynamics became apparent, we began to develop several tenants that remain true today.
- Customers have a greater capability to describe what is needed when looking at a prototype of the solution or at least business processes. Business Processing Re-engineering (BPR) has been around a long time and is not as prevalent as it used to be.
- Customers have a greater capability describing what they do on a daily basis and even infrequently.
- Working or partially working software is a better tool for understanding what a solution needs to do than any form of documentation.
This has lead us down a path where use cases and/or user stories have become a legitimate mechanism for defining what a system must do. The prototyping techniques and now the agile methodologies all expouse this mechanism as a favored way to define the scope of a project. Combine this with business processing modeling and the project manager has a different tool to define the "What" of the system. Process modeling and use cases also provide four additional benefits:
- Is more systematic as the team's tend to look at all paths and not just the happy path. In a process model, a decision point must have a Yes and No path to the question. In many questions, one or the other is an edge case so can be overlooked when reviewing just use cases. Modeling has an inherent auditing capability that tends to drive more thoroughness.
- Provides a mechanism to look for process improvements. In many cases and once the process is defined, customers can more easily identify steps or decision points that are no longer needed or can be streamlined.
- Is agnostic of the legacy application which enables the project team to define a design or configuration for commercial software unburdened by the legacy system. For commercial software, this is particularly useful in working within a core product and avoiding costly customizations.
- Provides a better mechanism for the test teams to become involved earlier in the project. When developing requirements, many test teams opt to review the session output and do not contribute to the requirements development. By using modeling and use cases when the use cases drive the structure and scope of the testing, the testing teams are motivated to participate early. The test team also provide a valuable service as they tend to be very systematic in thinking through edge cases and error scenarios resulting in a more complete set of use cases or process flows.
In summary, defining "what" the system needs to do remains a critical part of a project. As we have evolved, how we define "what" has more options that now include business process modeling, use case or user story definitions, and prototypes as a substitute for requirements gathering. When beginning a project, considering the appropriate mechanism for defining scope is an early and critical project management decision.
These mechanisms have different advantages depending on whether the project is a consulting project with a scope based statement of work whether it be a custom development or commercial software implementation or a product development organization developing and improving a commercial product for sale. These pros and cons of these techniques with respect to the project type are a topic for a future post.
