Unified Scenario-Based Design, Part 1: Methodological principles

Did you ever wonder how to provide crisp requirements to system architects, designers, and developers? Do the written scenarios ever completely explain to you and your teams all the context of the environment in which the systems will run? How can you quickly adapt to continuous business requirement changes? How can you create the best interfaces for a system? Unified Scenario-Based Design is an end-to-end methodology that addresses the above questions, with the aim of creating systems that more easily fit the needs of the business that requires them.

Share:

Alex Donatelli, Senior Technical Staff Member, IBM Tivoli Software

Alex DonatelliAlex Donatelli is a Senior Technical Staff Member at IBM. He is the Chief Architect of the Tivoli Laboratory in Rome, Italy and the Manager of the Rome Central Architectural Team. He has been working with both his staff and the overall technical community in Rome and in Tivoli to improve the quality of the products. The Unified Scenario-Based Design work is one example of such efforts.



Roberto Longobardi (roberto.longobardi@it.ibm.com), Interaction Solution Designer, IBM Tivoli Software

Roberto LongobardiRoberto Longobardi is an Interaction Solution Designer at IBM. He has been working in several Tivoli development projects, in the areas of performance and availability and of workload management. Recently challenged to provide a redesign hypothesis for the IBM Tivoli Workload Scheduler user interface, he sought to greatly enhance the consumability of the solution by getting it nearer to its business and operational contexts. Unified Scenario-Based Design is the result of this joint experience with the Rome Central Architectural Team.



Rosario Gangemi (rosario.gangemi@it.ibm.com), IBM Tivoli Configuration Manager Architect, IBM Tivoli Software

Rosario GangemiRosario is a Senior Software Engineer in the Tivoli Laboratory in Rome, Italy. He is the lead Architect for IBM Tivoli Configuration Manager, with 15 years experience in software development as a software engineer, market manager, and people manager. In his various roles he has been architecting, designing, sponsoring, and driving implementation of complex enterprise applications. He works with partners and customers and has lengthy experience translating business needs into product and solution requirements. He received his master's degree in Physics from the Universita' di Messina.



Claudio Marinelli, IBM Tivoli Configuration Manager Designer, IBM Tivoli Software

Claudio MarinelliClaudio is currently a Senior Software Engineer and the chief designer for IBM Tivoli Configuration Manager, with 14 years of experience in developing and designing enterprise applications in the system management arena. He is considered a key expert in the RUP and J2EE, and his current focus is in software engineering best practices and Model-Driven Architecture.



29 November 2005

Also available in Chinese

Introduction

In recent years, companies have come to rely more and more on software that supports their dynamic business processes as a way to gain sustainable competitive advantage, or just to stay competitive. This has driven the need to create software that not only supports the stated business goals, but that can be adapted easily when those goals change. As software is normally used by people, a third element of the equation is the end-user of such software. Even the best-designed and developed piece of technology cannot perform magic if its use is perceived as difficult by its intended audience.

Two major disciplines that try to solve this equation have recently emerged, each with its strengths; Scenario-Based Design [1] and Outside-In Design [2].

Scenario-Based Design (SBD) is emerging as a key discipline that addresses the need to manage customer requirements effectively, and to make the integration of products in the customer environment easier. Its main goal is to drive technology integration. Although this approach is a good starting point, it is not complete yet. To avoid creating solutions that are inconsistent with the existing customer roles and processes, SBD must focus more on the users, what they do, and the context they live in.

The Outside-In Design (OID) methodology and process within IBM represent the last evolutionary step of User-Centered Design [3] and User Engineering [4]. The main focus is on the business context where the product line lives, or is targeted to live. The goal of OID is more specifically to define the Users of such products to better design their interaction experience. This makes OID very effective in the field of User interface design. If a weakness were to be found in the OID approach, it would be the lack of formal connections among the business context, the system context, and the user interface.

Both disciplines are built around the concept that understanding the customer's business context is the key to success. Both methods also recognize that understanding is not enough: communicating your understanding in an unambiguous form to all the involved stakeholders (including the customers) is at least as important.

The UML methodology is widely accepted as the language to describe software systems, so it seems natural to adopt the same language to describe the knowledge of the business context (the users and the user interfaces) too. This will give rigor to the approach and allow for linking the outcome to the system architecture in an undisputable way. The solution is therefore to rely heavily on formal modeling for the business processes, as is common practice today for software systems.

