Capturing requirements with Business Motivation Model, IBM Rational RequisitePro, and IBM Rational Software Modeler

Use these tools to better understand the who, what, why, and how of business requirements

Delivering timely, business-relevant solutions starts with understanding the requirements. Good requirements analysis can greatly increase the chances of developing solutions that address the problem. Capturing requirements is facilitated by a clear separation among who, what, why, and how. Managing them requires rich links to the things that fulfill them. This article describes extensions to IBM® Rational® RequisitePro and IBM® Rational® Software Modeler that support the OMG Business Motivation Model (BMM) to graphically model business requirements, the relationships between them, and relationships to the things that fulfill them.

Jim Amsden (jamsden@us.ibm.com), Senior Technical Staff Member, IBM, Software Group

Jim Amsden is an IBM Senior Technical Staff Member with over 20 years of experience in designing and developing applications and tools for the software development industry. He holds a Masters in Computer Science from Boston University. His interests include contract-based development, agent programming, business-driven development, J2EE UML, and service-oriented architectures. He is co-author of "Enterprise Java Programming with IBM WebSphere". His current focus is on finding ways to integrate tools to better support agile development processes.



01 April 2008

Also available in Chinese Russian

About this article

This article describes a common requirements model implemented as an IBM® Rational® RequisitePro® template and corresponding UML profile that is available from IBM® developerWorks®. (See Downloads.) This will satisfy the minimum requirements management capabilities described below and provide a basis for new capabilities. Here's what you will learn about in this article:

  • The use of the Object Management Group (OMG) Business Motivation Model (BMM) as an example of a standard requirements management metamodel.
  • A RequisitePro template for BMM, including requirement types and applicable traceability, as well as attribute and traceability tree views to support the BMM relationships
  • A BMM UML (Unified Modeling Language) profile that corresponds to the RequisitePro template
  • The element, requirement, and link-creation relationships between the BMM UML profile and RequisitePro requirement types
  • How to access and install the profile and template
  • Examples for using the template and profile

Using BMM provides a simple, easy starting point for a requirements management metamodel, which is based on a standard that is practiced in the business. BMM enables you to use tools to understand the meaning of requirements and how they relate to the business processes and IT solutions that fulfill them. This is difficult to do effectively if there is no standard or consistent requirements metamodel or if the metamodel is so general that the requirements carry little semantic meaning.

BMM is also sufficiently generic that it can be used to capture business requirements about any domain. That is, BMM can easily be used to capture business requirements, governance requirements, IT application development requirements, nonfunctional requirements, and so forth across the application lifecycle

Requirements definition and management

Requirements definition and management is a broad topic that is beyond the scope of this article. However, it requires the ability to do these things, at minimum:

  • Model semantically rich requirements and the relationships between them
  • Connect requirements with the solutions that fulfill them in a way that exploits the meaning of the requirements and the solutions for better verification, validation, and change management
  • View and query requirements for traceability, change management, reporting, and assessment
  • Access requirements easily and update them by using a Web browser
  • View and edit requirements as rich text
  • View and edit graphic representations of requirements and their relationships

Rational RequisitePro provides requirements capture, definition, and management capabilities. IBM® Rational® Software Architect supports UML modeling to show how those requirements may be fulfilled. RequisitePro is integrated with Rational Software Modeler so that it is possible to visualize requirements and connect model elements to the requirements that they fulfill.

RequisitePro includes several requirements templates that you can use to configure requirements databases with the necessary requirement types for particular project needs:

  • Blank template
  • Composite template
  • Create from baseline template
  • RUP® template (IBM® Rational Unified Process®)
  • Traditional template
  • Use case template

Although these templates are quite useful, they may not be sufficiently business-oriented for some users nor deal with requirements in a sufficiently generic way to be applicable across the whole development lifecycle. This can result in requirements that may be difficult for business analysts to manage due to improper requirement types and relationships. It may also result in complex links between RequisitePro databases that have different requirement types to support the complete application lifecycle.

Rational Software Modeler can create models that have profiles applied. You can use these profiles to extend UML to support visual requirements modeling. It is also integrated with RequisitePro so that requirements may be created and linked across the tools. Rational Software Modeler includes these profiles:

  • Analysis profile
  • Business Modeling profile
  • Software Services profile

The Business Modeling profile has stereotypes for Business Goal and Business Service, and these stereotypes correspond to requirement types in the RequisitePro RUP templates. There are also requirement types for various styles of use-case modeling, such as business use cases and system use cases. But these profiles support limited requirements modeling, especially for business requirements.

