use case white paper - customer dialogues · web viewrevision history date revision author reviewer...

S I E B E L S Y S T E M S , I N C .

USE CASES – BENEFITS OF USING ON SIEBEL IMPLEMENTATIONS

METHODS & SOLUTIONSGLOBAL SERVICES OPERATIONS

Document ID: document.docStatus: Published

Version Number: 1.0Version Date: 16 September 2005

1.1.1.1 Revision HistoryDate Revision Author Reviewer16 September 2005 1.0 Adam Bloom Seth M. Williams

1.1.1.2 Distribution ListContact Organization Date

The contents of this document are confidential and proprietary to Siebel Systems, Inc.

Copyright 2005, Siebel Systems, Inc. Use Case White Paper 17 May 2023

2

Table of Contents

2 WHO THIS IS FOR AND WHY READ IT?...........................................................................................5

3 WHAT IS THE ULTIMATE PROBLEM WE ARE TRYING TO SOLVE?..................................5

4 IF THE MAIN GOAL IS TO MAXIMIZE VALUE AND MINIMIZE COST...HOW DO ALL THE BUSINESS DECISIONS ABOUT VALUE AND COST GET MADE DURING A SOFTWARE IMPLEMENTATION’S LIFECYCLE?......................................................................................................6

4.1 VALUE DECISIONS............................................................................................................................64.2 COST DECISIONS...............................................................................................................................74.3 THE IMPACT OF VALUE AND COST DECISIONS OVER TIME..............................................................84.4 ADDITIONAL PROJECT SUCCESS AND FAILURE FACTORS.................................................................84.5 REQUIREMENTS UPSTREAM RELATIONSHIP TO PRIOR DECISIONS & DOWNSTREAM IMPACT TO FUTURE DECISIONS.......................................................................................................................................94.6 SUMMARY.......................................................................................................................................10

5 WHAT ARE USE CASES?.................................................................................................................10

5.1 LET’S START WITH THE DEFINITION OF REQUIREMENTS...............................................................105.2 WHAT ARE USE CASES?.................................................................................................................11

5.2.1 Actor – Goal List....................................................................................................................115.2.2 Use Case Briefs......................................................................................................................125.2.3 Fully Dressed Use Cases........................................................................................................12

5.3 OK, SO WHY USE “USE CASES”?..................................................................................................13

6 USING USE CASES WITH PACKAGED APPLICATIONS.........................................................14

6.1 TERMININOLOGY IN PACKAGED APPLICATIONS.............................................................................156.2 BUSINESS PROCESSES IN PACKAGED APPILCATIONS......................................................................156.3 FRAMEWORKS OF PACKAGED APPLICATIONS.................................................................................15

7 HOW TO CREATE USE CASES AT SIEBEL?...............................................................................16

7.1 SIEBEL USE CASES METHODOLOGY...............................................................................................177.2 ACTOR-GOAL LIST:.........................................................................................................................207.3 FILLING OUT THE USE CASE TEMPLATE........................................................................................217.4 APPENDING USE CASES WITH ADDITIONAL INFORMATION............................................................23

7.4.1 Appending Use Cases with Additional Actions......................................................................247.4.2 Appending Use Cases with Additional Field-Level Information............................................257.4.3 Appending Use Cases with GUI Design.................................................................................267.4.4 Turning Use Cases into Design..............................................................................................28

8 EXAMPLES OF USE CASES FIT WITHIN THE PROJECT LIFECYCLE...............................29

8.1 EXAMPLE OF USE CASE BASED ESTIMATING MODEL....................................................................308.2 EXAMPLE OF REPOSITORY-PROJECT ASSOCIATION........................................................................318.3 EXAMPLE OF ESTIMATION, WORK PACKAGES, AND STATUS.........................................................328.4 EXAMPLES OF APPENDING TEST DATA TO USE CASES..................................................................33

8.4.1 Test Case Preparation Example.............................................................................................338.4.2 Test Cases Example A............................................................................................................338.4.3 Tests Cases Example B...........................................................................................................34

8.5 EXAMPLE OF CREATING TRAINING AND HELP FROM USE CASES..................................................35

9 Conclusion..............................................................................................................................................38

About This Document


3

Version Date Authors/Contributors CommentsV01 4/26/03 A.Bloom -Initial outline created and content planned.V02 4/29/03 A.Bloom -Initial draft of content written.

-No references are included at this time.V03 4/30/03 A.Bloom -Applied styles and renamed headings for sections

-Updates to all sections based on review of some contributors listed below.

V04 8/6/03 A.Bloom -Incorporated feedback from multiple contributors.-Updated/edited entire text.-Added all examples.

Author: Adam B. Bloom

About the Contributors: Via formal and informal correspondances and discussions, the following colleagues have provided input and feedback into this white paper in various forms.

Contributors: Amy Beth VonheimSeth WilliamsKaz NakamuraHumbert PiscitelliDavid QuappDoug JahnsDeepa GoelThomas SchryverThomas Chun


4

2 Who this is for and why read it? Audiences for this white paper include stakeholders involved with a Siebel implementation – executives, technical consultants, business analysts, users, and implementation partners. Particularly those responsible for the overall success and requirements of the system. This paper intends to answer they question “Why should you use ‘Use Cases’ on your Siebel Implementation?” At a high level, this paper aims to provide the following:

Outline that the main goal of Software – to create value for it’s stakeholders. Show that early decisions (scope, requirements, and design) in the development cycle

have the greatest impact on the overall value and cost of a software implementation. Define Use Cases. There are many misinterpretations about Use Cases, when done

correctly, Use Cases are one of the most effective methods for capturing the information that describes what a software system should do for it’s intended users.

Use cases can be used to effectively manage a Siebel software project throughout the application’s lifecycle – adding value to each key phase of the process, facilitate improved communication between teams, and improve the knowledge transfer between resources.

Further related papers may also point out that: Use Cases can benefit and complement the recently published comprehensive set of

Siebel best-practices which include a company’s ability to manage Strategy, Governance, User Adoption, Process, and Technology.

Use Cases easily align to all metrics that would be involved in managing the application’s business use as well as it’s IT management and support.

The input to this paper includes and leverages many articles and books as well as the experience of the authors and their colleagues. Much of it is based on the book Writing Effective Use Cases by Alistair Cockburn. This paper does not intend to be panacea that will cure all implementation issues. The intention of this paper is to provide a perspective and gather feedback – the audience should deny or support the information within – help answer why this approach is good or why it is missing something.

3 What is the ultimate problem we are trying to solve?To keep it simple, let’s assume a few points of reference about the economics of business software systems to set a few ground rules and establish a basis for the next section. Some companies may measure software more subjectively and view these topics as ideal but unrealistic approaches to evaluating software value Others have strict financial accountability for any investment including software.

A) Business software systems basically exist for two reasons:1) Help companies save money (decrease bottom line; cost savings)2) Help companies make money (increase top line; revenue increases)

This “value capture” can be accomplished through many types of software functionality ranging from network software to e-document management to physics calculations – the brochures of any software vendor can be referenced for examples of the “ROI.”

B) Business software systems require monetary investments to plan, implement, and measure – see the IT budget of any company to obtain a perspective of these costs.

C) The logical purpose for a busines software system is that it generate a greater amount of value than it consumes.

D) The stakeholders of any business software system should be accountable for ensuring that the investment in a software system that ultimately creates benefits that outweigh the costs. While


5

this is every stakeholder’s intended accountability, it is not always the outcome. Often times, politics, mismanagement, focus on the wrong problems, politics, cost-center mentality, and other reasons get in the way.

E) Additionally, business changes – the software application’s lifecycle should allow for evolution as the business needs change. It has higher value if it is able to accommodate process changes and effectively achieve a longer useful life. The inability to flexibly and quickly support the realities of business change mean a shorter useful life of less value delivered.

Using these factors as a guideline, the problem we are really trying to solve with software implementations is figuring out a way to maximize value over the lifecycle of an application. Logically, it should be safe to assume that, when stakeholders have a clear and detailed picture over time, of how to get value from a system and how to minimize all the costs of a system, then they should be able to direct and maximize the investment and utility of that system.

