Wednesday Nov 21, 2012

When should I use a Process Model versus a Use Case?

This Blog entry is a follow on to and addresses a question I sometimes get asked…..i.e. “when I am gathering requirements on a Project, should I use a Process Modeling approach, or should I use a Use Case approach?”

Not surprisingly, the short answer is “it depends”!

Let’s take a scenario where you are working on a Sales Force Automation project. We’ll call the process that is being implemented “Lead-to-Order”.

I would typically think of this type of project as being “Process Centric”. In other words, the focus will be on orchestrating a series of human and system related tasks that ultimately deliver value to the business in a cost effective way. Put in even simpler terms……implement an automated pre-sales system.

For this type of (Process Centric) project, requirements would typically be gathered through a series of Workshops where the focal point will be on creating, or confirming, the Future-State (To-Be) business process. If pre-defined “best-practice” business process models exist, then of course they could and should be used during the Workshops, but even in their absence, the focus of the Workshops will be to define the optimum series of Tasks, their connections, sequence, and dependencies that will ultimately reflect a business process that meets the needs of the business.

Now let’s take another scenario. Assume you are working on a Content Management project that involves automating the creation and management of content for User Manuals, Web Sites, Social Media publications etc. Would you call this type of project “Process Centric”?.......well you could, but it might also fall into the category of complex configuration, plus some custom extensions to a standard software application (COTS).

For this type of project it would certainly be worth considering using a Use Case approach in order to 1) understand the requirements, and 2) to capture the functional requirements of the custom extensions.

At this point you might be asking “why couldn't I use a Process Modeling approach for my Content Management project?” Well, of course you could, but you just need to think about which approach is the most effective. Start by analyzing the types of Tasks that will eventually be automated by the system, for example:


Best Suited To?


Task Name


Process Model


Use Case




Manage outbound calls





A series of linked human and system tasks for calling and following up with prospects

Manage content revision




Updating the content on a website

Update User Preferences




Updating a users display preferences

Assign Lead




Reviewing a lead, then assigning it to a sales person

Convert Lead to Quote




Updating the status of a lead, and then converting it to a sales order


As you can see, it’s not an exact science, and either approach is viable for the Tasks listed above.

However, where you have a series of interconnected Tasks or Activities, than when combined, deliver value to the business, then that would be a good indicator to lead with a Process Modeling approach. Another good indicator, is when the majority of the Tasks or Activities are available from within the standard COTS application.

On the other hand, when the Tasks or Activities in question are more isolated, tend not to cross traditional departmental boundaries, or involve very complex configuration or custom development work, then a Use Case approach should be considered

Now let’s take one final scenario…..

As you captured the To-Be Process flows for the Sales Force automation project, you discover a “Gap” in terms of what the client requires, and what the standard COTS application can provide. Let’s assume that the only way forward is to develop a Custom Extension. This would now be a perfect opportunity to document the functional requirements (behind the Gap) using a Use Case approach. After all, we will be developing some new software, and one of the most effective ways to begin the Software Development Lifecycle is to follow a Use Case approach.

As always, your comments are most welcome.




Tuesday Sep 25, 2012

Iterative and Incremental Principle Series 2: Finding Focus

Welcome back to the second blog in a five part series where I recount my personal experience with applying the Iterative and Incremental principle to my daily life.  As you recall from part one of the series, a conversation with my son prompted me to think about practical applications of the Iterative and Incremental approach and I realized I had incorporated this principle in my exercise regime.   

I have been a runner since college but about a year ago, I sustained an injury that prevented me from exercising.  When I was sufficiently healed, I decided to pick it up again.  Knowing it was unrealistic to pick up where I left off, I set a goal of running 3 miles or approximately for 30 minutes.    I was excited to get back into running and determined to meet my goal.  Unfortunately, after what felt like a lifetime, I looked at my watch and realized that I had 27 agonizing minutes to go!  My determination waned and my positive “I can do it” attitude was overridden by thoughts of “This is impossible”.   My initial focus and excitement was not sustained so I never met my goal.  