Many IBM customers create their own RequisitePro templates and UML profiles for requirements modeling. But this can result in nonstandard requirements and inconsistent relationships between requirements and the things that fulfill them. A more standard approach to requirements management makes business integration through services easier.

Therefore, what is needed is a standard RequisitePro template and a corresponding UML profile that supports the requirements management capabilities. Having such a standard not only supports richer requirements modeling, but enables the development of tools that can more effectively manage requirements if those tools can interpret what the requirements mean and how they relate to other artifacts in solution design and development.

Business Motivation Metamodel overview

The OMG Business Motivation Metamodel is a simple metamodel for capturing business requirements. This metamodel focuses on capturing semantically rich requirements that are useful for business analysis, querying, impact analysis, change management, and business reasoning. BMM is one several OMG standards developed by the Business Modeling and Integration Task Force (BMI-TF):

You can get more up-to-date versions of these documents from the Catalog of OMG Business Rules and Process Management Specifications (see Resources).

BMM is a practiced approach to capturing business requirements that was finalized as an OMG standard in October 2007. We are now seeing the emergence of supporting tools, including Xactium Business Motivation Solution. This represents an opportunity to provide capabilities that go beyond simple lists of linked requirement elements. Such lists support limited traceability but lack sufficient semantics to reason about the relationships between the requirements themselves and the elements that are intended to fulfill them.

BMM captures business requirements across different dimensions to rigorously capture and justify why the business wants to do something, what it is aiming to achieve, how it plans to get there, and how it assesses the result:

  • Ends: What the business wants to accomplish, not how
  • Means: How the business intends to accomplish its stated ends
  • Directives: The rules and policies that constrain and/or govern the available means
  • Assessment: Who and how the means are assessed against the ends, and the resulting potential impact
  • Influencers: Who or what judges or otherwise influences the assessment

Tip:
For further detail on BMM, see the OMG BMM Specification (see Resources).

The diagram in Figure 1 provides an overview of BMM. Not all of the metaclasses in this metamodel are included in the RequisitePro template and UML profile, because some of them are abstract superclasses.

Figure 1. Overview of BMM
Complex diagram that readers can click to see a larger version

Larger image of Figure 1.

Download and install the BMM profile and template

The BMM profile was developed by using the new profile generation tooling in Rational Software Modeler 7.0.5 to develop a profile plug-in and UI. This profile is a sample of how to use Rational Software Modeler extensibility mechanisms to support new modeling features. It may also be useful for capturing business requirements and linking them to the other model elements that fulfill them. However, this profile and the RequisitePro template are samples that are not supported parts of the Rational Software Modeler or RequsitePro products.

Follow these steps to install the BMM UML profile:

  1. Download and unzip the Business Motivation Model Profile (see Downloads).
  2. Start Rational Software Architect 7.0.0.5 or later and invoke Help > Software Updates > Find and Install.
  3. Select Search for new features to install.
  4. Click New Local Site, and navigate to your unzip location and select the Business Motivation Model Profile folder (see Figure 2).

The new site will appear in the Sites to include in search list, which is shown in Figure 2.

Figure 2. New site
Screen capture of Update Sites to Visit screen with BMM Profile selected
  1. Click Finish to see the features to install.
  2. In the Updates Search Result (Figure 3), select the Business Motivation Model profile.
Figure 3. Select the Business Motivation Model profile
Updates screen with BMM Profile selected as the feature to install
  1. Click Next. and accept the license agreement.
  2. Click Next to show the installation location.
  3. Click Finish to accept the default location and install the new feature.
  4. The update installer will prompt you to restart your workbench so that you can use the newly installed features.

You may now create UML models from the BMM template (Figure 4) or apply the BMM profile to an existing model (Figure 5).

Figure 4. Create a UML model from the BMM template
Create Model screen showing Categories, Templates, File name, and Destination folder
Figure 5. Apply the BMM profile to an existing model
Select Profile screen with Deployed Profile checked and Business Motivation Model chosen

The model now has additional capabilities of creating and linking BMM model elements, as shown in Figure 6.

Figure 6. New options for creating and linking BMM model elements
Modeling View overlaid by drop-down menus showing Add BMM and Goal options selected

Larger image of Figure 6.