It is also important to keep in mind that there is no overall silver bullet and requirements are ultimately dependent on knowing and picking the right problem, process, and metrics. As well, constraints such as legacy data, integrations, motivation, skills, time/attention, culture, and capital can also be limiting factors – even if the perfect system is built, there are elements that can keep businesses from getting usage and value from it. For the purposes of this discussion, the focus will be more narrow than the above constraints.

4 If the main goal is to maximize value and minimize cost...how do all the business decisions about value and cost get made during a software implementation’s lifecycle?

4.1 Value DecisionsThe decisions about the end-game value of a packaged software implementation are mostly made when the overall business objectives are decided by executives; however, it is very difficult to determine how much of these objectives will be addressed by the system until requirements are properly defined and agreed-to by business and IT organizations. The design dictates a majority of the remaining development costs, but at the point of complete and baselined requirements, the system’s “definition” should directly or indirectly “answer” most questions about the ability of the system to capture financial value – the accuracy and granularity of these “answers” are based on the company’s ability to 1) map the requirements to business processes and key performance metrics, 2) map business processes and metrics to financial controls, and estimate the expected improvement in the business processes and metrics created by the system. After requirements are complete (within a cycle), very little functionality is traditionally added or subtracted compared to the whole set of functionality (within a cycle).. Of course, there are exceptions, but, for the purposes of this definition, we will assume that major functionality revisions indicate that the systems’ requirements were not an actual baseline or were incomplete

Of course, the actual system-value cannot truly be measured until users are using it and an empirical comparison can be made on the metrics before and after the implementation. However, based on the argument that the complete definition of requirements (how users will use the system) also implies process improvements, it should be safe to say that the ability of the system to achieve business value should be quantifiable (best-case, expected, worst-case) by the time requirements are completed and baselined. For example:

Let’s assume a company has a manual process for rolling up forecasts via XLS spreadsheets and email. Executives look at some business metrics that show they have an issue - forecast inaccuracy. They research the cause of this problem within their


6

current forecast management processes. After identifying areas of improvement, they determine that the process for forecasting takes a lot of time because it is manual and gives them low accuracy due to each regional manager doing it their own way. They budget for a system that improves these process metrics: 1) Time (and money) spent managing forecast data would be reduced – 1000 employees save 2 hours each week. 2) Errors produced in forecasts would be reduced – this could potentially save a company millions if they use these forecasts to plan their supply-chain because overages and underages are expensive. At this point, the project is budgeted and planned. In the next step. The team writes the requirements for a forecasting system that should support the expected process improvements. Once the requirements are complete and give an accurate description of how the system will be used, the stakeholders show them (and perhaps a requirements-stage prototype) to users and get feedback on the estimated process improvements and financial gains expected.

Companies can nail down quantifiable improvements at requirements, but the challenge is that many companies don’t do it or don’t have a good approach for tracing from requirements to the “up-stream” process improvements and metrics.

4.2 Cost DecisionsOn the initial purchase of packaged application licenses, we will assume a company has more-or-less determined the cost of 1) client and server software licenses and maintenance fees 2) telecomunications fees and 3) client and server hardware costs -- all becuase they know how many users and servers will be used. Since TCO is company-specific, let’s assume that the capital expenditure (hardware, software, and telecom/network) represents 20-40% of total costs – let’s also assume these budgetary items are basically static costs. The remaining 60-80% of costs are in labor for support and development – whether a system undergoes 1 or 20 development cycles in it’s multi-year lifetime.

Figure is an example of TCO breakdown.

The remaining labor costs include the following processes and people: Development includes Management, Strategy, Analysis, Requirements, Design,

Development, Integration, Testing, and Deployment Processes. Support includes help-desk, training, maintenance, operations, and administrative

processes. These activities are usually performed after the initial development and is typically the smaller of labor costs, especially when development cycles continue. As well, poor development can often lead to increased support costs such as system downtime.


7

Of course, the actual costs cannot truly be measured until they are incurred and the costs can be measured. Each customer will have to analyze their own situation, but the assumption is that development labor is the largest cost of an implementation.

4.3 The Impact of Value and Cost Decisions over TimeIf the widest impacting decisions about value-creation and the widest impacting cost decisions are made during the requirements phase, what happens when requirements are changed or corrected downstream?

This figure assumes that for each requirement that is incorrectly specified, it costs 50 to 200 times as much to correct the mistake downstream as you would pay to correct the mistake at requirements time.

4.4 Additional Project Success and Failure FactorsThere is additional evidence published by many product and service firms within the software industry that correlates to these conclusions. Coming from a slightly different perspective, the Chaos Report (http://www.standishgroup.com/sample_research/chaos_1994_2.php) created by the Standish Group outlines what causes projects to succeed or fail:

Project Success Factors % of Responses1. User Involvement 15.9%2. Executive Management Support 13.9%3. Clear Statement of Requirements 13.0%4. Proper Planning 9.6%5. Realistic Expectations 8.2%6. Smaller Project Milestones 7.7%7. Competent Staff 7.2%8. Ownership 5.3%9. Clear Vision & Objectives 2.9%


8

10. Hard-Working, Focused Staff 2.4%Other 13.9%

Project Challenged Factors % of Responses1. Lack of User Input 12.8%2. Incomplete Requirements & Specifications 12.3%3. Changing Requirements & Specifications 11.8%4. Lack of Executive Support 7.5%5. Technology Incompetence 7.0%6. Lack of Resources 6.4%7. Unrealistic Expectations 5.9%8. Unclear Objectives 5.3%9. Unrealistic Time Frames 4.3%10. New Technology 3.7%Other 23.0%

Project Impaired Factors % of Responses1. Incomplete Requirements 13.1%2. Lack of User Involvement 12.4%3. Lack of Resources 10.6%4. Unrealistic Expectations 9.9%5. Lack of Executive Support 9.3%6. Changing Requirements & Specifications 8.7%7. Lack of Planning 8.1%8. Didn't Need It Any Longer 7.5%9. Lack of IT Management 6.2%10. Technology Illiteracy 4.3%Other 9.9%

Based on the list above, all of the above “success factors” (those in red) are intertwined with or completely defined during the requirements phase. This is further evidence of the impacts of requirements decisions and their importance.

4.5 Requirements Upstream Relationship to Prior Decisions & Downstream Impact to Future Decisions

If we consider that a project is a long stream of stage-and-gate business and technology decisions, then requirements sit in a critical position.

Before Initial Requirements: For most projects, the objectives, budget, ROI, and scope will have been decided before requirements are complete.

During Initial Requirements: For most consulting teams and IT shops, the end of the requirements is a key time to manage expectations surrounding the correlation or gaps between of ROI, investment, scope, process, metrics and the requirements. Ultimately, a mismatch between at this point guarantees a mismatch delivered.

After Initial Requirements: Additionally, the requirements feed every downstream phase includeing the following:

o Analysiso Design and Architectureo Developmento Unit Testing, System Testing, User Acceptance Testingo Support (help-desk, training, maintenance, operations, and administrative)


9

After Initial Deployment: Every item in the list above is impacted during the next iterations after the first deployment. The 20th iteration of a software package is impacted by the initial set of requirements!

Considering how requirements relate to value, cost, the impact of decisions over the implementations full lifecycle, there is no other conclusion but for companies to commit excellence to the management of requirements – it is every bit as important (and sometimes as expensive) as the physical product development mentality of picking the right product to take to market out of the 100 product ideas and concepts that never see the light of day. All-to-often, stakeholders take the first idea to market and drive down the value they can get.

4.6 Summary

Requirements are a very important blueprint for maximizing the value of a system: The up front value-oriented decisions are made before requirements and the system’s

description for achieving that value is made during requirements. Out of all cost-oriented decisons, the majority are greatly impacted by requirements. The requirements decisions are the most expensive to correct over time. The top project success and failure factors are related to requirements. Except for the steps before initial requirements, an implementation’s entire multiple-

iteration lifecycle is impacted by the initial requirements and each iteration by it’s requirement phase.

With the impact that requirements can have on the ability for a system to produce value, it is imperative that companies pick a process and methodology for managing these effectively. The approach recommended here is Use Cases which can also be called “Usage Scenarios.”

5 What are Use Cases?

5.1 Let’s Start with the Definition of RequirementsRequirements define the system and can include:

1) An explanation of the how the system will be used by people2) Definition of how the system will interface with other systems (used by other systems)3) Specific technical constraints or dependencies4) Performance, scalbility, availability, and other metrics5) Detailed business rules like required data formats or complex formulas6) Explanation of load, deployment, maintenance, back-up, and administration7) Explanation of business rules, security policies, usability, training, legal, political, and

