One of the most popular software agile techniques is the generation of Use Cases. Use Cases are used by stakeholders to succinctly express minimal desired functionality. However, on occasion, Use Cases have been misinterpreted to be maximum system requirements. Between these two perceptions of the role of Use Cases there is a gulf of technology.
Before we delve in to the topic at hand, let’s get a quick primer on what use cases are meant for. In software and systems engineering, a use case is a list of actions or event steps, typically defining the interactions between a role and a system, to achieve a goal. In systems engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals.
From a stakeholder perspective, a proposed software system is an opportunity to identify functionality they want or need to be available in the new system. The stakeholder communication methods are varied but one of them is agile Use Cases, which succinctly indicates an event and a desired outcome.
What is not communicated by the stakeholder, nor should it be, is an appropriate system architecture to robustly support the request, the capability to detect error conditions, a mechanism to gracefully recover from anomalies, and consistent communication techniques with user personnel. These elements are part of the system architecture, the infrastructure that supplies necessary components on which to build Use Case functionality. However, as necessary as these subsystems are, they are often minimized due to their non-visual representations. Whereas it is easy to perceive progress with UI elements, subsystems are imperceptible. Like footings on new building construction, ignoring software infrastructure results in only a matter of time before the failures start.
Here again options are available from do nothing, to educate the stakeholder, to commit to build a reputation of quality over quantity, etc. We can use the construction industry as a model and have technical specializations; we can build a library of reusable components; we can do custom development for each customer. The common trade off of time vs. money is in play for both the stakeholder and the contractor.
Whichever trade off is chosen; it is owed to the customer to do a technical review of their existing computer environment. A subsequent discussion on key technical issues, trade offs and an available library of reusable components will improve the likelihood of a successful project outcome for both the customer and the contractor.
What are your views on the misinterpretation of use cases? Do feel free to share your thoughts in the comment section below. Follow Princeton Blue on Facebook, LinkedIn, Twitter & Google+ to get BPM-specific updates regularly.