Follow these steps to install the BMM RequisitePro database template:

  1. Navigate to your Rational Software Architect or Rational Software Modeler workbench installation location (usually D:\SDP70).
  2. Navigate to plugins\com.ibm.xtools.uml.profiles.bmm.ui\RequisitePro templates.
  3. Copy the BMM template folder to the RequisitePro templates folder (usually D:\Program Files\Rational\RequisitePro\templates).

Now, when you start RequisitePro, you can create a new RequisitePro Project by using the BMM template, as Figure 7 shows.

Figure 7. Create a new RequisitePro Project by using the BMM template
Create Project view in RequisitePro with BMM Template icon selected

BMM profile and template summary

BMM is supported by a UML profile and corresponding RequisitePro project template. This supports the integration of diagram views, rich text, and database query views of requirements. Diagram views are important to support high-level views of a network of related requirements that do not fit into simple list or tree views. Rich text views provide a way to effectively document requirement details. Database queries support the ability to search for and trace relationships between requirements, as well as help assess the effect of change.

The sections that follow provide a high-level summary of the BMM profile and corresponding RequisitePro requirement types.

BMM profile

The BMM profile is shown in the following diagrams (Figures 8 through 12). The stereotype descriptions are the same as the descriptions of the corresponding RequisitePro requirement types and are given in Table 1 in the Requirements artifacts section, which follows.

Figure 8. Business Motivation Model
How Mission, Vision, Courses of Action, Desired Reslt and Directive re: Means and End
Figure 9. Ends
How Goal, Objective, Vision, Desired Result, End feed into Motivation Element stereotype
Figure 10. Means
Diagram of Means, Motivation Element and related stereotypes

Larger image of Figure 10.

Figure 11. Influencers
Directive, Regulation, and InfluencerCategory to Influencer, then to MotivationElement
Figure 12. Assessments
How Assessments affect other elements and, ultimately, MotivationElement, Means and End

Larger image of Figure 12.

Figure 13. UML extensions
Shows all stereotypes with arrows to the Artifacts metaclass

As you can see, all of the BMM stereotypes extend the UML 2 artifact. An artifact is a kind of class that is the specification of some piece of information that is used or produced by a development process. It was chosen as the root element for BMM stereotypes for this purpose, as well as to exploit its default display properties, which do not show the owned attributes and operations.

Requirements artifacts

This section describes the RequisitePro document and requirement types that correspond to the stereotypes in the previous section and support the development of BMM requirements models when using RequisitePro.

Document types

Table 1 describes the default document types included in this template and their associated default requirement types.

Table 1. Document types and associated requirement types
Document typeDescriptionDefault requirement type
Vision (VIS)A Vision describes the future state of the enterprise, without regard to how it is to be achieved. Vision is an overall image of what the organization wants to be or become. It usually encompasses the entire organization and is long-term in its perspective. Vision (VIS)
Use-Case Specification (UCS)This is the use case description and elaboration.Use Case (UC)
Glossary (GLS)The glossary is used to capture common vocabulary terms.Glossary Item (TERM)
Mission (MIS)A Mission indicates the ongoing operational activity of the enterprise. The Mission describes what the business is or will be doing on a day-to-day basis.

A Mission makes a Vision operative -- that is, it indicates the ongoing activity that makes the Vision a reality. A Mission is planned according to Strategies.

Supplementary Requirement (SUPL)
Requirements Management Plan (RMP)This document type describes requirements and strategies specific to the management and development of the project.Default for documents without requirements (NONE)

Requirement types

Table 2 describes the default requirement types included in this template.