other human elements humanRequirements do not always reflect the value or cost of a system or how to maximize value or minimize cost. This is a critical aspect of mapping requirements to process and metrics.

Regardless of what ends up being published or the methodology used, requirements should help clearly document the functionality to be delivered. To clearly document functionality, three groups need to be able to “consume” the information in requirements:

Stakeholders that represent end users and expect value from the system. Those involved with the next phase of work and use requirements to perform their tasks. Those managing the associated scope, process, time, resources, risks, and money

required to develop the functionality.


10

Diagram above shows General Project Phases

The “Consumer” Needs: Stakeholders, as an audience, care about a description of the system’s use – they want

to see it and experience it. From thier experiences, they can determine how acceptable the system will be to meet their process improvements and impact their metrics. Aristotle said, “Tell me and I forget; show me and I remember; involve me and I understand” which certainly holds true for meeting this audiences’ needs. Without meeting this, users often “change their mind” for what they wanted.

Developers involved with the next phases of work want a clear description of how the system should work and how it will be used by people or other systems – this allows them to structure, plan, and create what is desired. Support people want a definition and resource that is an accurate description of what the system does, what was built, and how users need to use it.

Management needs a way for requirements to correspond to scope, process, time, resources, risks, and money so that functionality can be managed and project reporting and metrics can tied to functionality.

With the needs outlined above, it is clear that the most important factors are that a system’s use is described and can be modular-ized for management purposes. For decades, methodolgies for managing software have been discussed and there are many options. The method promoted here is Use Cases, which are considered part of the Unified Modeling Language. Use Cases simply define, what a system should do from the perspective of a user (functionality) and is modular enough to correlate the functionality against all key project management measurements. It should be reemphasized (as in the beginning of this section) that use cases are typically the largest majority of requirements, but are not the entire set of system requirements.

5.2 What are Use Cases?

5.2.1 Actor – Goal ListMost simply, a use case can be described in a short verb-noun phrase like “Create Account” or “Find Service Request.” When adding a user (also called role or actor) to the goal, it provides context for who is allowed to perform this goal – “Organization-ABC-Salesperson Edits Account”. A simple list of these “user goals” define the beginning of a full use case as in the following table. The table also correlates the “User Goal” to project stakeholder, development, and management needs – the ability to show their scope and priority:

ID Actor Task-Level Goal In Out Priority001 Account Admin Manage All Account Information X


11

002 Sales Rep Manage All Account Information X003 Sales Rep, CSR Query Accounts X 1A business analyst can generate a very exhaustive list of potential goals very rapidly when a standard “naming convention” is used.

5.2.2 Use Case BriefsFor a slightly more detailed defiition, use cases include the definition of the primary actor, their goal, a brief description of what they are doing, and potentially a level. The following example is an informal Use Case “Brief”:

Actor: Salesperson Goal: Manage All Opportunity Information Brief Description: During his prospecting activities, a salesperson will want to create,

review, or change information about different opportunities. This will include specific information about an opportunity itself such as probability or close date as well as related contacts, team members, activities, etc.

Level: 3 (Group of individual activities)

The defintion of these elements: The actor represents a type of user, and it can also represent other systems or time. The goal is typcially a simple verb-noun phrase that is sometimes expanded for clarity or

to help differentiate similar goals. The brief description should quickly point out the context of use (within a process) or

further detail about the goal. This description is typically a shorter version of the use case “Full Scenario” (see below).

The level is often described in other company-specific terms. For example, Siebel uses Functional Domain, Process Domain, Sub-Domain, Business Process, Sub Process, Step. It’s purpose, is to allocate the level of detail that the use case describes. An example of a user-activity-level use case might be one that describes the specific ability to create an opportunity and what fields would be required and available to manage. Another may be a super-goal and set of sub-goals – Manage Opportunities would include the relating of multiple child entities such as create opportunity-attachments or opportunity-contacts.

5.2.3 Fully Dressed Use CasesIn a more detailed example of a “Fully Dressed Use Case” and explanation follows:

Use Case ID: ‘Action.EntityInitials’ (verb noun) is the basic naming convention. The name should offer some explanation of it’s detail – “Create.CustomerAccount.”

Event CommentsName: (Example) Create Customer AccountActor: Customer Service Rep, Sales Account Manager, etc.Level: Cloud, Kite, Sea, Fish, Clam – should explain the level of goals and help

define a hierarchy of goals as they match process. Could be 1, 2, 3, 4, 5 depending on how processes are modeled.

Goal: -(Example) To have a new Customer Account record reflect a valid and complete description of a Customer Account.-For high-level use cases, the goal should speak more to process improvements and metrics. For lower-level use cases, the goal should speak more to the specific intent of a user performing a more detailed task.

Scenario Briefs/Examples:

-Can be used to offer “day in the life narratives,” short descriptions of full scenarios, or context of business process activities. This should help developers understand what users will be doing when they develop the


12

system.Pre-conditions: -(Example) User logged into the system and has access to the

appropriate view. -This is a set of conditions that must exist before the use case can happen and can prevent certain cases from happening.

Trigger: Event that starts the scenario such as logging in, navigating, or hitting a button.

Full Scenario: -Scenarios can also be extended, re-used, split paths, and merge paths. Re-using allows scenarios that are low-level and common events to be stated once and re-used. There should be approiximately 7-10 steps in a scenario that form a list of user-action, system re-action elements as below. This is the critical portion that describes how the user will interact with the system:-(Example)1. User Navigates to XYZ

2. System shows XYZ View3. User creates new record4. User enters data5. User steps off record

6. System stores data and fires integration message

Data Usage and Stakeholder

Interests (Minimal, Guarantees, Validations, Successful

Ending):

-(Examples)1. Required fields during manual entry are completed in order for a

record to be captured correctly by the database.2. Certain fields are system-generated.3. Fields X, Y, and Z are Read-only.4. Integration message Use Case is successful (See integration use

cases)5. User’s attempt at completing goal is captured and any error is

logged (See error logging use cases).- The intent is that additional business rules are captured to guarantee certain events happen once a goal is started.

Data Conversion: 1. Notes about data conversion. Existing data and systems increase the Use Cases.

Assumptions: 1.Key assumptions are listedIssues/Concerns/ Risks/Questions:

-(Examples)1. Question: [ ] Is account status manually entered?2. Question: [ ] How is parent Account Name filled out?3. Risk: This area is completely custom and not out-of-the-box (OOTB)-This section should act as an audit trail

Interdependencies: Interdependencies may help to group use cases that must be delivered together to perform correctly. Information about downstream systems, other subsystems, or additonal project management meta-data can also be captured.

5.3 OK, So Why Use “Use Cases”?The benefits of using Use Cases:

1) User-centric – written in the perspective of those that will accept, use, and derive value from the system.

2) Supports all downstream efforts including analysis, architecture, design, development, testing, help, and training. If used by these teams, they will ultimately drive considerable efficiency thru cost, time, and resource-savings in the development and support cycles


13

becuase content will not have to be completely re-written for design, testing, training, or support.

3) Very common method for capturing business requirements.4) One of the most widely written about methodologies.5) Designed with object-oriented systems and applies to web services.6) Easy for non-technical workers to read and understand the use of the system.7) One of the most current and complete methodologies available to date, incorporates with

other development process methodologies such as activity diagrams and entity relationship diagrams.

8) Proven to be an effective and successful approach when used correctly.9) Have considerable support by software vendors who build tools for managing

requirements.10) Dovetail with other top methodologies for business process analysis as well as technical

design and analysis as part of the UML.11) Can be used effectively with project management techniques and activities.12) The basis is scenarios or narratives which most other methodologies also use in some

form.