The aim of this set of articles is to describe an effective unified design methodology, based on the two complementary approaches of Scenario-Based Design and Outside-In Design. The methodology will lead to a rigorous and complete set of design specifications -- ranging from business context to systems' implementation -- with a key focus on the User experience. The name given to the methodology in these articles is Unified Scenario-Based Design (USBD).


Benefits of Unified Scenario-Based Design

The USBD methodology described in these articles is being piloted on the redesign of the IBM® Tivoli® Workload Scheduler (TWS) user interface, and is proving to give, among others, the following advantages:

  • Allows you to consider the business context and its goals as a key determining factor governing the constraints under which software is to be designed
  • Provides the possibility to:
    • determine whether the business goals are being supported correctly
    • identify which areas need more investments
    • spot conflicting goals
    • verify how tasks performed by users support business needs
    • design user interfaces that fit users' needs and goals
    The formal traces from the business process elements to the system elements provide you greater agility, in terms of the ability to adapt the software products quickly in reaction to changes in the business. By exploiting the fact that you are modeling the business processes and goals using the same formalism that you use to model the system, you can now have a single description of the entire end-to-end picture, from business needs to software products.
  • Creates unambiguous documentation and communication among the various teams participating in the software development cycle via the formal, UML-based modeling of users and of user interfaces
  • Gives you the ability to link the user interface and the system models, enabling you to find errors more easily. This allows you to apply all the best practices for designing software systems to the design of user interfaces.

This set of articles will discuss the desirability of a USBD approach that focuses on the end-to-end business environment where products live, rather than on just describing the business scenarios that surround a single product. By describing the way to link business needs to software implementation, these articles outline the way to capture business processes via process maps, goals, and class diagrams, and how to trace them with actual implementation. The series will also describe how you can formally represent user interfaces linked with system analysis. A natural evolution of the work around this methodology is an IBM® Rational Unified Process® (RUP®) customization that describes the process to support this methodology.

Note: Two areas covered by OID, the IBM Business Domain and the Milestone Process, are out of the scope of this integration. They do have value, and since their meaning is not changed as part of this work, they are not addressed here but are covered in the OID material.


Problems of a common practice

It is a common practice to render, due to a lack of formality, product specifications that substantially lack objective interpretation; this is very evident when you consider the inability to formally trace two fundamental specification artifacts like business processes and business goals against the application layer. This lack of objective interpretation severely weakens the common practice in cases where the business system must quickly react to new or updated requirements.

The following list summarizes the problem statement and outlines the major concerns with the current approach:

  • Modeling a system with only use-case driven UML specifications does not allow a good level of business reactivity. Even if this practice brings many benefits by focusing the analysis and design efforts on the usage dimension of a system, it is still not enough.
    • Implementing changes in reaction to new or modified business requirements is still a major challenge from both a time-to-market and quality perspective
    • Application development cannot efficiently react to changes happening in the business layer. This is because the business specifications are not sufficiently structured at the business definition layer, and because they are not efficiently traced to the application layer
  • A gap exists between the business and application layers
    • Business analysts and application analysts do not use the same language (such as UML) to formalize their systems
    • Specifications are not rendered identifiable in the current UML diagrams
  • There is a lack of traceability between abstraction layers
    • It is not easy for analysts to specify the evolution of the requirements when facing changes, or for designers to implement the required adjustments to the systems supporting those requirements
    • As a direct impact of this lack of traceability, analysts are not encouraged to formalize business reactions in separate models: both business rules and their usage constraints are mixed inadvertently in application use cases
  • The quality of the User experience is generally low
    • There is a poor understanding of products' Users, their goals and tasks, and most importantly how the products fit into the Customer business process
    • User interface designers and system designers do not use the same language (UML) to formalize their systems
    • User interface specifications can be ambiguous, and are not traceable to the actual system's UML diagrams

As proof of these statements, consider an example coming from real life: Figure 1 depicts three different scenarios, described in a verbal format as current best practices recommend. The figure also shows the list of requirements that have been identified from the scenarios, but with no link to the latter.

Suppose that the Update software stack scenario was not to include Step 8 anymore, as a consequence of a change in the process. Removing one step leads to two major problems in the current process. First of all, the process to determine the requirements set associated with the change is not deterministic, and therefore error prone. This is due to the fact that the link between scenarios and requirements is neither formally expressed nor supported by any tools. Second, the removal of the associated requirements and related use cases may have side effects on different scenarios, and there is no way of determining such effects.

Figure 1. Problem statement: an example from real life
Problem statement: An example from real life

In order to address this problem, USBD methodology provides the means for describing scenarios and requirements in a formal way, and for linking those to the systems and the User interfaces being designed.

