Level: Introductory Adam Frankl, Vice President of Marketing, Ravenflow
15 Aug 2007 
from The Rational Edge: Read how business use cases can serve as the basis for validating requirements during the software development process.
From The Rational Edge.
Effective communication among application development project stakeholders is often challenging, especially when the team is geographically distributed or time constrained. IBM® Rational® software helps organizations automate, integrate, and govern the core business process of software and systems delivery via the IBM Rational Software Delivery Platform. At the platform's core is the IBM Rational Unified Process® (RUP®), a flexible framework for establishing an iterative business process for software and systems delivery. Based on more than two decades of harvested best practices, RUP helps to reduce the risk of project failure and promotes consistency, predictability, productivity, and efficiency across the organization.
The RUP Business Modeling discipline provides tools and notations for business use cases which facilitate effective stakeholder communication and validation with domain experts. It allows business analysts to use the same notation and tools to document business processes that software architects and designers use to document software solutions. This allows the two groups to communicate better, ensuring that software systems really meet business needs.
What are business use cases?
A business use case describes a business process, documented as a sequence of actions that provides observable value to a business actor. A business actor is any person, system or thing that interacts with the business or organization. So a business use case should describe what the business does -- namely, its interactions with its environment -- to deliver value to its stakeholders. To fully understand the purpose of a business and its processes, you have to know who puts demands on it and who is interested in its output.
Another way to think of a business use case is that it documents a particular business workflow. The flow of events, or workflow, is a key element of a business use case. It describes what the business does to deliver value to a business actor. This description should be understandable by anyone within the business. (And, importantly, it is distinct from a description of how the business solves its problems.)
Whether a development project is focused in a new business area or on providing new functionality, validated business use cases are a crucial element of RUP. The Rational Unified Process Business Modeling discipline facilitates effective communication and validation of project requirements by providing tools and notations for working with business use cases.
The business use case model
The business use case model provides the big picture from a business actor's perspective. It describes the business process in a way that is accessible to all members of the project team. But software teams also need business models for other reasons. Software must be delivered rapidly, in increments driven by business value rather than technical needs. A good business model provides a software-independent description of the processes to be automated, thereby promoting comprehension of priorities and risks prior to technology selection.
The IT team must have descriptions of the business that allow team members to make informed decisions, including an unambiguous specification of the business process that details relevant value and cost factors. Business use cases are documented via specifications that consist of both textual workflow descriptions and one or more Unified Modeling Language (UML) activity diagrams. Figure 1 provides an example of a business use case specification. Notice that the diagram on the left provides a pictorial representation of the workflow structure described in the business use case text on the right.
Figure 1: Example of a business use case specification
Corresponding workflow description for Figure 1.
- The Customer Sales Interface initializes contact.
- If the Customer Sales Interface determines that initial opportunity work is complete, then the Customer Sales Interface sends a proposal request to the Proposal Owner.
- Otherwise the Customer Sales Interface searches for alternatives.
- If the Customer Sales Interface finds an alternative, then go to Start.
- The Proposal Owner creates a proposal project plan.
- The Proposal Owner sends the proposal project plan to the Quote Owner.
- The Quote Owner prepares a quote.
- The Quote Owner sends the quote to the Proposal Owner.
- The Proposal Owner analyzes the proposal and finalizes the proposal.
- The Proposal Owner creates a delinery project plan.
- The Proposal Owner completes additional information.
- The Proposal Owner sends the proposal to the Customer Sales Interface.
- The Customer Sales Interface presents the proposal.
- The Customer Sales Interface obtains the customer decision.
The components of the diagram shown in Figure 1 are listed below.
- "Swim lanes", or columns, show which business worker is performing each activity. A business worker would not be shown in an activity diagram for a business use case itself, but it would be shown as part of the business use case realization.
- Activity states represent the performance of an activity or step within the workflow.
- Transitions indicate which activity state follows another. This type of transition is referred to as a completion transition. It is a specific type of transition that is triggered by the completion of the activity represented by an activity state.
- Decisions each have a defined set of guard conditions. Guard conditions control which transition, among a set of alternatives, is triggered by the completion of an activity. Decisions and guard conditions allow business analysts to show alternative paths in a business use case workflow.
Business use cases and simulation prototyping
User interface prototypes can greatly facilitate the process of validating business use cases with users. The feedback obtained through interface validation should be incorporated into the business use case specification, but it is important to generate the use case specification before prototyping. Putting simulations in front of users too early in the requirements cycle risks missing out on a full definition of the problem being addressed. The business analyst must start with the business use cases in order to understand the problem, and then understand the process flow, before starting to design the page flow. In other words, the business analyst needs to understand the business process before designing simulations of specific pages.
The business analysis model
While the business use case model describes what happens between business actors and the business -- making no assumptions about the structure of the business or how it achieves its goals -- the purpose of the business analysis model is to describe how business use cases are performed. The business analysis model concretely defines the services offered by the business, defines the internal business workers and the information they use, describes their structural organization into independent units, and defines how they interact to realize the behavior described in the business use cases.
The business analysis model describes the realization of business use cases by providing an abstraction of how business systems, workers and other entities should collaborate in order to perform the business use cases. It also defines the external business services that are invoked by business actors in the performance of business use cases.
The business analysis model is used by stakeholders and business process analysts to understand how the business currently works (in as-is form) and to analyze the effects of changes to the business (in to-be form). The model is also used by systems analysts to derive requirements for automated systems that will be used as part of business processes. Software architects use the model to define a software architecture that fits the organization seamlessly, as well as to identify classes in software analysis and design models. Because the same model is used by the business side and the IT team, the two groups are "speaking the same language" about, and thus better able to meet, the real needs of the business.
Business use cases and the software development lifecycle
While business modeling can be done either independently of or as part of a business process reengineering effort, it adds value to the software development process in either case. Specifically, business modeling helps to define system requirements. For a development team, part of the requirements process is to analyze the problem being solved. Performing this analysis in the greater context of the business can help ensure that the system it builds will meet business goals.
In fact, a UML-based business model can be a direct input to a requirements model. RUP defines direct mapping between the two. If you map a business model to an analysis model:
- A business process that is to be automated will be represented as a use case.
- A business use case will become a subsystem.
- Each business entity will become an entity class.
This mapping provides a head start for nailing down the requirements and for the analysis and design workflows. When an organization is complex and trying to automate significant functions, a business use case model can be invaluable. Making sure that the enterprise solves the right problem in the business context can mean the difference between success and failure for the business. Using the UML to model business and requirements is a best practice in focused communications and excellent project outcomes.
Tool support for business use cases
Because it is so important not only to get requirements right, but also to communicate them in a way that is accessible to all project team members, tools that automate the translation of textual use cases into visual models offer significant time savings.
Common errors are often more easily identified in diagrams, so the ability to quickly generate visual representations of written use cases greatly expedites an iterative requirements validation process. And projects often run into trouble because business people think in words, while architects and engineers respond to models. This communication gap is best overcome by text and diagrams that work together. Obtaining complete requirements -- and accurate visual models -- in the early days of a project is critical for achieving success in later stages of the development lifecycle.
Figure 2 indicates where popular requirements definition, management, and modeling tools fit into RUP for application development.
Figure 2: How popular requirements definition, management, and modeling tools fit into RUP for application development
IBM Rational RequisitePro® is a requirements management tool that lets teams share requirements using familiar, document-based methods while leveraging database-enabled capabilities such as requirements traceability and impact analysis. Results include better communication and management of requirements, as well as an increased likelihood of completing projects on time, within budget and above expectations.
IBM Rational Software Modeler is a robust, UML 2.0-based visual modeling and design tool. It enables architects, systems analysts, designers and others to specify and communicate development information from several perspectives and to various stakeholders, while providing rich support for modeling with UML 2.1.
RAVEN from Ravenflow is a validated "Ready for IBM Rational" partner product which is designed to help teams develop and validate business use cases. The "Ready for IBM Rational" designation indicates that RAVEN meets Rational integration guidelines; it interoperates safely and provides consistent user experience when used with Rational products. RAVEN allows analysts to quickly specify and validate business use cases with all project stakeholders and users by automatically creating diagram views from business use case text. It interoperates with Rational RequisitePro to store the business use cases in the RequisitePro database.
Resources - Participate in the discussion forum.
-
Register for the Webinar today
The automated solution for authoring, validating and managing business requirements: Ravenflow and IBM Rational RequisitePro
September 5th, 2007 - 12pm EDT - Sponsored by Ravenflow
Accurately aligning business objectives with IT delivery is critical to delivering innovative business applications. Unfortunately, this is much easier said than done. Poor communication of complex requirements often results in projects that are delivered late, over budget, or without features needed by the business. Attend this webinar to learn how Ravenflow and IBM Rational's RequisitePro form a complete solution for getting requirements right and successfully managing them through the development and delivery of business application projects and see a live demo of the integration.
- A new forum has been created specifically for Rational Edge articles, so now you can share your thoughts about this or other articles in the current issue or our archives. Read what your colleagues the world over have to say, generate your own discussion, or join discussions in progress. Begin by clicking HERE.
-
Global Rational User Group Community
About the author  | 
| | Adam Frankl is VP of Marketing for Ravenflow. He is also the editor of Requirements Development Journal. Previously, he was the founding editor of Rose Architect, the magazine from Rational Software dedicated to visual modeling with UML. He also was director of marketing for Rational Rose and the UML at Rational Software. He started his career as a Requirements Engineer at the Lockheed Skunk Works after serving as an infantry captain in the US Army. |
Rate this page
| 