Table 2. Default requirement types included in the template
Requirement typeDescriptionAttributes
Assessment (ASMT)An Assessment is a judgment about some Influencer that affects the organization's ability to employ its Means or achieve its Ends. In other words, an Assessment expresses a logical connection (fact type) between Influencers and the Ends or Means, or both. Priority, Type, Status, Difficulty, Stability, Risk, Planned Iteration, Actual Iteration, Origin, Contact Name, Enhancement Request, Defect, Obsolete
BusinessPolicy (BPOL)A Business Policy is a non-actionable Directive, the purpose of which is to govern or guide the enterprise. Business Policies provide the basis for Business Rules. Business Policies also govern Business Processes.Priority, Type, Status, Difficulty, Stability, Risk, Planned Iteration, Actual Iteration, Origin, Contact Name, Enhancement Request, Defect, Obsolete
BusinessRule (BRULE)A Business Rule is a Directive that is intended to govern, guide, or influence business behavior in support of Business Policy that has been formulated in response to an Opportunity, Threat, Strength, or Weakness. Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete
Business Use Case (BUC)A use case that captures requirements from the perspective of key external stakeholders involved in potential value exchange.Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete
Glossary Item (TERM) A term that is used in the project's common vocabulary becomes part of the glossary. (Not applicable)
Goal (GOAL)A Goal is a statement about a state or condition of the enterprise to be brought about or sustained through appropriate Means. A Goal amplifies a Vision. That is, it indicates what must be satisfied continually to effectively attain the Vision.Priority, Status, Difficulty, Stability, Risk, Enhancement Request, Defect, Contact Name, Obsolete
Influencer (INFL)Influencers are those entities that can impact the enterprise in its employment of Means or achievement of its Ends. This impact has influence that is judged in Assessments.Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete
Mission (MIS)A Mission indicates the ongoing operational activity of the enterprise. The Mission describes what the business is or will be doing on a day-to-day basis. A Mission makes a Vision operative.Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete
Objective (OBJ) An Objective is a statement of an attainable, time-targeted, and measurable target that the enterprise seeks to meet in order to achieve its Goals. Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete
PotentialReward (RWRD) A Potential Reward is a kind of Potential Impact that indicates the probability of gain. Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete
Process (PROC) A Process represents a means of realizing a course of action or fulfilling desired results.Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete
Regulation (REG)A Directive may act as some other Organization Unit's Regulation. The Business Rules and Business Policies determined at one level in an organization may be effectively the law (Regulation) for lower-level organizations.Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete
Risk (RISK)A Risk is a kind of Impact Value that indicates the impact and probability of loss.Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete
Strategy (STRAT)A Strategy is one component of the plan for the Mission. A Strategy represents the essential Course of Action to achieve Ends — Goals in particular. A Strategy usually channels efforts towards those Goals. Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete
Tactic (TACT)A Tactic is a Course of Action that represents part of the detailing of Strategies. A Tactic implements Strategies. Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete
Use Case (UC)A description of system behavior in terms of sequences of actions. A use case should yield an observable result of value to an actor.Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete
Vision (VIS)A Vision describes the future state of the enterprise, without regard to how it is to be achieved.Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete

An example

The following example (not included in the download) was created by using Rational RequisitePro 7 and Rational Software Modeler 7.0.5. It uses the RequisitePro BMM template, BMM profile, and RequisitePro Eclipse client and Requirements perspective to create a simple business motivation model. This example shows how the various views of requirements are created and integrated and how requirements are connected to the elements that fulfill them.

Scenario

JK Enterprises is a (fictitious) global financial organization that is involved in a business optimization program to improve how they handle opening customer accounts. JK Enterprise's Business Process Optimization (BPO) effort, called Project Enterprise, identified opening an account as one of the key business processes that needs improvement and automation. Account opening consists of account sales, application, verification, and activation.

Goals: JK Enterprises wants to address its account management process to improve efficiency, reduce costs and latency, and increase customer satisfaction.

To achieve these goals, the project manager, Patricia, initiated the AMS Prime project to improve and automate parts of the account opening process. Business analyst Bob's job is to capture and analyze the requirements for this project and to provide initial business use cases that describe what the new account management process must do.

Bob's first task is to determine the business requirements for the AMS Prime project. He starts by understanding the executives' business vision. Next, he determines the specific goals and quantifiable metrics that amplify the vision and then determines the strategies and tactics that support the achievement of these objectives.

The business Vision and Mission are captured in a RequisitePro project, diagram, and rich text document.

The Requirements Explorer shows the Account Management requirements project, the organization of the requirements into folders, and the Account Management Services Vision.

Figure 14. Account Management requirements
Requirements Explorer view showing requirements in folders, including one for Vision

The diagram in Figure 15 shows the relationship between the Account Management Services Vision and the AMS Prime project mission statement that makes this vision operative.

Figure 15. Relationship between the vision and the mission statement
AMS Prime icon with arrow that points to Account Management Services Vision icon

The details of the Account Management Services Vision are captured in a rich-text document (Figure 16). The entry in the requirements database, the model elements in the diagram, and the document are all linked together, thereby providing multiple views and navigation facilities for the same underlying requirements information.

Figure 16. Document that summarizes the Account Management Services Vision
Screen capture of the rich-text document