There are only three reasons I’ve heard of why people don’t use use cases:1) No understanding or competency in using them2) It’s considered too much documentation3) We have another approach we like or are used to

With some clarification, two issues can be put to rest as obstacles and the other is a decision:1) Like any process, tool, or technique people use, it is important that the user knows how to

use it. Without this knowledge, misuse is a probable outcome – if you don’t know how to use a hammer, you may damage the wall or your thumb, and, with practice, one can master the use. I would not recommend using use cases without a committment to the proper approach and understanding.

2) The approach recommended here allows the author of the use cases to choose the depth of description for a given set of functionality. If a function is from a packaged application and is well understood by all stakeholders and developers, then the author should use an actor-goal list or a use case brief to limit the amount of necessary documentation. If a function is very complicated, very customized, and no stakeholders or developers are familiar with it, then the fully-dressed use case should be used. The goal is not to create documentation for the sake of documentation – it is to communicate effectively regarding the most value-impacting documentation a system will have.

3) There are other acceptable techniques that mostly are mostly based on similar use of scenarios or rapid prototyping (which should be incorporated regardless). An ad-hoc approach to “listing everything out that the system should do” is not acceptable.

6 Using Use Cases with Packaged ApplicationsThere are several things to keep in mind when using Use Cases with a packaged application like Siebel. Under most circumstances, use case methodologies suggest that the business requirements be completely separated from the GUI design. Futhermore, the UML-defined efforts surrounding the completion of Use Cases and particularly the steps for design and development almost always assume the system is being built from a blank slate. When managing use cases for packaged applications, there are some very important considerations – most importantly, we can assume that packaged applications have already been built, and they are being customized or configured by an implementation team:

1) Terminology for things (GUI elements, objects, data) already exists.2) Business processes may be imposed or defined by the application and thereby tie

requirements and OOTB functionality to a strict process.3) The technology is implemented with certain frameworks


14

Those facilitating requirements will constantly iterate through understanding how the customer’s current terminology, process, or applicaton maps to Siebel.

6.1 Termininology in Packaged ApplicationsThe application already has names for things – in discussing the application with business users, it will be important to explain the key terminiology used within the application and begin to align those pre-defined items with the terms the business uses. For Siebel applications, this could be terminology from a business process, user action on an item, functional area, GUI element, etc.

Business Process Examples – Pipeline Management, Order Management, and Forecasting, etc.

User Actions Examples – Merge, delete, query, drilldown, scroll, etc. Functional Area Examples – Agreements, Accounts, Service Requests, Activities, etc. GUI Element Examples – Screen Tabs, View Tabs, Queries Drop Down, Show More, etc.

When capturing use cases, those responsible for capturing use cases should be careful to introduce terms appropriately to allow the user to define their goals in their terms while still matching the user’s terms to Siebel terms. Importantly, users that are familiar with Siebel will be more likely to describe their goals in Siebel’s terminology. As well, the use case and requirements document templates should take terminology into account.

6.2 Business Processes in Packaged AppilcationsOften an applicaton’s product marketing team has studied many cusomter business processes and has worked to embed best practices or elements of these processes into the application. Balance is required during the course of discussions to understand the customer’s current business process, where the application might be forcing a different process, and what the appropriate solution is. There are only a few outcomes for these situations: a) the application is changed to support the customer’s business process b) the customer’s business process is changed to match the application c) some of both.

Pipeline Management – A certain number of phases and names exist out of the box. Order Management – A certain set of steps exist for different industries or channels. Forecasting – Customers might often run their forecasts from excel spreadsheets.

Siebel is often process-agnostic – a user can typically follow a business process by using any set of views in any order (Smarscript or Workflow-driven GUI would be exceptions). During the capture of requirements, being agnostic offers flexibility; however, many companies expect applications to provide users more of a step-by-step guide through a processes. What is important in the requirements capture is that the user’s goals are understood – the context of a process can be provided, but diving into the details of the processes implementation within the application should be avoided until the user goals are clearly understood. The idea is to provide a general notion of what the application does to gather an understanding of the customer’s goals. One approach would be to allow the user to define the process in their terms (use case briefs), and, in the following week, allow the business analyst to “Siebel-ize” the use cases while writing fully dressed use cases. The business analyst should also have a clear understanding of when and where to incorporate process into the use case template (order, organization, and hierarchy of use cases) and how and when to document things like navigation or workflow-driven GUI views.

6.3 Frameworks of Packaged ApplicationsFor every aspect of the the packaged application’s interactions to external user’s or systems and it’s internal interaction among it’s own subsystems, frameworks exist. By frameworks, we mean a basic structure or frame of reference that provides pre-existing ideas or guidelines for how the software operates. These frameworks are put in place to support object oriented system designs and include things like “model-view-controller” architectures or “windows GUI objects.” In the case of Siebel, these can include the following high-level components and examples:

GUI Framework – Navigation, viewing (Views and Applets), and querying capabilities.


15

Business Framework – Components, joining or linking entities, calculating fields, or adding code.

Data Framework – Database interaction and generation of SQL from GUI or business layer interactions.

Integration Framework – Java, XML, COM, etc.What is most critical regarding use cases and frameworks is two-fold. One, use cases that describe user interaction must adhere to certain architectural frameworks to ensure the use cases can be meanigfully organized in a fashion that mimics the applications frameworks – this applies to the template used and the approach to capturing user’s needs. Two, use cases that describe system interaction must often take user interaction into account as the triggerig event and may also need to cover multiple complex system goals being reached in certain orders. For example, siebel views correspond to certain navigational elements and certain querying capabilities – navigation to the “My Accounts” View means certain things happen – GUI changes, SQL is generated to bring certain data in the GUI, personalization rules may fire, etc. Adding a record in this view may also imply updating certain tables, having certain validation, requiring certain user keys in the database, and have integration workflows fire.

7 How to create Use Cases at Siebel?In a generic implementation (diagram below), the lifecycle goes in the following order: objectives, business process analysis, system requirements, design/architecture/gap analysis, development, testing, roll-out/training/support. Use Cases are captured towards the end of business process analysis, cover functional system requirements, and provide input into design/architecture/gap analysis.

Diagram above shows General Project Phases

At Siebel, this would take place towards the completion of an ePlan, at a high-level during the writing of the Scope of Work, and during requirements –before the Design phase (designated by the yellow in the diagram above).

A Statement of Work would provide the following input to requirements and Use Cases: Goals/Objectives Modules/Assets and Functionality Planned to deliver including:

o Named OOTB functions (Call Center, Email Response, etc.)o Users of the System (Call Center XYZ, Sales Group ABC, Partner 123, etc.)o High-level Requirements (Actor-Goal List such as Manage Service Requests,

Create Service Requests, Edit Service Requests)o Expected Object Configuration (Accounts, Opportunities, Activities, etc.) and

Levels of Configuration (High, medium, low)o Expected Conversion and Interfaces for key entities and datao Expected Changes to other systems for key entities and data

Critical Success Factors, Assumptions, and Risks Preliminary Approach, Budget, Effort, Staffing, and Scheduling


16

ePlan would provide the following input to requirements and Use Cases: High-Level Requirements

o Customer Needs: Business Drivers, Goals/Objectives, Reports, Stakeholder Requests, Glossary

o Customer Organization: Organization, Division, Role, Products, Channelso Solution: Solutions for Requirements, Applications, Modules, Screens, Viewso Technical Information: Systems, Interfaces, Software Requirements, Technical

Strategyo Project & Program: Project Team, Risks, Issues, Notes, Phases

Identification of Common or Business-Unit Specific Requirements Matrix that maps Goals to Processes to Requirements to Areas of Siebel Functionality

and provides Plans and additional SOW-related information (all items listed above)

Requirements, as mentioned above, flush out details about how users will use the system.

The Design Phase typically creates a document that includes several types of tables – these tables represent all the key object defitions to be changed in the repository and the key changes for each definition:

Application, Screen, View, Applet Business Object, Business Component Database Pseudo Code with Objects and Events Identified Integration Objects and Other Interfaces Physical and Logical Architecture ERD Data Load Mappings Administrative Data and Functions (Personalization, Product Definitions, Lists of Values,

Workflow, Assignment Manager, etc.)It is also worth mentioning here that, while use cases can capture sufficient detail, proper analysis of existing data must be done and an a clear design phase must still be undertaken before development truly begins. Data particularly, may be a limiting factor in the ability to deliver functionality (that is data dependent” or in the ability to deliver a usable system).

As mentioned, the outcome of the design stage is development and then testing – quite a bit of effort is undertaken here until the customer reveiws again in some kind of testing stage. In addition, the documentation the customer will be using to judge the effectiveness of the design, development, and testing is the requirements (and use cases). It is critical that these capture what the customer will be expecting without any confusion – implementations where there is confusion means that break-fix work during user-acceptance testing turns into “new requirements” or “enhancements” that the integrator fixes or the customer gets upset.

7.1 Siebel Use Cases MethodologyThere are books entirely devoted to explaining how to write use cases and this paper does not cover every detail. The use case “brief” and “fully dressed” use cases above are examples of the templates; however, these can be altered and more research and work needs to be done to come up with the “perfect” Siebel Use Case Template. While this paper’s focus is on the deliverable and not the process, a generic process is descbribed here. The generic process for requirements capture is known to most business analysts and project managers – it includes meetings, discussing goals and use cases, and preparing/reviewing detailed descriptions. In parallel, technical requirements that are non-Use-Case requirements (see section above: software constraints, performance, service levels, etc.) can be done. The organization of the process and activities to use cases is done as one would typically expect with the traditional rules for meetings


17

size, preparation, attendees, homework, parking lot, facilitation, etc. This could be used in more of a waterfall or a highly iterative cycle. Activities should include:

1) Preparation2) High-level kick-off Meeting – Set expectations via a) review how the objectives and

processes map to the user groups (from SOW or ePlan) b) the initial Actor Goal List (highest level description of use cases) and use case breifs are reviewed (and/or updated) as an outline of the use cases to be detailed. c) review of frameworks and terminology.

3) Analysis, Discussion, and Composition of Use Cases for expected user interactions with the system – this includes updates of any Use Case Briefs, detailing of Fully Dressed Use Cases, capturing key terminology, and discussion of process gaps.

4) Review of detailed use cases including field level requirements with the test cases for key scenarios captured.

5) Use Cases can be mapped to prototypical, actual, or designed GUI – these are separate, but related to the use cases.

The meetings should take place for situations where no system exists AND should also take place where systems are being replaced in any way (due to integration or decommission).

Real and existing data should be available before, during, and after these meetings to be reviewed by the business analyst and technical resources.

While use cases should be captured for conversion and integration, there is other technical information and assumptions that must be captured during this stage that use cases do not capture. Activity diagrams, sequence diagrams, data-flow diagrams or other UML based documents should be created and common objects and entities should be documented.

The output deliverable of these activities is a document that specifies: Objectives – Reference or reaffirm what was previously agreed to. Gaps must be

identified and managed when they have impact to scope. Business Processes – Reference or reaffirm what was previously agreed to. Gaps must

be identified and managed when they have impact to scope. This is particularly important where Siebel forces a business process because significant customization may entail.

Organizations/Actors – Reference or reaffirm what was previously agreed to. Gaps must be identified and managed when they have impact to scope.

Actor Goal List – This is a high-level list of the functionality of the system and should act as an outline to the use cases. It’s purpose is to help set the bounds of scope. It is also extremely useful in managing risks, planning budgets/resources/timelines, packaging development efforts, organizing design and architecture, etc.

Use Cases – Fully dressed and complete with all issues closed GUI – Mock, actual, or prototypical can be included. If managed appropriately, GUI

design can be completed at this point. Non-Use Case Requirements – Can be contained within this document or another for

data, systems, etc. Integrations can still be captured in use-case format.

There are several key points about use cases that are important enough to mention about the process before we explain the deliverable. These practices are typically missed when someone just looks at the Use Case template and begins to try and fill it out:

1) Filling Out Templates – Just because the template exists doesn’t mean anyone can effectively fill it out. Similarly, the format of most magazine articles or dotoral theses are all similar and follow a template, but that does not mean one can effectively write a magazine article or doctoral thesis – training is required. The template is extremely easy to fill out by an analyst with some training and experience. The organization of it requires more thought and much iteration – only those experienced with the application, use cases methodologies, and human factors will have an easy time ordering, organizing, and nesting use cases in a logical and easy-to-understand manner.


18

2) Actor-Goal Lists – As mentioned, these are the highest-level list of use cases. These lists contain just the actor (user) and the goal (verb-noun). This is extremely useful for a number of reasons and is almost completely forgotten. This list organizes and can correlate to scope, functional organization, level of detail, relationships to other use cases, development effort per use case, and, in the case of Siebel implementations, use of views, applets, controls, business objects, business components, fields, tables, and columns. Most importantly, it can help to manage scope discussions with any group on the team and drive assignment of work packages in development and accountability for areas that are integrated or interdependent.

3) Organizational Structure – Not only are there functional groupings, it is very critical to understand the level of detail the use case is trying to achieve. This is mainly due to the fact that goals have hierarchies. In the above example, the Management of All Opportunity Information is not as detailed as managing information about an Opportunity’s Activiy record or specific Opportunity fields. There is also the context of querying, inserting, deleting or editing records. Furthermore, it is important to organize use cases for re-use, linking, and extending them.

4) Homogenaiety – Use cases should be of the same approximate size (around 9 steps within the full scenario of a fully dressed use case). Often times, people will create some use cases that are many pages and others that are one step. The size should also align closely to development effort.

5) Consistency of Documentation – Consistency is of critical importance – the consistent use of verbs, nouns, templates, organizational hierarchies, etc. will drastically increase the reader’s ease-of-understanding and reading the document – consider it an instruction manual and keep the “lessons” consistent so that patterns become apparent and the reader doesn’t waste time wondering if two inconsistently handled elements should actually work the same way or not.

6) Misunderstanding or Incomplete Use Case Elements – Preconditions, guarantees, triggers, post-conditions, and other elements should be understood and documented to be complete. The analyst should know when to complete all areas, when to leave ommissions, and when to identify gaps from OOTB.

7) Avoid Early Over-detailing – Use cases should become more detailed as you go. Early in the process, an analyst should not be getting to the point of asking customers about field validation – this is really getting into latter aspects of documentation and GUI design. As well, if a function is a critical and customized item, it should be captured; otherwise, an analyst should rely on existing frameworks to define functionality. Analysts should be capturing a rule from stakeholders and determining a match for capabilities existing within the existing system. Use Cases can be used to model systems at a very detailed level of interaction; however, at a certain point, it becomes more important to use another diagram or method. Use cases can model black box mechanisms like the update of certain attributes based on the invokation of a method, but this should be done deliberately.

8) Overdocumenting – There are a few things to consider before creating a huge document. Use cases are modular and re-usable, you should not have to write the same detailed explanation over and over – looking for common cases will help “fold” use cases into others and reference them instead of re-writing. As well, if the function exists and is used without customization, then there should be very little documented versus an extrememly customized and scripted area that needs detail to elaborate appropriately. The “Brief” and “Fully Dressed” Cases can be interspersed in one document in order to reduce the amount of documentation.

9) Forgetting Exceptions and Failures – It is correct to start off writing the success scenario; however, many times the effort required to handle exceptions and failures multiplies that of the success scenario. Before the requirements are completed, one should cover failure cases – this is particularly critical for integrations with other systems.


19

7.2 Actor-Goal List:

Sample Actor-Goal ListID Actor Task-Level Goal In Priority Out

Account Admin Manage All Account Information XSales Rep Manage All Account Information XSales Rep, CSR Query Accounts X 1Sales Rep, CSR Create Account X 1Sales Rep, CSR Edit Account X 1Account Admin Delete Account X 3Sales Rep Query Account’s Team XSales Rep Create Account’s Team XSales Rep Edit Account’s Team XAccount Admin Delete Account’s Team XSales Rep Query Account’s Opportunities X 1Sales Rep Create Account’s Opportunity X 1Sales Rep Edit Account’s Opportunity X 1Account Admin Delete Account’s Opportunity X 3