The method is being piloted on the redesign of the TWS user interface, and the benefits achieved through the new approach are tangible:

  • All parties involved in the product development cycle, including the executives (who must make decisions about strategic directions), the product managers (who must keep in constant communication with the customer community), and of course the development team, have a clear understanding of the business context where the product line lives. Thus, everyone is on the same page when discussing requirements, features, and product positioning. Furthermore, the development team finally has the means to achieve the customer orientation that is always asked of them. Having defined which parts of a business process are common among all customers -- and which are implemented optionally -- also helps guide the prioritization of the product's features.
  • User scenarios are no longer pure conjectures, but have been derived from the business process and validated with the user community. In addition, by means of traces in the models, the development team can be sure that the use cases it is addressing actually support the targeted subset of scenarios. As far as the user experience is concerned, since they have described users and their goals in a formal way, the team can be sure that the addressed use cases support the user goals, and that their visual realization provides the desired functionality in a usable way that matches the users' skills.
  • The links between the user interface and the system models allow for more efficient reviews, thus resulting in more errors found earlier in the development cycle. Also, the development team can now apply best practices for designing software systems to the design of the user interface.
  • The development organization can react more quickly to changes in the business context. The introduction of the formal traces between the business and the system models lets development understand the impact on the system(s) caused by a change in the business needs. This enhances the always sought after business agility, and takes another step towards being an on-demand development organization.

Assumptions and key facts

This set of articles makes large use of concepts and artifacts that can be found in the modeling discipline. It does therefore assume some level of knowledge on your part regarding these concepts. Following is the basic knowledge needed to allow a comfortable reading of this article. Business Modeling (as per the standard RUP definition) will be used as the framework for representing the Customers' business processes. You can refer to Learn business process modeling basics for the analyst [5], Effective Business Modeling with UML: Describing Business Use Cases and Realizations [6], and Introducing the IBM Rational Unified Process essentials by analogy [7] for an introduction to this discipline.

The UML formalism is key to giving rigor to this approach, and to linking the outcome to the system architecture in an undisputable way. For an overview of UML, you can refer to Unified Modeling Language version 2.0 [8], the UML Distilled book [9] and UML Resource Center [10].

The IT Infrastructure Library (ITIL) [11] will be leveraged, following the same approach contained in the USBD methodology, as the system management reference business process.


Unified Scenario Based Design

USBD is the proposed unified design methodology to cover the end-to-end spectrum of software development. The objective is to be able to design a product that covers all or part of the modeled business process, and helps the intended Users achieve their identified goals with the best possible experience. Another aspect of development that USBD addresses is how to support communication channels between producers and consumers via a concise, yet complete, set of formal documents. These documents, or artifacts, allow unambiguous communication among the various interfaces and actors to enable a concise communication without losing information. USBD identifies process steps and associated artifacts that can be grouped into the following categories:

  1. Understanding the customer
  2. Understanding the users
  3. Conceptual design

Each one of these categories will be detailed in an article in this series. An additional article will discuss an IBM® Rational® Software Architect (RSA) or IBM® Rational® Software Modeler (RSM) profile and model templates that will be provided to ease the implementation of this methodology. The steps in the first two categories fall naturally in the Interaction Designer role, which includes the RUP role of Requirements Analyst and partially that of the Designer. The third category is covered by the product Architect and the Designer. This first article provides an overview of USBD, and introduces the case study that will be used throughout this series of articles to illustrate the concepts discussed. The other articles detail the activities and the related artifacts of the methodology.


Overview of the process and the case study

USBD will be described by leveraging a real-life scenario, in other words a case-study. The scenario has been developed in its entirety, but in these articles only a single path is described in detail to explain the methodology used. This section introduces the case study, based on an effort to understand how the TWS Operational Interface (hereafter referred to as the TWS Web UI) could be redesigned to better fit the market.

The case-study identifies the operational business processes in place at the customers that implement the workload scheduling automation. The IT Infrastructure Library (ITIL) is used to identify the best practices to leverage in that business context. The ICT Infrastructure Management and Service Support disciplines are the ones that match the problem at hand. The model suggested by ITIL is then reviewed and validated with people who are in close contact with customers of scheduling products (in other words, TWS), and eventually with the customers themselves.