You can create these requirements either from the model or from the RequisitePro Requirement Explorer. To create them from the model, use the tools in the BMM palette or the items in the Add BMM pop-up menu. You can link the RequisitePro requirement to the model element by dragging the requirement from the Requirements Explorer onto the element in the model. RequisitePro does not currently support element and requirement creation policies that recognize UML stereotypes. Therefore, if you use a RequisitePro requirement to create a new UML model element, you will need to select the created Artifact and set its stereotype to correspond to the requirement type. Similarly, if you create a RequisitePro requirement from a BMM model element, you must set the RequisitePro requirement type to the type corresponding to the element's stereotype.

After reviewing the project's vision, Bob amplifies the vision with more specific business goals and then quantifies each goal with specific, measurable, achievable, realistic, and time-bound (SMART) objectives.

Figure 17 shoes the goals in the requirements repository.

Figure 17. Saved goals
Requirements Explorer view of Goals folder with subfolders for specific goals

Tip:
You can click the Goals item that is highlighted in Figure 17 to run a query that shows more detail in the Requirements Query view. Figure 18 shows the results.

Figure 18. Details of Goals item
Query results by requirement showing Priority, Status, Cost, and Difficulty

The goals and objectives can also be shown in a diagram, such as the one that Figure 19 shows. This makes it easy to see what goals amplify the vision and what objectives quantify the goals.

Figure 19. How objectives quantify the vision
Objectives that can be quantified, such as activities, time to market, system availability

Again, each element in the diagram is linked to its corresponding requirement in the Requirements Explorer (see the link arrows in the Explorer view in Figure 18) and the section in the Word document. This provides easy navigation between the different views.

Bob now knows what the business wants to achieve and why. He must now determine the strategies and tactics for how to meet the goals and objectives.

Figure 20 expands the requirements database to show the strategies and tactics that help achieve the objectives.

Figure 20. Strategies and Tactics folders under Courses of Action
Screen capture with the Tactics item highlighted (which can expand to show details)

Selecting the Tactics item (Figure 21) runs a query that provides additional detail on each of the tactics.

Figure 21. Query results showing details of tactics
Details including Priority, Type, Status, Difficulty, Stability and more

Larger image of Figure 21.

As with the business ends, you can also visualize the relationship between the business means and courses of action. The diagram in Figure 22 shows the strategies planned for the AMS Prime mission and the tactics that implement the strategies.

Figure 22. Strategies and Tactics in diagram form
Shows 3 tactics (as chess pieces) to implement the Improve Account Verification objective

Bob also links the business means to the ends that they fulfill (see Figure 23).

Figure 23. Relationships of means to ends
Diagram

Then he gathers the business policies and rules that govern the courses of action (Figure 24).

Figure 24. Illustrated view of relevant policies and rules
Diagram of loan policies that govern goal (action): Reduce Need for Additional Documentation

Bob has captured business requirements that express the desired business result, the courses of action that will achieve that result, and the directives that govern those actions. He is now ready to capture more detailed requirements for realizing these courses of action in a business and IT solution. Bob develops Business Use Cases to capture requirement details from the perspective of key external stakeholders (Figure 25).

Figure 25. Diagram of Business Use Cases
Screen capture

Bob can also connect the requirements to business components, system use cases, processes, service collaborations, or any other model element that describes how the requirements might be fulfilled in an IT solution (see Figure 26).

Figure 26. Comprehensive illustration of model elements
Screen capture of complex diagram with link to larger version

Bob's requirements model is now complete. By using this model, he is now in a good position to answer these questions when they inevitably arise:

  • What objectives does this service fulfill?
  • What strategies does this business process implement?
  • How well does this process meet its objectives?
  • If this process changes, what effect will it have on the objectives that it is intended to fulfill?
  • Is this process change compatible with business policies and rules?
  • Which goals have no quantifying objectives?
  • Which objectives are not supported by any strategy?
  • Which services implement this tactic?
  • Which objectives, strategies, tactics, business processes, and services are affected if this goal changes?
  • What is the business value of this service?
  • Why do we have this implementation? What is it for?

Traceability between the requirements and the things that fulfill them provides the information necessary to answer these and other important business questions.

Summary of benefits

The sample UML profile and RequisitePro template use Rational tool extensibility mechanisms to enable you to model business requirements that are based on the OMG Business Motivation Model standard. This approach helps provide a way to capture, validate, analyze, and manage changes of requirements. By using these tools and techniques, you will better understand the who, what, why, and how of business requirements.


Download

DescriptionNameSize
Business Motivation Model ProfileBusinessMotivationModelProfile.zip1274KB

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=297472
ArticleTitle=Capturing requirements with Business Motivation Model, IBM Rational RequisitePro, and IBM Rational Software Modeler
publish-date=04012008