by Molly Eddington
Business application requirements gathering can be daunting. Members of a project team often have very different perspectives on what the requirements of a project are. They may not agree on priorities. And it can be challenging to try to ensure that everyone understands what needs to be done. The process can be time-consuming and frustrating, filled with endless meetings.
Luckily, there is an easier way.
DCO, or “Directly Capture Objectives,” presents a combination of processes and tools to help project teams better capture, organize and store application-specific artifacts. DCO helps the people on those teams to document and visualize the business needs so that they can collectively look at them and agree on precisely where they need to go in the project.
What Exactly Is DCO?
DCO, or Directly Capture Objectives, is a combination of processes and tools for capturing, organizing and storing application specific artifacts, using Pega 7, during the entire project implementation lifecycle. DCO is an enabling technology that can be used collaboratively by all project participants, including QA/Testing resources, and especially by Business and Technology representatives.
Why Do We Need DCO?
Application development depends upon the accurate collection of objectives, requirements and specifications (use cases or user stories) which describe:
- how users process cases
- what data they need to collect
- which policies govern their actions.
DCO ensures that all this information is up-to-date, consistent and available to anyone who needs it.
DCO saves time, effort and money by addressing any knowledge gaps between business and application developers, by creating a common understanding, and by reducing wasted effort due to misunderstandings. DCO also helps ultimately to automate the work that has been a primary pain point for the business.DCO is the first landing point where they can start visualizing that automation.
DCO also offers a traceable central repository for all application-specific artifacts. It essentially captures all knowledge about the application within PRPC, including objectives, requirements, specifications, and actual solution artifacts (the RULES).
Key Components of DCO
DCO creates a core structure of the application for quick rapid prototyping.
Requirements and Specifications
Requirements defines what an application must do or allow to satisfy one or more business objectives. Specifications, on the other hand, define how an application satisfies one or more requirements.
Case Type represents a specific business transaction that requires many tasks in order for completion. In DCO, these tasks are represented as steps, and steps are then grouped into stages.
Documents produced within DCO include the following:
This document, intended for project stakeholders, describes the project and communicates project vision.
This document, intended for project participants, collects the specifications for DCO sessions.
The Application document, useful for training, describes what was built, and provides in-progress snapshots.
This document estimates the project timeline and the amount of effort involved.
How DCO Stacks Up Against Methodology
DCO is not a substitute for an implementation methodology, nor is it part of a specific implementation methodology. It is, rather, a strategic approach to facilitate PRPC application development as well as increase methodology efficiencies.
It does so by:
- making the implementation process simpler to use
- automating many more of the manual tasks
- being flexible enough to be incorporated into an implementation methodology, including PegaBPM, RUP, Waterfall, SCRUM or any hybrid methodology
When to Use DCO With Pega BPM
It’s recommended to use DCO with Pega BPM if:
- clients or projects are used to a more traditional waterfall model and want to start implementing projects with a more agile discipline
- the business wants to stay engaged/play an active role throughout the entire implementation lifecycle
- the requirements have the potential to change
This would involve an iterative approach that releases slivers of functionality at frequent intervals (90-180 days) to incrementally maximize the value gained by the project.
When to Use DCO With Scrum
Scrum is an iterative approach that consists of a number of time-boxed iterative periods called Sprints, that are usually 2-4 weeks long in duration.
DCO might be used with Scrum on any project that has aggressive deadlines, complex requirements and a degree of uniqueness.
DCO Differences Between PRPC 6.x and Pega 7.1
There have been numerous changes and improvements to the DCO components in Pega 7.1.
The most notable changes for Business Architects are:
- Discovery Mapping has been replaced with “Stage based Case Management”
- Focus on iterations (primary path then UI, etc) has been removed allowing for cover all aspects at any time
- Methodology was limited to “Use Case” but now includes “User Stories”
The most notable changes for System Architects are:
- Running the Application Accelerator is no longer required before DCO can start
- Extended UI gallery to provide a more detailed UI look and feel during DCO
- Extended support for guardrail reporting
The following is a complete list of changes to DCO:
- The development of Continuous vs. Static DCO
- Application Express replaces Application Accelerator
- Stage-based Case Design
- Specification flexibility
- Expanded rule linking
- Methodology Configuration replaces Manual Methodology Control. Changes include:
- Configuration setting automates artifact versions
- Automated sizing for SCRUM
- Focus is now work stream-based with prioritization of core, important, and nice to have
- Enhanced documentation features and reporting
- All-encompassing iterations
- Extended collaboration includes tools like Pega Pulse, PDN Feeds, Asset Comments
- Enhanced PMF capabilities
- Visible governance
- Guardrail reporting
- Reporting (OOTB)
- Enhanced UI creation
- Extended UI Gallery
- Real-time UI Inspector
In summary, DCO has many capabilities for capturing business objectives and requirements however it must be kept in mind that the main reasons we should be using DCO is because it can:
- Increase the probability of project success as it drives applications to be built in “business terms”
- Stimulate collaboration and productivity across the entire project team including the end user community that can help make for faster and higher quality implementations, and
- Specifications captured in Pega, means they are available for both developers to build against, testers to test against as well as for all stakeholders. This traceability reduces the chances of missed expectations and errors.