This Actor-Goal list represents a preliminary list where things might still be changing. Again, the actor is a user type and the name represents an action (verb) on an entity or related entity (noun). Nouns include key entities within Siebel and verbs include Navigate, Query, Create, Relate/Associate, Dissassociate, Delete, and Merge (a comprehensive list is included below). Here are additional things that can be derived or included with this list (these can also be left out of the Actor-Goal list but included in an actual Use Case):

Scope -- This list can be used to determine what will be designed, developed, and deployed for a set of project project phases, projects, or even project teams. It can drive accountability and awareness amongst development areas that overlap within a team or across teams.

Functional Organization -- The Actors mapping to Task-Level Goals can define whether sales, service, or marketing organizations use the application. The names of the Task-Level Goals include nouns that represent entities – these can be grouped together by Accounts or Service Requests. The verbs are key actions (Query, Create, Edit, Delete, etc.) that are found on most applet menus and represent things that users do to records. Additional actions are outlined below.

Level of detail – The item “Manage All Account Information” is really a “super-goal” and is not a Task-Level Goal, it is more analagous to a Process or Sub Process (by Siebel’s Business Process Taxonomy). The Task-Level Goals are really sub-processes or steps within the taxonomy. “Manage All Account Information” is shown here because, at this point, we are not sure if there are actual user steps that need to take place at a “meta-data” level like managing master account information or if this is just a goup of goals with no corresponding Siebel views but is a Siebel screen. As well, we could add a column for goal or process level (Functional Domain, Process Domain, Sub-Domain, Business Process, Sub Process, Step) to help organize the hierarchy of this list, the hierarchy will need to be in place by the time use cases are complete, but aren’t necessary for the Actor-Goal list.

Categorizaton of Use Cases -- Grouping, categorization, and meta-classification of use cases is important and includes the ability to place value on a group of use cases, associate phases and package their delivery (things that must be delivered together), assign level of effort, or even associate them to types of development like workflow or scripting.

Relationships to other Use Cases – Siebel provides a very clear and consistent framework for relating entities (1:1, M:1, 1:M, and M:M). These relationships are established via Form Views (Parent Form Applet, Child List Applet), Pick Applets, and


20

MVG Applets. Furthermore, there can be multiple relationships, bidirectional, and different types of relationships between two entities. This framework can be easily captured by the verb within the Actor-Goal List.

o 1:1 or M:1 – Entities can be Created and Related OR just Related: 1:1 – Create (and Relate) Account’s Profile: An Account-Profile view has

two form applets. Create and Relate (Siebel can allow the creation of the profile form and relate it to the Account in the background by creating a foreign key)

M:1 – Relate Profile to Parent Account or Create Profile: An administrative All Profiles view has a pick applet for a user to pick an account for a single value field, relating the profile to it’s parent account.

o 1:M – Entities can be Created and Related OR just Related: 1:M – Create (and Relate) Account’s Opportunities: Account-

Opportunities view has a form and list applet where new opportunities can be created – perhaps every child opportunity has a required field that is a foreign key relationship to it’s parent.

1:M – Create Account’s Affiliated Account: Account-Accounts View has a form and list applet where new account relationships can be created, but the child list applet has a pick applet to create relationships and does not allow the creation of new accounts.

o M:M – Entities can be Related OR Created and Related: M:M – Relate Account’s Address: An Account-Address view could have

an MVG Applet where addresses can be related, and the new button (if available) spawns the association applet which allows for the creation of a new address record that also gets related to the account upon creation.

Development Effort per Use Case and Relationship to Siebel Objects—This list of use cases can imply one or many views and/or applets; considering the Siebel architecture, one can infer the business, data layer, and even integration components. For example, naming entities such as “Accounts” or “Account’s Opportunity” also imply the use of certain views, objects, and tables in Siebel – these objects can also be called out in an additional column. Knowing this, designers and developers can easily provide high-medium, and low effort estimates to use cases. Similarly, it is easy to identify objects that are being used, conflicting, or overlapping be their association with multiple use cases. Care should be taken because situations often arise where an applet’s visible functionality (within a use case) is different under a different context of use (another use case) and the Siebel GUI reuses many objects – the design should appropriately call out whether the object might need to be copied (for a different search spec) or where another aspect of the architecture is used (personalization).

7.3 Filling Out the Use Case TemplateHopefully, this clarifies the importance of the “outline” captured in the Actor-Goal List. Basically, the key next step is filling out the use cases. Some iteration should be involved in the templates and the organization of them until there is a balance of consistency regarding the hierarchy, homogenaiety, and organization. The table below should be filled out with actual use case content, below the have both instructions and examples.

Event Interview GuideID This should be unique and not numbered if possible. Numbering makes

reording and hierarchical changes difficult.Name: -The name should be a short Verb-Noun Phrase that matches the Actor-

Goal ListActor: -This should list all the actors, it the Actor-Goal list is kep current and

sufficient than this does not need to be duplicated. A database would work effectively here.


21

-Actors (roles) can be employees, positions, responsibilities,or organizations, and the design has to be considered because of things like state-model or script that are accomplished at a field, not view, level. For example, state model can be public or based on an individual and business component script could look to perform a function “if” a certain view is the current view in context.-Keep in mind that the actor (role) actually represents things a user is supposed to be accountable for. While it is likely that Salespeople all have the access to the same functions, actual sales users in a division could need different functionality and it is important to understand when different functionality is requried based on the user—Can all users query, create, edit, or delete or is it constrained by who they are individually, where they are in the management chain, what division they are in, or what functionality they need within a division?-What is the name of this system? Is this time?

Level: -Could include the levels Cloud, Kite, Sea, Fish, Clam – should explain the level of goals and help define a hierarchy of goals as they match process.- Siebel uses the following to define processes: Functional Domain, Process Domain, Sub-Domain, Business Process, Sub Process, Step-Typically, the analyst should understand the structure of these and negotiate them on behalf of the customer and user. Clarifications should be made in general terms.-Other feedback mechanisms like card-sorting work well here if critical.-Do users conceptually group these functions together? Do users do this in a very surgical manner (updating one field) or consider the task a broad brushstroke (create an entire account hierarchy)?

Goal: -(Example) To have a new Customer Account record reflect a valid and complete description of a Customer Account-What is the user ultimately trying to accomplish before they move on to the next thing?-Who does this goal serve and why?-Is it clear which part of the goal the system is to support versus goals that are outside this system (example is speaking with the customer may or may not be captured in the system as an opportunity’s activity)?

Scenario Briefs/Examples:

-Can be used to offer “day in the life narratives,” short descriptions of full scenarios, or context of business process activities.-What business process is referenced here? Are there any gaps or issues associated with the process and this use case (the system)?

Pre-conditions: -(Example) User logged into the system and has access to the appropriate view-The system enforces that this is true before letting the use case start.-What does the system enforce before the use case can start?-Besides being logged in and having access to the view, does the actor need a network connection? Does a record have to be valid or of a certain status? Does an entity relationship have to exist?

Trigger: -Specifies the event that gets the use case started. This can be the first step or preced the first step, but consistency is good.-What button or tab did the user touch to begin this? What record was upserted to the database? What request did another system make? What was the time rule for this being invoked?

Full Scenario: The full scenario should call out navigation to different views and the actions a user takes while on that view. Navigation and querying can be re-used as modular use cases and only unusual navigation would be called out separately. Performing common actions (add, edit, delete) on records or entities should be explained here because these actions often


22

have rules that can be called out, field-by-field, in an appending table for things like required, user-key, validation, etc.1) What did the user do? (click a tab or button)2) What did the system do? (show a view, update a record, pop a

message)3) What did the user do?4) What did the system do?5) Etc., Etc., Etc.

Data Usage and Stakeholder

Interests (Minimal, Guarantees, Validations, Successful

Ending):

-Optional. Minimal guarantees ensure some aspect of stakeholder interests is met even though the case failed. This is typically a business guarantee like all necessary fields were not filled out, but the record is still captured as incomplete and invalid. Is there anything that the system should absolutely guarantee if this user’s actions don’t complete?- Optional. Successful Ending ensures some aspect of stakeholder interests is met when the case succeeded. This is typically a business guarantee like something will be shipped. What should the system absolutely guarantee when this user’s actions complete?-Validations and other field level requriements can be captured in a separate table. This use case’s action potentially does something to a record – it should capture the fields that are acted upon. What fields are impacted? What needs to be validated by the system? What needs to be in place for a record to reach a certain state?