Understanding that the 30 minute run was simply too much for me mentally, I changed my approach.   I decided to try interval training.  For each interval, I planned to walk for 3 minutes, then jog for 2 minutes, and finally sprint for 1 minute, and I planned to repeat this pattern 5 times.  I found that each interval set was challenging, yet achievable, leaving me excited and invigorated for my next interval.  I easily completed five intervals – or 30 minutes!!  My sense of accomplishment soared.

What does this have to do with OUM?  Have you heard the saying -- “How do you eat an elephant?  One bite at a time!”?  This adage certainly applies in my example and in an OUM systems implementation.  It is easier to manage, track progress and maintain team focus for weeks at a time, rather than for months at a time.   With shorter milestones, the project team focuses on the iteration goal.  Once the iteration goal is met, a sense of accomplishment is experience and the team can be re-focused on a fresh, yet achievable new challenge. 

Join me tomorrow as I expand the concept of Iterative and incremental by taking a step back to explore the recommended approach for planning your iterations.

Monday Aug 13, 2012

A Use Case for the Olympic 100m Final


Unless you have been hiding away on a desert island, you would probably have seen Usain Bolt win the 100m Gold Medal at the London 2012 Olympics!

It would clearly be “absurd” to write a Use Case for such an event, but nevertheless, it serves as a good memory jogger for the various components of a Use Case.

Let’s set the scene by having a quick recap, along with a very brief (summarized) description of the major components of a fully dressed1 Use Case:

Use Case Name: 4 words or less, and conveys the goal of the Primary Actor

Primary Actor: The actor who has the primary reason for interacting with the business/system

Secondary Actor(s): actors who support the completion of the Use Case

Assumptions: what do we believe to be true, but may later prove to be untrue

Pre-Conditions: that which must be true before the use case can start

Trigger: event(s) that initiate/start the Use Case

Main Success Scenario: the ‘Happy Path’ to achieve the goal of the Primary Actor

Alternate Scenario: alternate paths that still achieve the goal of the Primary Actor

Exception Scenario: exception paths where the goal of the Primary Actor is not met

Let’s now overlay those terms onto our 100m Olympic Race

Use Case Component






Use Case Name:


Run 100m Race

4 words or less!

Primary Actor:




Secondary Actor(s):


Starting Official




The Primary Actor has no injuries

We can’t be 100% sure of this, and we certainly cannot test for it with absolute accuracy, therefore we make it an assumption




Primary Actor has passed the doping test, and has a valid qualifying time

We can verify these conditions before the Use Case starts, and in fact, we would not want the Use Case to start if any of these conditions could not be verified




Starting Official fires the starting pistol

This is somewhat controversial in the sense that one could argue that the trigger could be the Athlete ‘hearing’ the starting gun, or even the Athlete taking the first step out of the blocks. However for the purpose of this ‘memory jogger’ let’s just go with the fact that the Use Case cannot start until the starting pistol is fired!

Main Success Scenario:


 <!--[if !supportLists]-->· <!--[endif]-->The Use Case begins when the Primary Actors launches out of the blocks

<!--[if !supportLists]-->· <!--[endif]--> The ‘System’ responds by…………

<!--[if !supportLists]-->· <!--[endif]-->The Use Case ends when the Primary Actor crosses the finish line


Alternate Scenario


A false start occurs, resulting in a restart

The Athlete will still cross the finish line, therefore the ‘goal’ of the Use Case is still achieved

Exception Scenario:


The Primary Actor tears a muscle during the race and is not able to cross the finish line

One of our assumptions proves to be incorrect, and therefore the Use Case ‘goal’ cannot be met



We could extend this analogue even further by thinking of Post Conditions for each of the scenarios, but hopefully you get the idea!

Cleary this is a very basic example, and we don’t even touch upon timing devices, photo finish etc.