As outlined previously, this is fundamental to understand the business context around any operational context for scheduling software, and falls into the Understanding the Customer category. Understanding such context translates into the need to formally define:

  1. The business process needed to implement the workload scheduling, including:
    • what are the different activities
    • how they are related
    • who is responsible for each of them
    • which artifacts are exchanged during the process
  2. The business goals, set by the organization, that the process supports. This includes understanding:
    • what are the business goals
    • how each of them is measured
    • who sets each goal

The way to formally model point 1 above is to use a Business Process Map and a set of detailed Business Processes. This is shown in Figure 2. The former represents in a compact way all of the identified business processes, and the relations among them. The focus is at the organizational unit level. Starting from the map, the business processes of interest can then be further detailed to better understand opportunities for automation.

Figure 2: Business Process Map
Business Process Map

Experience suggests that the same logical business process is implemented in different forms at various Customers. In practice, anyway, you will discover that the identified business context is made up of two major sections, the core and the customization. These articles describe how to leverage this variability.

The activities described in a business process are very high-level. In reality, each activity may be performed under the responsibility of the identified Business Actor by several other actors. The formalism to describe in more detail how an activity is performed, and by which actors, is to use Business Use Cases and their realizations.

For the case study, the business processes, the corresponding business actors, and a set of business goals are derived by interpretation of the ITIL documentation. Similarly, a set of business use cases are also derived and related to the business goals that each supports.

These two activities outline the approach to use to model business processes and the corresponding use cases. A crucial aspect of the USBD methodology is then the description and formalization of how the identified business processes support the business goals. This concept is captured in the Business Use Case Realizations. Each realization is used to relate an activity in the business process to one or more business goals via formal tracing, as shown in Figure 3.

Figure 3: Business goals and business use cases
Business Goals and Business Use Cases

This completes the analysis needed at the business level to identify the context under which the technology is being used, as well as the business goals it has to help achieve. The next logical step is to identify which parts of the processes can be automated.

The business modeling performed so far has identified a set of Business Workers who participate in business use case realizations. In principle, any one of these workers may be chosen to be automated. Once such a business worker has been identified, that will imply the definition of a System (the automated worker) and its User (the non-automated worker that exchanges messages with it). This will also identify the messages exchanged between the two that naturally define the use cases of the system. In this context, the business use case realization can also be considered the definition of a Scenario.

The way business use case realizations describe scenarios where users may interact with software systems is shown in Figure 4.

Figure 4: Business use case realizations as scenarios
Business Use Case Realizations as scenarios

Use Cases, by definition, represent the interaction of the system being modeled with its intended user. The need to understand and formally describe the identified users of the system(s) comes out of the experience. A very successful methodology used to model the actual or potential users of a product, or suite of products, is Interaction Design (IaD)--see Resources, [4]. USBD extends IaD to give it the rigor of UML, and to allow for tracing the outcomes of user modeling to the business and the system models.

During the design phase, software systems are usually decomposed into classes and subsystems, and the use cases are realized in terms of these elements. In case the system has a User front-end, it is also critical to design the UI rigorously. USBD approaches the problem by also describing how use cases are realized in terms of the UI elements.

Figure 5 shows how use case storyboards describe the screens that make up the User interaction, and how they are navigated for the specific use case.

Figure 5: System use cases and their realization in terms of storyboards
System Use-Cases and their realization in terms of Storyboards

Although describing the UI using UML has tremendous value inside the development team, the outcome can be difficult to use for customer validation. In this context, Visual Scenario Storyboards can still prove to be very effective; even more so if they are used to represent the identified scenarios, which will sound very familiar to Customers.

Another piece of the puzzle is the implicit relation between the user goals and the business goals. This relationship needs to be captured explicitly to ensure that user goals support the business goals. The relationship can be derived from the model by following the formal traces starting from a business goal, to the business use case realization, to the use case, and finally to the User Goal. Anyway, once this relationship has been identified, it can be made explicit in a class diagram that shows the associations among the two classes of goals.

Visual scenario storyboards -- and the relationship between business and user goals -- are shown in Figure 5.

Figure 6 shows an example that puts all the previous concepts together; it refers to a real case depicting a fragment of a business model partially covered by the TWS product.

Figure 6: Bringing the pieces altogether
Bringing the pieces altogether

Two other articles in this series provide more details on the topics described, and will provide an end-to-end example of how to put USBD into practice. A final article will explain how to use an RSA add-on to create the artifacts introduced.

  • Part 2: Understand the Customer and the User
  • Part 3: Develop a conceptual design
  • Part 4: Put the concepts to work

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=99115
ArticleTitle=Unified Scenario-Based Design, Part 1: Methodological principles
publish-date=11292005