We all know how difficult it is to achieve project success without complete product requirements. Yet gathering complete requirements without exhausting the project schedule and budget remains elusive for many project managers. In this short article we will provide tips for gathering hidden requirements quickly.
Traditionally, many software developers have embraced new technology. As flat files gave way to hierarchical databases and as those databases gave way to relational tables, as mainframe technology became distributed and as object oriented technology replaced information engineering, many developers jumped at the opportunity to learn new skills. Project managers, however, tended to be more wary. How this new technology would affect schedules and budgets, what the relationship would be between the technology and project risk and quality, how easy it would be to hire staff with technical expertise became tough questions for these managers to answer.
With new technology came new methods known as development methodologies. We went from the Waterfall methodology to the Whale model, to Rapid Application Development to Iterative Project Management, and each new process claimed to reduce the software development cycle time. Each has had both advantages and disadvantages, but none has proven totally satisfactory. One reason for the disillusion is that none addresses gathering and managing requirements both quickly and thoroughly.
One proven approach for quick and complete requirements-gathering is what I call "concurrent modeling." This approach is different from concurrent component engineering, or concurrency, commonly used in developing e-solutions. Concurrent modeling suggests that by modeling business data, business processes, system processes through use case modeling, and prototyping, requirements quickly surface. In addition, each type of modeling effort supports the other modeling efforts and forces analysts to ask their customers the kinds of pertinent questions that drive out hidden requirements.
While modeling requirements with use cases does not provide a complete solution, it does provide one important dimension of requirements-gathering-that of describing the conversation between a system and its user(s). Although this system is usually automated (such as an Order system), it can be a system in its broadest sense, comprised of methods, procedures, forms, and automated systems. Another way to think of a use case is that it describes what a system does in response to a request or a trigger. If I want my car to stop, I need to have a 'conversation' with it and make that request. Today I need to talk my car's language; I cannot simply shout 'STOP!' I need to use an interface to state my request. That interface is the brake. Hopefully the car responds by slowing down and coming to a halt.
Use cases have their roots in Information Engineering, which twenty years ago had such proponents as Ed Yourdon and James Martin. What we then called event or process modeling, we now call use case modeling. External agents became what we now call actors. Data flowing into and out of the system and processes within the system, we now think of in terms of interfaces. We now call the hierarchy of system processes use cases.
Many practitioners confuse this system process model with a business process model, or process map. Both use cases and process maps describe processes. The former describes the reaction of a system to an external trigger. Process maps also describe processes, but from the perspective of who does what in the organization. In both cases the process is described with one verb and one noun, known as an action and an object, and in both instances inputs are transformed into outputs.
An example of a process is 'Check Inventory.' From a business process perspective, checking inventory might include a business person examining actual items, perhaps taking a physical count of the inventory, scanning cartons or items, and comparing the items on-hand to a report. In use cases modeling 'Check Inventory' might describe how an Order system (actor) queries the Inventory Management System to see if the requested items are in stock and then reserves the items, all without human interaction.
One of the most commonly asked questions from my students is why they need to do modeling other than use case modeling. I answer as follows:
- Data models provide what information appears on user interfaces (UIs), for both data entry screens, as well as reports. It also provides many of the business rules, e.g., whether or not customers are required to have accounts.
- Process maps provide UI navigation, which should follow the business processes (hopefully improved or reengineered). These maps also drive out business rules, e.g., we process deposits before withdrawals.
- Prototyping, which is derived from both the data and the process models, allows for early feedback and helps drive out additional requirements.
- Use case models not only show system interfaces, but can lead to a description of edits and messages and testing scripts. They also become the basis for software program design.
It's no wonder, then, that one of the most common complaints from so many people is that they have done a thorough job of use case modeling and yet requirements still surface throughout and after the project!
So to help achieve success on software projects, focus not just on the project effort, but on the product requirements. And remember that concurrent modeling will reduce the risk of schedule and budget overruns, since hidden requirements will surface sooner in the development process, reducing the cost of rework during the entire project and, importantly, after the project is implemented.
Don't forget to leave your comments below
Elizabeth Larson, CBAP, PMP, CSM, and Richard Larson, CBAP, PMP, are Co-Principals of Watermark Learning (www.watermarklearning.com), a globally recognized business analysis and project management training company. For over 20 years, they have used their extensive experience in both business analysis and project management to help thousands of BA and PM practitioners develop new skills. They have helped build Watermark's training into a unique combination of industry best practices, an engaging format, and a practical approach. Watermark Learning students immediately learn the real-world skills necessary to produce enduring results. Both Elizabeth and Richard are among the world's first Certified Business Analysis Professionals (CBAP) through the International Institute of Business Analysis (IIBA) and are contributors to the IIBA Business Analysis Body of Knowledge (BABOK). They are also certified Project Management Professionals (PMP) and are contributors to the section on collecting requirements in the 4th edition of the Project Management Body of Knowledge (PMBOK).
Subscribe to this comment's feed
written by a guest, July 20, 2010
In my experience a reason why use cases aren't sufficient to define system requirements is also the same reason for their strength, that they describe requirements entirely from a user dialogue perspective, in effect where the user or actor is playing a particular role. The problem is that roles often change and can in that sense be superficial, whereas an information system needs to be able to survive role changes with minimum modification. Consequently its necessary to identify and describe requirements from other perspectives than just those of its currently envisaged actors, hence the need for at least conceptual data (business ontology) models in addition to use cases, which can drive out different viewpoints.
Its probably worth mentioning, for those that aren't familiar with the history, that the term 'use case' was invented by Ivar Jacobson in the later 60's, before he teamed up with Grady Booch and James Rumbaugh to develop UML.
-
- +2
-
-
written by aamaxwell@gmail.com, July 20, 2010
Use Case diagrams can be quite limited - Do you recommend using some form of process model to help define the scope and relationships between Use Cases?
-
- +0
-
-
written by Richard_Larson, July 21, 2010
-
- +0
-
-
written by Richard_Larson, July 21, 2010
-
- +0
-
-
written by a guest, July 22, 2010
As a teacher I am always frustrated at having to read through articles 2 or 3 times because the info required to understand earlier topics requires the knowledge of info in later ones. At least provide a link to other references if you are assuming previous knowledge.
But still a good article, especially for those who are already familiar with use cases.
John
-
- +1
-
-
written by Colin101, July 22, 2010
-
- +0
-
-
written by wvangalen, July 28, 2010
On a separate note, rather than describing a use case as a response to an event (step on the brake), I prefer to see a use case as a definition of how the system to which a use case belongs meets a particular goal of one of its users (slow down, stop).
-- A system’s use case model gains in clarity and crispness when each use case is named after a single, ultimate goal for which the actor wants to use the system and that reflects the result of the use case’s successful completion.
-- This change in orientation introduces some subtle but meaningful improvements in use case names, like Reserve Items instead of Check Inventory and Find Customer instead of Customer Search. A goal-oriented name more clearly reflects the use case’s scope (of interest to all of its consumers) and the measure of its success (especially of interest to testers).
-- System, actor and use case names can be validated by inserting them into the little test phrase “the uses the in order to ”, like “the Order System uses the Inventory Management System in order to Reserve Items”.
-
- +0
-
-
written by elizabeth.larson, July 29, 2010
The whale is so called because when you create a little diagram of the different approaches to software development, the diagram associated with Waterfall looks a bit like a whale. The head of the whale is large, like capturing all the requirements up-front. Less work is done in design and development, mirroring the body of the whale. It's an old-fashioned term popular in the 90s with case tools.
-
- +0
-
-
written by elizabeth.larson, July 29, 2010
Thanks for articulating the benefits of concurrent modeling so clearly. As to the writing of the use case, many people have found the goal-orientated approach you describe helpful. Our approach to writing use cases is purposefully different. Although not as common in the literature on use cases, we believe that writing use cases from the perspective of the system, not the actor, allows more in-depth analysis which leads to a more complete description of the interaction between actor and system more quickly.
BTW, we’re much less fussy about the name of the use case, as long as it’s a verb/noun combination. So for us the name of Check Inventory or Reserve Item is equally appropriate. We would never recommend Customer Search but either Search Customer or Find Customer works for us. We like your example of a use case description: “the Order System uses the Inventory Management System in order to Reserve Items”. It’s stated from the perspective of the System (the Order System). Again, we allow for a lot of variations as long as the scope is clear (item is reserved, not order is placed) so we know when the use case begins and ends, as long as the narrative flow of events starts with the actor action and ends with the system response, and as long as the use case does not become a business process. Thanks again for your helpful comment.
-
- +0
-
-
written by wvangalen, August 03, 2010
-
- +0
-
-
Click Here to login or create a free account.
A system use case documents how some specific system responds to an event, whereas a business use case defines how an organization responds to an event. The methodology is the same, but the "perspective" is different. Start with the business use cases first and then each step in the response leads to the identification of system use cases.