Notes from 55th International STC Conference
Philadelphia, Pennsylvania, June 1-4, 2008

Dissecting a Project Objective into Business Requirements and Use Cases

Mark Hanigan and Bonnie Spivey

A veteran presenter, Mark Hanigan is an STC Fellow and former STC president. Currently an independent contractor, he has worked a wide range of products across the technical communication profession. A former Pellegrin Scholarship winner in the University of Central Florida’s technical communication program, Bonnie Spivey now works as a technical communicator/systems analyst for Walt Disney World Cruiselines.

Session Description: This mini-workshop explained and demonstrated the process of “taking apart” a project objective to determine to determine its “component” business requirements and use cases.

• How do you build use cases?
• What is a project objective?
   
• A call for a technology-driven solution to a business problem.
• It must be consistent with corporate mission statement and supportive of both business objectives and project objectives of other projects.
• What is a context diagram? Creating a context diagram
   
• If you are following UML and structured methodology, this is the first UML artifact (drawing).
• Identifies at a high level the architectural domain of your project solution
• Put another way, it identifies where the eventual technology solution of your project objective will live and how it will “play well” with others
• Finally, it helps to define the scope of your project
• How do you derive business requirements?
   
• Organize the business information you think you need into high-level categories
• Conduct interviews, shadow sessions, focus groups, and surveys.
• Convert your results into business requirements.
• The types of activities you conduct to gather business requirements are important as follows:
   
• They should include quantitative as well as qualitative results
• If possible, quantify the qualitative results to show trends to rank functional importance, and so forth.
• From the beginning be thinking about proof of concept, which validates the project costs after go-live.
• An individual business requirement in itself must be constructed following very rigid rules:
   
• It must have one and only one subject and one action...
• ...and it must be measurable, testable, and repeatable.
• How do you build use cases?
   
• Sort the business requirements into the high-level categories you identified at the beginning of the business-requirements-gathering process
• Each high-level category translates into a use case (it could be more than one)
• Build an activity diagram for each category’s business requirements that accounts for all business requirements in the category.
• If you are following UML and structured methodology, these are activity diagrams (with their use cases). A complete set of uses cases ensures that all requirements have been considered.
• By the way, some practitioners prefer build the use cases and activity diagrams first and then extract the business requirements from them.
• In reality, whether your start with business requirements and then build the use cases and activity diagrams of vice versa, it ends up with a back-and-forth process
• This includes a repetition of your data collection process.
• Once all the uses cases have been identified and named, each use case gets placed by its name
• The use case model identifies the interrelationships with other use cases
• The use case model also identifies the relationships of the use cases to the eventual end users
• It can even identify the relationships to other external things like other computer programs and input/output devices like printers
• This is typically the third UML artifact type created
• Overall, the use case model describes what a system does from the standpoint of an internal observer.
• Practical example for workshop: reservation system demo (Disney Cruise Lines)
   
• Corporate mission statement → business objective → project objective
• Identify actors and interfaces; precisely define activities
• Somewhat analogous to Six Sigma Kaizen Events
• Cruise line reservation system actually includes over 1,000 use cases
• Each group of business requirements becomes the core of a use case.
• Then, the use cases can be related to each other and to the actors via a use case diagram (also called a use case model).

Note: This workshop demonstrated the need to return to a 90-minute slot for workshops (STC unwisely chose a 60-minute format for the first time this year). Most of the time was consumed by the overview, which, while extremely informative, left inadequate time to complete and go over the workshop materials (this was unfortunate, because they were excellent).