This is just a ‘Memory Jogger’ so don’t worry about whether this is a Business Use Case, or a System Use Case. We’ll leave that topic for another Blog entry!


1 Cockburn, A, 2000, Writing Effective Use Case, Addison-Wesley Professional; Edition 1




Thursday May 31, 2012

The Use-Case Driven Approach to Change Management

In the third entry of the series on OUM and PMI’s Pulse of the Profession, we took a look at the continued importance of change management and risk management. The topic of scope change management and OUM’s use-case driven approach has come up in few recent conversations. So I thought I would jot down a few thoughts on how the use-case driven approach aids a project team in managing the project’s scope.

Use-case models are one of several tools in OUM used to establish and manage the project's scope.  Because use-cases can be understood by both business and IT project team members, they can serve as a bridge for ongoing collaboration as well as a visual diagram that encapsulates all agreed-upon functionality. This makes them a vital artifact in identifying changes to the project’s scope.

Here are some of the primary benefits of using the use-case driven approach as part of the effort for establishing and managing project scope:

  • Use-cases quickly communicates scope in a straightforward manner. All project stakeholders can have a common foundation for the decisions regarding architecture and design and how they relate to the project's objectives.
  • Once agreed upon, a use-case can be put under change control and any updates to the model can then be quickly identified as potentially affecting the project’s scope.  Changes requested or discovered later in the project can be analyzed objectively for their impact on project's budget, resources and schedule.
  • A modular foundation for the design of the software solution can be established in Elaboration.  This permits work to be divided up effectively and executed in so that the most important and riskiest use-cases can be tackled early in the project.
  • Use-cases help the team make informed decisions about implementation priorities, which allows effective allocation of limited project resources.  This is very helpful in not only managing scope, but in doing iterative and incremental planning which relies heavily on the ability to identify project priorities.

Bottom line is that use-cases give the project team solid understanding of scope early in the project.  Combine this understanding with effective project management and communication and you have an effective tool for reducing the risk of overruns in budget and/or time due to out of control scope changes.

Now that you’ve had a chance to read these thoughts on the use-case driven approach and project scope, please let me know your feedback based on your experience.

Tuesday Mar 20, 2012

Use Case Actors - Primary versus Secondary

The Unified Modeling Language (UML1) defines an Actor (from UseCases) as:

An actor specifies a role played by a user or any other system that interacts with the subject.


In Alistair Cockburn’s book “Writing Effective Use Cases” (2) Actors are further defined as follows:

Primary Actor: The primary actor of a use case is the stakeholder that calls on the system to deliver one of its services. It has a goal with respect to the system – one that can be satisfied by its operation. The primary actor is often, but not always, the actor who triggers the use case.


Supporting Actors: A supporting actor in a use case in an external actor that provides a service to the system under design. It might be a high-speed printer, a web service, or humans that have to do some research and get back to us.


In a 2006 article (3) Cockburn refined the definitions slightly to read:

Primary Actors: The Actor(s) using the system to achieve a goal. The Use Case documents the interactions between the system and the actors to achieve the goal of the primary actor.


Secondary Actors: Actors that the system needs assistance from to achieve the primary actor’s goal.


Finally, the Oracle Unified Method (OUM) concurs with the UML definition of Actors, along with Cockburn’s refinement, but OUM also includes the following:

Secondary actors may or may not have goals that they expect to be satisfied by the use case, the primary actor always has a goal, and the use case exists to satisfy the primary actor.


Now that we are on the same “page”, let’s consider two examples:

  1. A bank loan officer wants to review a loan application from a customer, and part of the process involves a real-time credit rating check.
    • Use Case Name: Review Loan Application
    • Primary Actor: Loan Officer
    • Secondary Actors: Credit Rating System
  2. A Human Resources manager wants to change the job code of an employee, and as part of the process, automatically notify several other departments within the company of the change.
    • Use Case Name: Maintain Job Code
    • Primary Actor: Human Resources Manager
    • Secondary Actors: None