Data Conversion: -Notes about data conversion-If we import records, what data is missing, duplicated, inconsistent, invalid, incorrect, false, etc. that can impact this use case from completing successfully? What needs to be done to the data to ensure that, after conversion, this use case can be performed on imported data?

Assumptions: -What is assumed about the actors, functionality, objects, data, integration, conversion, etc. What do we need to capture to help protect us or the client from unknowns?

Issues/Concerns/ Risks/Questions:

-This could be kept in a separate table with actions, owners, and dates. All elements should be completed and closed before the use case can be signed off as a complete requirement.-What issues or concerns exist that should go in front of some review board or governance body? What risks could cause this project to fail? What remaining questions have we been unable to answer but need to be answered for this use case to be completed?

Interdependencies: -What elements of the application are interdependent or overlapping with this use case and will need to be resolved at some point in the project?

7.4 Appending Use Cases with Additional InformationThe analyst must also decide how much requirements detail they have time and should get into during a phase of requirements capture – eventually, the detail begins to get into design. Keep in mind that the fact that this is a packaged application means that use cases (done as described) already imply GUI design and more!!! Additional detail will eventually need to be captured regarding the GUI elements of navigation, views, applets, applet menus, fields, and buttons – this can be done during requirements or during design – but eventually it is covered even if teams wait until UAT. These GUI elements (nouns) typically are associated with users actions (verbs) and can be presented 1) in their own use case 2) called out in a separate table below a use case or 3) in a corresponding design document. The author recommends that as much of the following “Appending” items be captured by the completion of requirements as long as incorrect design is not forced upon the design team or there is opportunity to update the requirements and use


23

cases to reflect a better design (a typical occurance). The additional detail captured may lengthen the requirements phase, but will reduce risk and improve efficiency (save money and time) throughout the rest of the project.

7.4.1 Appending Use Cases with Additional ActionsThe table below is a fairly comprehensive set of user-actions that correspond to Siebel GUI frameworks (usually applets) and should be appended to a use case (when it corresponds to applets appropriately). For example, the use case “Delete Account” may not need to be called out separately unless a limited set of users can do it or a situation where a custom “logical delete” (not physical delete) is created.

Common Actions: These should be captured within the Full Scenario in the use case template above.

Alternative Actions (similar to Common Actions): o Changing Records is typically inherent to an applet and is either available or not

– it is basically a mass-edit.o Disassociation is a “Delete” from a Siebel user’s perspective, but the requirement

should cover a “deep delete” to avoid orphaning records if appropriate.o Relating/Association is very common and could probably belong in the common

category. It should be called out in a use case on it’s own and the traditional Siebel term for it is “pick” though an “association” applet creates and relates as covered above.

Navigational and Administrative Actions: These are typical of each applet menu or specialized OOTB C++ class-based buttons. Typically, these are left on or removed from an applet and can be called out in a separate table rather than their own use case. If a specialied OOTB button is unfamiliar, complicated, or new to users (like Revise), it might be described in a use case as well.

Custom Buttons: These can do a number of things – they could simply navigate to another view, call a business service for validation, or start an integration. It is likely that these buttons may require their own use case like in the case of generating an activity for a certain account team member based on hitting “Approve Opportunity” in the opportunities list View.

If it is custom functionality, it is definitely worthwhile to detail these actions in their own use case.

The previously discussed actions are highlighted in yellow:Common Actions Alternative Actions Navigational Actions Administrative ActionsNew/Create Navigate Columns DisplayedEdit Change Records New Query ImportSave Run Query ExportCopy Refine Query Example: Reload

PersonalizationUndo Save Query As Example: Next DayDelete Disassociate First Record Etc...Select Last RecordPick Associate Scroll

Advanced SortSelect AllInvert SelectionMore/LessTab (Controls)

Custom Buttons Custom Buttons Custom Buttons Custom Buttons


24

7.4.2 Appending Use Cases with Additional Field-Level InformationUse Cases’ nouns are the main entities involved with the action. SVFs, MVGs, and other Control/Field level requirements often exist and have rules. A table should be appended to each use case for the appropriate applets contained within the use case (items in the table can call out other use cases). This will allow clear trace-ability from requirements to design and actually make design meaningful to stakeholders, managers, developers, and non-technical teams such as trainers and help-desk.

Regardless of whether field-level rules are captured during requirements or design, they will need to capture information about the following (which will all need to be designed and developed):

Entity relationships Validation Editing State Need for separate use case Foreign keys State model Script Assignment manager Workflow pPrsonalization LOVs Required Defaults Inherited OOTB Formatting Size/legnth Type Uniqueness/user-keys Join/mvl System generated Displayed Calculated Audited.

Except for entity relationships (which is recommended to call out in the actor-goal list and use case template), use a table similar to the one below to capture field-level information and even speak to reusability of fields. These can be generic or specific to appets, but it should be clear whether or not certain applets are intended becuase of the re-use of applets versus fields and where customization should take place. Controls column below correspond to the examples above.

ID Control Field Table.Column Comments01 Entity

RelationshipSystem forces user to associate an entity.

02 Validation Record must have a value for record to reach a certain status.

03 Editing Field is read-only.04 State Transitions apply, see details below.05 Separate Use

CaseCertain value startes integration, see Integration Use Case XYZ.

06 Assigment Field used by assigment manager, see Assignment Use Cases.

07 Workflow Field used by workflow, see workflow


25

Use Cases.08 Personalization Field matches profile of user to records

showing in results.09 LOVs Field does not show up on query form

applet.10 Required Field is required to create record or is

required for a certain status.11 Defaulted/

InheritedField has a pre-defaulted value or value inherited from a parent.

12 OOTB May call out to leave alone or remove.13 Formatting Field must include an @ sign.14 Size/Length Field limited to 5 characters.15 Type Field must be of type currency.16 Uniqueness/

User-KeysField part of user key.

17 Join/MVL Part of join or MVL to entity XYZ.18 System

GeneratedSystem calculates future date.

19 Displayed Field not displayed on query applet is used to limit query results.

20 Calculated System performs calculation on field.21 Audited Audit trail performs on field.

7.4.3 Appending Use Cases with GUI DesignSimilarly to the actions and fields above, GUI Design (and Protyping) can be appended to the use cases for further definition of system use. Pseudo-GUI (Mock-GUI), screen shots with call-outs, or actual prototypes can be called out for corresponding use cases (containing the views and/or applets).

Use GUI particularly in situations where: Usability and efficiency of use is critical. The GUI design can be a requirement!!! An

example of this is a call center that needs to bring up several applets about a customer into one “portal” view without having to navigate around to see data.

Ease of data entry or order of data entry is critical. A smartscript drives efficient user input without much attention to complicated navigation – the order of data capture may be a requirement.

Non-employee users are involved. These users often do not receive training, so the ability to easily navigate is critical.

Where views or applets are completely customized or GUI controls and web template items are drastically changed.

Pseudo-GUI Design Example:


26

Example of Screen Shots with Call-Outs:


27

1

2

7.4.4 Turning Use Cases into DesignIf the Actor-Goal list acts as a table of contents, all appropriate use cases are completed, and all appropriate appending actions, field-level rules, and GUI design are completed, then this “requirements content” is more than adequate for completing all applicable object definitions for GUI, business, data, adminstrative definitions, and integrations which are typically captured in tables for the design stage deliverables. Designs also point out the workflow or sequence of key data-related events and provide more definition for tables and script for highly customized areas (custom-development oriented areas).

The level of requirements information defined here will also free up designers to: Spend more time defining a coordinated, low risk, and well-architected design Spend more time working and less time in meetings and communications Reduce time spent bantering over what the requirement means or what the system

should do Spend less time developing and re-developing changes Spend less time fixing bugs and defects


28

