Wednesday Dec 05, 2012

Finding "Stuff" In OUM

 

One of the first questions people asked when they start using the Oracle Unified Method (OUM) is “how do I find X ?”

Well of course no one is really looking for “X”!! but typically an OUM user might know the Task ID, or part of the Task Name, or maybe they just want to find out if there is any content within OUM that is related to a couple of keys words they have in their mind.

Here are three quick tips I give people:

1. Open up one of the OUM Views, then click “Expand All”, and then use your Browser’s search function to locate a key Word.

For example, Google Chrome or Internet Explorer: <CTRL> F, then type in a key Word, i.e. Architecture

This is fast and easy option to use, but it only searches the current OUM page

2. Use the PDF view of OUM

Open up one of the OUM Views, and then click the PDF View button located at the top of the View. Depending on your Browser’s settings, the PDF file will either open up in a new Window, or be saved to your local machine. In either case, once the PDF file is open, you can use the built in PDF search commands to search for key words across a large portion of the OUM Method Pack.

This is great option for searching the entire Full Method View of OUM, including linked HTML pages, however the search will not included linked Documents, i.e. Word, Excel.

3.  <!--[endif]-->Use your operating systems file index to search for key words

This is my favorite option, and one I use virtually every day. I happen to use Windows Search, but you could also use Google Desktop Search, of Finder on a MAC.

All you need to do (on a Windows machine) is to make sure your local OUM folder structure is included in the Windows Index. Go to Control Panel, select Indexing Options, and ensure your OUM folder is included in the Index, i.e. C:/METHOD/OM40/OUM_5.6

Once your OUM folders are indexed, just open up Windows Search (or Google Desktop Search) and type in your key worlds, i.e. Unit Testing

The reason I use this option the most is because the Search will take place across the entire content of the Indexed folders, included linked files.

Happy searching!

 

 

 

 

 

Wednesday Nov 21, 2012

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

This Blog entry is a follow on to https://blogs.oracle.com/oum/entry/oum_is_business_process_and 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

 

Notes

 

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.

 

 

 

Friday Oct 12, 2012

Iterative Project Planning - Let's Talk

I recently had an interesting conversation with a Project Manager regarding the shift from a "Waterfall" approach, to an Iterative approach to managing projects. Click on the following link to see an animated version of that conversation!

https://www.youtube.com/watch?v=ZMOCO_wS96k

 

Wednesday Oct 03, 2012

Where's my MD.070?

In a previous Blog entry titled “Where’s My MD.050” I discussed how the OUM Analysis Specification is the “new-and-improved” version of the more traditional Functional Design Document (or MD.050 for Oracle AIM stalwarts).

In a similar way, the OUM Design Specification is an evolution of what we used to call the Technical Design Document (or MD.070).

Let’s dig a little deeper……

In a traditional software development process, the “Design Task” would include all the time and resources required to design the software component(s), AND to create the final Technical Design Document.

However, in OUM, we have created distinct Tasks for pure design work, along with an optional Task for pulling all of that work together into a Design Specification.


 

Some of the Design Tasks shown above will result in their own Work Products (i.e. an Architecture Description), whilst other Tasks would act as “placeholders” for a specific work effort.

In any event, the DS.140 Design Specification can include a combination of unique content, along with links to other Work Products, together which enable a complete technical description of the component, or solution, being designed.

So next time someone asks “where’s my MD.070” the short answer would be to tell them to read the OUM Task description for DS.140 – Design Specification!

 

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

 

Content

 

Comments

 

Use Case Name:

 

Run 100m Race

4 words or less!

Primary Actor:

 

Athlete

 

Secondary Actor(s):

 

Starting Official

 

Assumptions:

 

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

 

Pre-Conditions:

 

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

 

Trigger:

 

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

 

 

 

Tuesday Jun 26, 2012

Where’s my MD.050?

A question that I’m sometimes asked is “where’s my MD.050 in OUM?” For those not familiar with an MD.050, it serves the purpose of being a Functional Design Document (FDD) in one of Oracle’s legacy Methods.

Functional Design Documents have existed for many years with their primary purpose being to describe the functional aspects of one or more components of an IT system, typically, a Custom Extension of some sort.

So why don’t we have a direct replacement for the MD.050/FDD in OUM? In simple terms, the disadvantage of the MD.050/FDD approach is that it tends to lead practitioners into “Design mode” too early in the process. Whereas OUM encourages more emphasis on gathering, and describing the functional requirements of a system ahead of the formal Analysis and Design process.

So that just means more work up front for the Business Analyst or Functional Consultants right?