The first example is quite straight forward; we need to define the Secondary Actor because without the “Credit Rating System” we cannot successfully complete the Use Case. In other words, the goal of the Primary Actor is to successfully complete the Loan Application, but they need the explicit “help” of the Secondary Actor (Credit Rating System) to achieve this goal.

The second example is where people sometimes get confused. Within OUM we would not include the “other departments” as Secondary Actors and therefore not include them on the Use Case diagram for the following reasons:


  • The other departments are not required for the successful completion of the Use Case
  • We are not expecting any response from the other departments (at least within the bounds of the Use Case under discussion)

Having said that, within the detail of the Use Case Specification Main Success Scenario, we would include something like:

“The system sends a notification to the related department heads (ref. Business Rule BR101)”

Now let’s consider one final example.

A Procurement Manager wants to place a “bid” for some goods using an On-Line Trading Community (B2B version of eBay)

    • Use Case Name: Create Bid
    • Primary Actor: Procurement Manager
    • Secondary Actors: On-Line Trading Community

You might wonder why the Trading Community is listed as a Secondary Actor, i.e. if all we are going to do is place a bid for a specific quantity of goods at a given price and send that off to the Trading Community, then why would the Trading Community need to “assist” in that Use Case?

Well, once again, it comes back to the “User Experience” and how we want to optimize that when we think about our Use Case, and ultimately, when the developer comes to assembling some code.

In this final example, the Procurement Manager cannot successfully complete the “Create Bid” Use Case until they receive an affirmative confirmation back from the Trading Community that the Bid has been accepted. Therefore, the Trading Community must become a Secondary Actor and be referenced both on the Use Case diagram and Use Case Specification.

Any astute readers who are wondering about the “single sitting” rule will have to wait for a follow-up Blog entry to find out how that consideration can be factored in!!!

Happy Use Case writing!

(1) OMG Unified Modeling LanguageTM (OMG UML), Superstructure Version 2.4.1

(2) Cockburn, A, 2000, Writing Effective Use Case, Addison-Wesley Professional; Edition 1

(3) Cockburn, A, 2006 “Use Case fundamentals” viewed 20th March 2012,






Tuesday Mar 13, 2012

Use Case Assumptions versus Pre-Conditions

Within the Oracle Unified Method (OUM) we define the following in relation to Use Cases:


  • Assumptions: Facts we assume to be true, but may later prove to be untrue
  • Pre-Conditions: That which must be true before the Use Case can start


Seems pretty clear at this point! But in practice, when would it be appropriate to use an Assumption versus a Pre-Condition within a Use Case?

Let’s look at a hypothetical Use Case which represents the creation of an On-Line Sales Order (Internet shopping). For the sake of this example, we will name the Use Case – Create On-Line Sales Order

If a Business Analyst were writing such a Use Case, one question that might come up is…..”How should we deal with the possibility of the Credit Card Payment Gateway being unavailable during the on-line order creation process?”

One option would be to use a Use Case “Pre-Condition”. In other words, we will not let the Use Case “start” unless the Payment Gateway is actually available. This would force the software developer into creating some logic that checks the Payment Gateway Status prior to the user beginning the shopping process, and if the Gateway was “down” then the user would not be allowed to even begin the shopping process, i.e. a Pre-Condition allows us to define “what must be true before the Use Case can begin”.

Nothing wrong with that option you might think?

Well……another option would be to use a Use Case “Assumption”. In other words, we will assume that the Credit Card Payment Gateway is available, and allow the Use Case to “start” without actually verifying its availability. The implication for this, in terms of software development, is that the developer will not check the Payment Gateway status when the user begins the “shopping” process, and if at the point of checkout, the Gateway is in fact “down”, then we would describe how that should be handled through a Use Case Exception Scenario.

At this point we really need to step back from the semantics of the Use Case framework and think about how the business would prefer to handle this process, and specifically, what sort of user experience do they ideally want to provide to their on-line shoppers?