8 Examples of Use Cases fit within the Project LifecycleThe following examples were used on a project and the estimates were made during the requirements phase. The estimations were accurate to the day without over-working staff. As well, the estimation models can be adapted for use within SOWs or ePlans as mentioned previously in this document.

8.1 Example of Use Case Based Estimating Model Use Cases are Grouped with their associated Use Cases (from a user perspective) Associated Staff Days of Effort can be analyzed, objects can be associated, and design/develop function types of effort can be associated Other estimation techniques, automation, and association to business units, processes or metrics can also be applied and measured

throughout the project (see notes column for examples).

Staff Heavy

Use Case Days Config

& Heavy Work State Group Use Case ID Effort View/Applet for Use Case Config Scripts Scripts flow Model NotesMng CA Create CA 2 Account List View 1 Process XYZMng CA Query CA 0.5 "" 1 Mng CA Edit CA 2 "" 1 Mng CA Delete CA 0.5 "" 1 Phase TBD

Mng CA Create CA Notes 0.5 Account Note View 1 Resources/time assigned

Mng CA Edit CA Notes 0.5 "" 1

Mng CA Create CA Addr 3Account List View/Pop-Up Applets 1

# Correct Addresses Sent Downstream improves

Mng CA Edit CA Addr 2 "" 1

Mng CA Create CA FP 2Com Account Financial Profile View 1 Service Org

Mng CA Edit CA FP 2 "" 1 Service OrgMng CA Create FP-A 1 "" 1 Service Org

Mng CA View Hierarchy 1Com Account Hierarchy Analysis View 1

Mng CA Create CA Affiliation 1 Custom Affiliation 1 1 Mng CA Edit CA Affiliation 0.5 "" 1 Mng CA Delete CA Affiliation 0.5 "" 1

8.2 Example of Repository-Project Association The Views here are associated to “child” object definitions and projects All object definitions can be linked to use cases (via views or applets) and this can help identify areas of interdependency for planning

View Applet Project Applet BC Project BC Relation Table Project TableAccount List View Com Account

SIS Account List Applet Account Account N/A Newtable S_ORG_EXT

Account List View Com Account

SIS Account Entry Applet Account Account N/A Newtable S_ORG_EXT

Account List View Mvg

Account Address Mvg Applet CUT Address CUT Address Join and Link Newtable S_ADDR_PER

Account List View CUT Address

Com Address Assoc Applet BASE CUT Address CUT Address Join and Link Newtable S_ADDR_PER

Account List View CUT Address

Com Address Assoc Applet EDIT CUT Address CUT Address Join and Link Newtable S_ADDR_PER

Com Account Financial Profile View Com Account

SIS Account Entry Applet Account Account N/A Newtable S_ORG_EXT


31

8.3 Example of Estimation, Work Packages, and Status Use Cases can be grouped into work packages with total estimation for a group of architecturally interdependendent use cases Use Cases are grouped to be completed in a certain order (when one set of functionality must exist before another can be built or tested) The status of work packages for design, development, and varios testing can also be kept

Status EstimationNot

StartedIn

ProgressPending Review Complete

Check Sum

WorkPackage Effort Use Case ID

StaffDays View Project View

1 1 Create CA 2 Account (SSE)Account List View

1 1 Query CA 0.5 Account (SSE)Account List View

1 1 Edit CA 2 Com AccountCom Sub Account View

1 1 Delete CA 0.5 Com AccountCom Sub Account View

1 1 Create CA SA 3 Com AccountCom Sub Account View

1 1 Query SA 0.5 1 1 Edit SA 1 1 1 Delete SA 0.5

1 1 Create CA-PBA 2 1 1 Create BA-BA 2

1 1 Query BA 0.5 1 1 Edit BA 0.5 1 1 Delete BA 0.5

Accounts 15.5

1 1 Validate Customer Account 11 1 Validate Service Account 0.5

1 1Validate Accounts 2 Validate Billing Account 0.5


32

8.4 Examples of Appending Test Data to Use Cases The following tables provide examples of additional test information that could be included with a group or individual use cases These tables can be added during requriements, or later on during test planning and preparation phases The tables outline what data must exist to be prepare for a test and what data should be used to test functionality The tests can be applied to unit testing, system testing, integration testing, data-conversion testing, performance testing, and user

acceptance testing

8.4.1 Test Case Preparation Example All views must be compiled and responsibilities set appropriately Account Status will need to be completely editable to perform the following test cases Data to be used for Create, Query, Edit, and Delete:

# Field/Label Test Data:1 Row Status (New) System set2 Name (Account Name) Use “%Initials% DevTest %###%” like “AB DevTest 001”3 Location (Site (Branch)) Leave Null4 Alias (Short Name) Use “%Initials%001” like “AB001”

8.4.2 Test Cases Example AID Excepti

on/Sub Step/Condition Expected Results Screen

ShotP/F

001

When user enters application “Accounts” Screen Tab is available

P

002

When user selects “Accounts” Screen Tab, the Account List View shows.

P

003

My Accounts, My Team’s Accounts, and All Accounts List View should be available to appropriate users.

P

004

Sub Accounts, Hierarchy, Affiliation Notes, Financial Profile, Site Profile, and Billing Profile Views should be available under the Accounts Screen

P

019

2 The table below defines how a field is editable at different stages

F


33

020

3 See Validation Use Case, validation must fire with Valid Flag and Comments being set by the system.

P

8.4.3 Tests Cases Example BCorresponding Field Design Tests For Edit Use Case – Read Only/Un-editable fields

# Field/Label R/O @ Pending Active & Active

ID—P/F R/O @ Closed ID—P/F

1 Row Status (New) 021—P 057—P2 Name (Account Name) X 022—P X 058—P3 Location (Site (Branch)) X 023—P X 059—P4 Alias (Short Name) X 024—P X 060—P


34

8.5 Example of Creating Training and Help From Use Cases The training below directly corresponds to the Use Case Templates Content is almost identical (or easily derived) and the order has been mildly modified This information can also be saved as HTML help files within the appliction

Creating an Account Record

Introduction As a central object for managing customer relationships, an account record must be created for each prospective or customer account before other supporting information can be entered about the account. When the account record is created, the agent can begin to add and track important details such as contacts, opportunities, and service requests.

Sample Image

Accounts Screen


35

Steps Step Action

1 Navigate to the Accounts screen.2 Click the Show drop-down arrow and select My Accounts.3 Click in the Accounts list.4 Complete the following required fields:

Note: Click to expand the form and view all available account fields.

Field DescriptionName Type the business name of the customer account

using title case, for example, Fred Smith Pty Ltd.Site If an account has multiple locations, the Site field

can be used to determine a more specific location.Main Phone # Type the account’s central phone number,

including the area code, with no spaces. The phone number is automatically formatted in (AAA) NNN NNNN format.

Main Fax # Type the account’s main fax number, including the area code, with no spaces. The phone number is automatically formatted in (AAA) NNN NNNN format.

Current Volume Click and use , and to select Currency Code, Exchange Date and Amount for the current volume of business with this account.

Potential Volume Click and use , and to select Currency Code, Exchange Date and Amount for the potential volume of business with this account.

URL Type the full Web address of any Web site maintained by the account; for example, www.geoffreysteel.com.

Region Type the name of the region, for example, Midwest.


36

Account Type Select the account type that best describes the relationship between the account and company, for example, Prospect, Consultant.

Stage Click to select the stage of the account, for example, Rollout.

Expertise Click to select the expertise of the account, for example, Technology.

Partner Click to indicate this account is a partner.Competitor Click to indicate this account is a competitor.Reference Click to indicate this account can be used as a

reference.


37

9 ConclusionThis paper’s purpose was to answer the question “Why should you use ‘Use Cases’ on your Siebel Implementation?” Decisions surrounding the value and cost happen on the front end of a project. By the requirements phase completion, these decisions have very large impacts to all downstream project efforts – by requirements the large majority of top-line and bottom line financials have been determined for a project. Use Cases are a very appropriate approach to managing software requirements. If managed using the templates, examples, and recommendations made here, a project’s ability to deliver value to it’s stakeholders will increase and the project teams efficiency and effectiveness will improve.

use case white paper - customer dialogues · web viewrevision history date revision author reviewer...

Documents