Atomic Use Cases - Fission or Fusion

With the advent of Pega's DCO features has come the rise of the term "atomic use case.” As with so many terms which become popularized "atomic use case" means many things to many people.

The question is: What does it mean to you?

Well, for starters, it means you've got to formulate your opinion of what the term means or you're going to be powerless to participate in any DCO-enabled projects. You CAN sit there and nod sagely without a clue. You can make up your own meaning. You can do some research on the internet on these and other UML terms. These are but some of your choices, but so far none of them puts you in the position of participating in a valuable capacity on your client project.

Let's start with "use case.”

Lots and lots of folks have talked about use cases forever. Interestingly, it turns out that this terminology is as old as Pega. It goes back to Ivar Jacobson's work in UML back in 1986. http://en.wikipedia.org/wiki/Use_case

In 1986 Pega was architected using the bold choice of PL/1 in VMS and MVS/CICS environments at that moment in time. The PegaSYSTEM was hardly object-oriented at that moment. In point of fact, as the Wikipedia article points out, use cases themselves aren't necessarily object-oriented although they've originated in the object-oriented community. They are, in fact, by definition procedural because they describe a process in time order.

Use cases detail a sequence of events or actions initiated by an actor in order to achieve a goal. Yes, it can be one or more actors, so long as they are set on achieving the same goal. For example, someone in a retail store could help a customer fill out an online application for a store credit card. Via the web, that same customer could do the same thing themselves. The goal is to complete the application and send it off for processing/approval. So in this case we have two actors who will use the system to achieve the same goal – the same usage.

In our world, actors can be people or other systems. For example, in a SmartPAYMENTS setting, it could be a Swift, CHIPS (the kind without Ponch and Jon), or FEDWire message that kicks off the creation of a new case.

A use case is going to capture a sequence of actions or events then. You can see how this would be a good way to capture requirements around various system features and functions. You learn who does what and in what order. You should uncover the decisions they make as they go. This process will start to get you into the DNA of the system and the business functions it must enable.

Done properly you will capture a lot of the requirements, at least the functional ones. Note: You will need something else to help catalogue your non-functional requirements – things such as, "The system must be available 24 hours per day, 7 days a week, 365 days a year."

So why atomic use cases?

Well, frankly use cases come in all shapes and sizes and lengths. It's easy to get lost in all the information you've gathered, and it's even harder to know what you don't know yet.

If a use case can have an unlimited number of steps, then it can be as hard to break down, analyze, design, and build, as any other form of requirements-based documentation.

If a use case can be at any level of detail, the overall project sizing, design, and build can be compromised. In some cases you'll have every little mouse click. In others you'll be missing entire screens and critical interfaces. How do you size and manage that reliably? How do you know you've accounted for what you don't know? How do you cope with resourcing? One developer per use case? Two?

The industry has started to popularize the term "atomic use case" of late, as people recognize that the devil is indeed in the details.

Breaking use cased down into their smallest size also enables us to break them into their most reusable, most common elements. From there sizing, planning, designing, and building become much more predictable. With predictability comes reliability and common practices for risk mitigation, communication, etc.

So atomic refers to sizing. Is that it for Pega and DCO?

Pega doesn't require only "size" to define or limit a use case. There are other criteria which drive the definition or identification of an atomic use case.

An atomic use case:

• Specifies one or more actors
• Specifies a single event or method that triggers it
• Does not involve a change of ownership during processing
• Corresponds to one particular step or series of steps within a screen flow or a single flow action in the processing of a work type
• Describes the processes to be performed including the steps involved in completing the use case, applicable edits, and the expected behaviors and outcomes
• Provides enough business detail so that a developer can implement it
• Should only take a few minutes to enter into the PRPC Application Profiler

Think again about reusability, about tracking, reporting on your design and build progress in a project. You have people who need to track how much is built to support the stated requirements, as well as how much is tested and ready for promotion to production. And then there are milestones and invoicing as that project progresses.... You literally need to know what requirements are "built out" and "testable" and "delivered" and which are not.

Pega's DCO features enable you to create, edit, and maintain (yes even delete, but careful as always with this) atomic use cases. The intention is to connect them to the actual rules in the application that manifest and enable them.

Atomic use cases are referenced by:

• Flow Rules
• Activities
• Local Actions and Flow Actions
• "New" Harnesses

As such, it does you little good if you have one gigantic use case referenced to every single "New" Harness and Activity and Flow Rule you've created for the 250+ features you're building. What you must do is limit the size and scope of the use case so that you truly know whether it's been built, and whether it can be tested, and whether it's ready for delivery/promotion to Production.

So, it's fission? How do I know when I'm there?

You need to know the scope of your engagement. Whether you're working on an Agile or waterfall project, scope is critical. From there, you need to work the business process flows out at a high enough level that you can identify connections, commonalities, and at least some of the actors.

If you're working within a solution framework, then a lot of the groundwork is already done for you. Generate the use case catalogue for your framework. Generate the list of actors, etc. already accounted for by the framework. Work with your client to identify the differences. Identify what's not accounted for, what must be built custom to support the client. Zero in on these areas.

Your client can also help you cross use cases and actors off the list, where the framework is not applicable to the current project. Don't delete them. Just set those aside for now. Keep moving.

Whether you're working with a framework or a custom solution, start mapping out the business processes (diagrams of any kind, especially vanilla flowcharts can be of use here). Work with your SMEs to drill into enough detail that you can tell the difference between a large, complex process, and a smaller, more straight-forward one.

As the detail emerges, start applying the guidelines Pega has given for atomic use cases. For example, make sure your work object doesn't transfer to a new party or system for further processing. If it does, your use case stops and a new one starts. If your process requires that you make multiple interface calls to gather data, then each one of those calls should be its own use case.

Be sure and think about your functional design tools here, including flowcharts and other pictorial representations of processes. http://www.knowledgerules.com/blogs/life/2009/08/functional-design-picture-is-worth-1k_757.html It may be easier to identify use cases by reviewing diagrams and marking boundaries between handoffs. It’s easier to keep consistent with sizing in this fashion too.

Make sure to engage your LSA in this process. He or she will be able to apply not only a keen business eye but a keen technical eye to the use cases you're discovering. Your LSA may be able to find further places to break business use cases into smaller pieces.

Educate your client at all levels of the project as to why you need to get to this level of detail, and the risks you run where this level cannot be obtained. On tight deadlines, lack of detail in the requirements compounds the work for design, build, and test. Lack of detail also adds risk to each stage of the project, where risk can manifest as additional time, money, and resources.

You will experience a time period where more and more use cases are identified. That's ok. Keep listing them. Prioritize. Not all have to be fleshed out immediately and you'll even find some may be outside the scope of the current project (especially if you're working with slivers). Set those aside, keep moving on the critical path.

It's also fusion.

Be especially sensitive to things that are common. It could be that a customer accesses a system over and over again, picking up one data element and then another during data gathering. It could be that because the access is really the same, but the property you're picking up is different that you're really in the same use case. All that needs happen is to parameterize the call.

Work with your LSA especially to be sure that you don't unnecessarily fragment your use cases, where you have several that are all alike except for one thing.

Also, be sure that once your atomic use cases are all identified that you can build back up from them to the business process you're enabling. If you can't, something is missing. Find it. Address it.

Again working from process maps, not just heavy text documents should help you perform this "reverse check.”

Is that all?

Identify your atomic use cases by name and get them as fleshed out as possible so you can move on to the next steps. With DCO and the Application Profiler, you can identify your use cases as you find them – just name them. You can then associate your steps, requirements, actors, and complexity. When the profile is generated, DCO will yield a sizing with which you can work to tune the rest of the stages of your implementation.

That's not the only time you can create or add atomic use cases, though. Once the application ruleset has been created and people are working away, you can always come back and add new use cases directly into PRPC and associate them to the rules which bring them to life.

Doing this improves traceability not only for requirements but at a project management level. You can continually generate your DCO documents to show the build against the requirements and design. This is an extremely useful tool in your arsenal when managing scope and relationship dynamics. A simple mouse click can enable you to list the use cases and the application rules necessitated by them. Whether in spreadsheet form or Word Document, this can be very insightful, and a great tool to communicate progress, risk, and start the conversations to close any gaps.

Atomic use cases are the building blocks in this puzzle, no doubt. The consulting skills it takes to identify, analyze, and catalogue them are the critical tools you need to create them and a solid foundation for your project.