If you were the on-line shopper, you would be pretty un-happy if you had just spent 30 minutes choosing a range of items, including size/color/style, only to find that you could not checkout due to a problem with the Payment Gateway. You might not want to come back and shop there again!

So…..Pre-Condition sounds like the best option for this scenario?

Perhaps not……Let’s put the shopper experience at the forefront of our approach. If we apply this type of thinking, then another option would be to allow the customer to go through the product selection process, and at the point of selecting the checkout option, we would only then check the status of the Payment Gateway. If it was “up” then the customer would checkout as normal. It the Payment Gateway was not available, an option would be provided for the customer to either abort the checkout, or save their items in the shopping cart, and the business would notify them as soon as the Payment Gateway was available.

This latter option has many advantages, particularly in the area of analytics in terms of quantifying the number of customers who were not able to checkout due to a Payment Gateway issue, and the value of any lost business for those customer who do not return, even if they had previously saved items in their shopping cart.

Let’s now return to our Use Case. If we assume the business decides to take the latter option, should we use a Pre-Condition or an Assumption? The preferred option would be as follows:

  • Make the availability of the Payment Gateway a Use Case Assumption
  • Create an independent (<<include>>) Use Case called “Verify Payment Gateway Status” and reference this in the main success scenario of the “Create On-Line Sales Order” Use Case at the point the user selects the Checkout option.
  • If the Payment Gateway is available, then Use Case continues through the checkout process
  • If the Payment Gateway is unavailable, then the User is presented with an option to either:
    1. “abort shopping” whereby an Exception Scenario would describe the subsequent steps
    2. “save items, pay later” whereby an Alternate Scenario would describe the subsequent steps before returning to the main success scenario

In summary, on the face of things the difference between a Use Case Assumption and a Pre-Condition seems a little arbitrary. However these, along with other elements of a Use Case approach encourages an essential level of dialog between the Analyst and the Business; and it is this level of analytical rigor which makes a Use Case approach such a powerful approach to understanding complex requirements, and/or describing functional requirements prior to a potentially costly software development cycle.

In short.....time invested in the structured analysis of requirements, is more efficient that leaving the Software Developer to "fill in the blanks".

Monday Feb 20, 2012

What comes first…Gap Analysis or Use Case development?

What comes first…Gap Analysis or Use Case development?

It’s a good question and one we often get asked, but like most things in an imperfect World, the answer is “it depends!”

If we look at the OUM Method Pack and examine the dependencies for the Gap Analysis Tasks, then we see that one of the key pre-requisites are Use Case Specifications.

So that means we have to write a Use Case before doing any Gap Analysis…..right?.....well, it depends!!!

Consider the following two examples:

Let’s say you are implementing one of Oracle’s COTS applications, for example, eBS, Fusion or PeopleSoft etc. We might begin by capturing functional requirements by iteratively developing a Future Process Model. During that process you discover that the client has some requirements that cannot be met using the standard features of the application. If those requirements are reasonably well understood, then you would most likely drop into the OUM Gap Analysis “Process”. If the result of that process is a decision to go down a custom development path in order to close the “Gap” then one or more Use Cases could be created in order to fully describe the functional solution to the Gap.

Now consider this scenario. Your client is designing a solution that includes Single Sign-On, Business Intelligence and some components of Content Management. In this type of environment, it’s especially important to ask ourselves “what is the best way to capture functional requirements?” Why you may ask?............well, for projects that are process centric (e.g. Order-to-Cash, Procure-to-Pay) one would tend to favor the development of a Future Process model in order to define functional requirements. However, for projects that are not centered around traditional business processes, then we might want to consider leading with a Use Case approach in order to capture the client’s functional requirements.

In this second example, we probably won’t discover any Gaps until we go through the first iteration of Use Case development. But if we do uncover any Gaps, then our Use Cases will be an ideal direct input into the Gap Analysis process.

So what comes first Gap Analysis or Use Case Development?…..well just like the Chicken-and-Egg story, it all depends!!

Sunday Dec 04, 2011