Well no…..the design of a solution, particularly when it involves a complex custom extension, does not necessarily take longer just because you put more thought into the functional requirements. In fact, one could argue the complete opposite, in that by putting more emphasis on clearly understanding the nuances of functionality requirements early in the process, then the overall time and cost incurred during the Analysis to Design process should be less.

In short, as your understanding of requirements matures over time, it is far easier (and more cost effective) to update a document or a diagram, than to change lines of code.

So how does that translate into Tasks and Work Products in OUM?

Let us assume you have reached a point on a project where a Custom Extension is needed. One of the first things you should consider doing is creating a Use Case, and remember, a Use Case could be as simple as a few lines of text reflecting a “User Story”, or it could be what Cockburn1 describes as a “fully dressed Use Case”.

It is worth mentioned at this point the highly scalable nature of OUM in the sense that “documents” should not be produced just because that is the way we have always done things. Some projects may well be predicated upon a base of electronic documents, whilst other projects may take a much more Agile approach to describing functional requirements; through “User Stories” perhaps.

In any event, it is quite common for a Custom Extension to involve the creation of several “components”, i.e. some new screens, an interface, a report etc. Therefore several Use Cases might be required, which in turn can then be assembled into a Use Case Package.

Once you have the Use Cases attributed to an appropriate (fit-for-purpose) level of detail, and assembled into a Package, you can now create an Analysis Model for the Package. An Analysis Model is conceptual in nature, and depending on the solution being developing, would involve the creation of one or more diagrams (i.e. Sequence Diagrams, Collaboration Diagrams etc.) which collectively describe the Data, Behavior and Use Interface requirements of the solution. If required, the various elements of the Analysis Model may be indexed via an Analysis Specification.

For Custom Extension projects that follow a pure Object Orientated approach, then the Analysis Model will naturally support the development of the Design Model without any further artifacts. However, for projects that are transitioning to this approach, then the various elements of the Analysis Model may be represented within the Analysis Specification.

If we now return to the original question of “Where’s my MD.050”. The full answer would be:

 

  • Capture the functional requirements within a Use Case
  • Group related Use Cases into a Package
  • Create an Analysis Model for each Package
  • Consider creating an Analysis Specification (AN.100) as a index to each Analysis Model artifact

 

An alternative answer for a relatively simple Custom Extension would be:

 

  • Capture the functional requirements within a Use Case
  • Optionally, group related Use Cases into a Package
  • Create an Analysis Specification (AN.100) for each package

 

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

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, http://alistair.cockburn.us/Use+case+fundamentals

 

 

 

 

 

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!!

Wednesday Dec 14, 2011

Build Up Or Tailor Down?

OUM is intended to be highly scalable. In our industry today we hear lots of buzzwords around Agile or Agility. We see many methods in today’s marketplace that have adopted an agile approach to software development. The Global Methods team is in strong agreement with the tenets put forth in the “Manifesto for Agile Software Development.” We also see a debate in our industry about agility versus discipline which has been well framed in the book “Balancing Agility and Discipline: A Guide for the Perplexed” by Barry Boehm and Richard Turner.

 

To help OUM’s users determine just how much of OUM they should employ on a given project, we have adopted many of the philosophies and conclusions put forth in the book. It has helped to guide us in developing OUM and also in developing the guidance related to using OUM. By Boehm and Turner’s definition, at its highest level, OUM is a plan-driven method, which could be tailored down by an expert, to fit a particular situation. However, as the book points out, non experts tend to play it safe under these circumstances, and often tend to use to much or all of a method “at considerable unnecessary expense.”

Therefore, we’ve taken the advice of Boehm and Turner and adopted the philosophy of “Build it Up – Don’t Tailor it Down.” OUM’s Implement Core Workflow, along with OUM’s diverse set of views, are intended to support this philosophy.

In addition to the workflow and views, we advise you to follow 4 steps when considering the tasks to include in your OUM based workplan.

The first step is to start from a core set of tasks. We recommend that you consider using the OUM Implement Core Workflow for this purpose along with an OUM view that best matches the needs of your project. Remember, though, that the views tend to be a superset of tasks related to a particular solution, discipline, or technology. Therefore, the core workflow and views should be used together to achieve the right balance for your project.

Further information on tailoring OUM can be found in this White Paper: http://my.oracle.com/content/native/cnt723708

An external version of this White Paper will be published early in 2012 along with recorded training for Oracle Consulting, along with our Partner and Customer community. 

 

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
About

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

Read:

· Brief

· White Paper

· Customer Program Data Sheet

Connect:

· OUM on Twitter

· OUM on LinkedIn

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Feeds