Everything is URGENT – a look at Use Case prioritisation.

Everything is urgent. How many times have you heard that? The business needs this functionality to launch a new product, we have to have that piece of functionality to comply with new legislation, our current software licence is expiring. There are a myriad of factors influencing priority how do you deal with them in a way that recognises and mitigates for risk. Yes, risk. How often have you been tempted to put off dealing with difficult or risky functionality? How often has your decision to take the low hanging fruit turned sour?

In OUM we have an approach to prioritisation that is comprehensive and realistic, in other words fit for purpose.

Before you start the list of Use Cases should be reviewed and approved by the key stakeholders to ensure expectations are managed.

When that is done we can start evaluating use cases based on four perspectives.

  1. Customer priority - Importance of the use case to the business, and the urgency to have its functionality.
  2. Risk- you need to recognize risk early.  This needs to managed closely.
  3. Complexity – a measure of difficulty (requirements and development).  This also needs to managed closely.
  4. Dependencies – you need to know the connections. 

Now let us drill down a little on each one.

Customer Priority

Identify whether functionality is highest priority and is the focus of the system, or borders on being out-of-scope with a real potential to be postponed.

When it’s a challenge to get your customer to commit to prioritizing Use Cases, a 2 x 2 Urgency/Importance Matrix can be helpful.

This gives you a way of seeing what the Importance of the use case to the business, and the urgency to have the functionality available .Used in combination they help to determine priority.

The premise is that Importance is a measure of value to the business and Urgency is a measure of how quickly they need this functionality, so these can be used to differentiate priority.


Risk is a measure of uncertainty and for each Use Case you should identify the things that could occur and the impact to the project if it did

A Risk Portfolio Chart can be used to plot each Use Case profile based on its probability of occurrence and the degree of impact if the risk(s) occurs.

There are generally four categories of Risk. These four (4) categories should be used as a checklist by you to ensure all risks are identified.

Each risk that is forgotten or mismanaged may cause schedule slips, implementation problems, or worse.

It is important that people understand what gets elevated to management vs. what can be handled at project level - e.g., management risks often cannot be handled at the project level.

  • Technological risks are the risk that project result will not comply with performance, functional, inter-operability, or quality requirements
  • Project management risks are risks to cost or schedule.  What is the risk that the project cost will exceed the budget or schedule
  • Organizational risks  are attributed to organizational changes at the client site
  • External risks are those risks imposed by external factors such as Labour unions or trading community partner organizations

·         Sometimes it is useful to graphically plot the Use Cases on a Risk Portfolio Chart. Each use case is assessed and then plotted on a risk profile chart to show the probability that the risk(s) will occur and the degree of impact if it does.

The higher the probability and the impact, the more emphasis a project manager should place on that Use Case to ensure the proper mitigation strategy is applied to eliminate or reduce the risks.


You need to assess whether functionality contains simplistic input and output algorithms or intricate critical methods. Typical complexity factors to consider are:

  • Number of Actor Profiles
  • Number of proposed scenarios
  • Kind of System
    • Simplicity of the User System
    • Real-time System
    • Embedded System

·        Dependencies

It is common for one Use Case to “depend upon’ one or more other Use Cases and/or external interfaces. Often the pre- and post- conditions of a Use Case will hint at these dependencies.

Dependencies between Use Cases and/or external interfaces often will drive the sequence regarding how the Use Cases will need to be written and/or implemented.


These perspectives provide input into the planning process. Use cases do not have to be prioritized this way, there could be other factors.

For example once you know the business delivery priorities, you can then plan the development priorities.

However one best practice is to address the highest risk early in the project.  This minimizes the possibility of working on the least important things first, and then not having time. When the more complex or architecturally significant use cases are considered too late in the project lifecycle, you are at risk of missing requirements, which will severely impact the usefulness of the system to the end users.

So, everything is urgent. Correct??

Tuesday Nov 08, 2011

OUM is Business Process and Use Case-Driven

Business Process and Use Case-Driven

Business processes and use cases are used as the primary artifacts for establishing the desired behavior of the system and for communicating this behavior among the stakeholders.

OUM projects are able to document requirements through business process models, through use cases, and through written supplemental and quality of service requirements. OUM guidance helps implementers to understand where each technique is appropriate and how they fit togehter

Business processes modeling helps stakeholders and implementers to understand the business processes of an organization, and look at the business requirements that are satisfied by a particular business process. To complement business process models, use cases models and use cases may be used to:

  • Provide a consistent mechanism to link system requirements to design and test tasks
  • Bridge the gap between business modeling, business processes, and software system functionality
  • Provide a consistent thread through OUM – use cases help amplify and consolidate the many other benefits of the method
  • Identify implicit or unstated requirements
  • Manage traceability of requirements through testing

Often business process models for predefined solutions exist and contain some form or description of how the user interacts with the system or how a system interacts with another system. Where these business process models already exist, they should be reviewed as a means of gathering business requirements. The need for additional use case modeling would depend on how well the business process models have captured the requirements of the business. Use cases become particularly important where there is a significant gap between the functionality required by the business and the functionality provided by the predefined solution or software product that is being employed. OUM proposes that implementers develop only the set of models and artifacts required to understand and document requirements and trace those requirements through the implementation lifecycle.

As the project progresses and where the need to develop use cases arises, the use cases are analyzed and the system is designed and implemented to meet the requirements captured in the use cases. The implemented components are tested to verify that they provide the business benefit described by the use cases. All of the models (Use Case Model, Analysis Model, Design Model, Architectural Implementation, and Performance Test Transaction Models) are related to each other through trace dependencies. Use cases are prioritized to:

  • Define the architecture before committing too much resource
  • First deliver the components with the highest value to the customer

Monday Oct 31, 2011

Tell us your best tip for writing a use case?

Do you have a favorite tip for writing a use case that you would like to share with us?  Here are some of our tips:


  • Use a two-column format.
  • Use structured sentences.
  • Use active verb phrases.
  • Write in the present tense.
  • Avoid compound sentences.
  • Describe the steps by starting every action with "The actor..." or "The system..."
  • Number the steps…but not until you’re done.
  • Each step should contain one testable, traceable requirement.
Please feel free to write your best tip in the discussion area below


Friday Sep 02, 2011

It's all down in Black and White.


In the BI/EPM View of Oracle Unified Method we introduced the idea of Black and White box Use Cases.

Black-Box Use Case Black-box use cases capture requirements at the level of observable behavior, but do not reveal the internal workings of the business or system. Most use cases are written at the black-box level to maintain the separation between requirements and design. Within this view, black-box use cases are most applicable to development of a custom BI system, but would also apply to the implementation of BI and EPM product-based systems that require custom extensions that support new data entry or reporting requirements.

White-Box Use Case White-box use cases capture requirements that reveal the internal workings of a business or system. White-box use cases detail how the system will satisfy the requirements. White-box use cases are applicable on projects that will implement BI and EPM product-based systems to document requirements regarding changes in the way the product needs to work.

Black-Box versus White-Box

It is important to understand how black-box and white-box use cases are applied to support BI and EPM projects.

Black-box use cases are typically used to capture requirements related to the development of new data entry, display, and reporting mechanisms. This includes new custom data entry and report components or data entry and reporting extensions being made to a BI or EPM product.

White box use cases are used to capture requirements related to the development or customization of internal data extraction, transformation, and loading components. These requirements typically result in the configuration or customization of existing EPM or BI Apps products. When using white-box use cases, remember to keep the use cases at the level of requirements and not to delve into system design.

All clear now?


Tony Carpenter


OUM Logo
The Oracle® Unified Method (OUM) is Oracle’s standards-based method that enables the entire Enterprise Information Technology (IT) lifecycle.


· Brief

· White Paper

· Customer Program Data Sheet


· OUM on Twitter

· OUM on LinkedIn


« June 2016