Problem occur without using DCO:

Business application requirements gathering is famously hard. It’s hard for IT to

sort out business priorities and get the details they need from busy business
people. It’s hard for business stakeholders to sign off on 600-page documents of
requirements. Overall, the process is exhausting, filled with meetings where
“minutes are kept and hours are lost.” No wonder industry stats report that 70% of
IT systems fail to meet business requirements.

Business user is failed to explain business objective of the application and it is very
difficult for IT team to get the requirements from business user. Business and IT
team are not sharing a common understanding and goals that impact the quality of
application.

After getting requirements from business peoples, development team start working
on requirements. At the time of testing an application or at the time production
phase, they analyze that requirements are different and development team
developed something different due to lack of communication between business and
IT Team.

Pega come with a solution so that business and IT team can share the common
understanding and goals from the start of project to till end of the project. We call
it as DCO (Directly Capture Objective).

By the help of DCO, instead of creating mountains of requirements documents,

business people and IT use a shared visual model i.e. Designer Studio that can
directly insert requirements into the application and it will automatically
generate the documentation you need.

DCO dramatically increases both the speed and accuracy with which applications
are delivered and it also helps better engage with business in the enterprise
projects.

Video URL: https://www.pega.com/insights/resources/build-change-directly-

capture-objectives-dco
Business Objective:

Planning is a critical phase of application development. As a business architect,

you analyze business needs and capture these needs in the form of business
objectives and requirements, in Pega.

A business objective is a result that a company aims to achieve. It also includes

the strategies that people will use to get there. A business objective usually
includes a time frame and lists the resources available.

Role of Business Architect during analysis:

As a business architect, you:

• Identify what your clients need to run their business.

• Propose Pega solutions to add value to the business.

• Elicit input from multiple stakeholders to build consensus.

• Work to build a shared understanding across teams.

Key activities to analyze Business need:

To analyze needs:

• Identify business users.

• Discover what adds value to the business.

• Gather information about business problems.

• Synthesize input from multiple stakeholders to identify possible solutions.

How to define “SMART” business Objective:

a) S (Specific) business objective: A “specific” business objective describes

exactly what needs to be done and the results of the work to be done. 

Example: 1000 or more account creation online each month by the end of
2Q19.

Specific: Describe what to deliver

 b) M (Measurable) business objective: Describe specific measures we use to
determine if we are successful in achieving the business goals.

Example: 1000 or more account creation online each month by the end of
2Q19.

Measurable: Quantifiable & Reportable

c) A (Achievable) business objective: “Achievable” means that stakeholders

are in agreement that an objective is attainable.

Example: 1000 or more account creation online each month by the end of
2Q19.

Achievable: Realistic according to stakeholders

d) R (Relevant) business Objective: Identify business objectives that add

value to the business and are relevant to the Pega solution.

Example: 1000 or more account creation online each month by the end of
2Q19.

Relevant: Impact core business value

e) T (Time-Bound) business Objective: Include time-bound end points and

check points in the business objective.

Example: 1000 or more account creation online each month by the end of
2Q19.

Time-Bound: Target date

Requirement

Requirements describe what the Pega application must do to satisfy business

objectives.

A good requirement:

 Describes desired behavior in a clear and concise manner

 Is understood by business and technical audiences
  Is written in a manner that can be tested and confirmed.

Tips of Writing Requirements:

a) Verifiable: Include information that allows someone to test the requirement

in the Pega application. The tester is able to evaluate the requirement in a
way that does not compromise the integrity of the application or the
associated data.
b) Clear & Concise: Write a brief description for the requirement. Keep the
length short (no more than 30 to 50 words). Use active voice, with proper
grammar, spelling, and punctuation.
c) Complete: Provide all of the information necessary to define the
corresponding feature.
d) Consistent: Use consistent terminology and syntax in your requirements so
that solution architects can quickly identify related requirements and
functionality.
e) Traceable: Traceable requirements help us understand how a requirement
specifies a feature that satisfies a client need. Each requirement is linked to
the corresponding specification and related rules in Pega to assess
application progress.  
f) Viable: The development team should be able to satisfy a good requirement
within the project schedule and budget, using available technology and staff.
g) Necessary: The requirement describes functionality that must be in scope to
meet the business objectives. Omitting the requirement may lead to a
deficiency within the application.
h) Solution-Free: Write requirements that relate to business needs and
operations. Do not mention solutions.
i) Granularity: Choose an appropriate level of granularity for your
requirements. Write individually testable requirements. Avoid long narrative
paragraphs.
j) Singular: Avoid redundant requirements.
 k) Understandable: A requirement is understandable when the business and
technical stakeholders have a shared understanding of the business context
and intended meaning.

Requirement is divided into 5 categories:

a) Business rules: Describe the processing of the business logic in a case.

These are often associated with a step in the process — either manual or
automated — to identify desired system behavior. To identify business
rules, look for information that frequently changes.
b) Change Control requirement: Describe changes that impact the Pega
application. The change may be relevant for a new Pega application or an
existing one.
c) Enterprise standard requirements: Document any enterprise or
industry standard to which our application must adhere, such as a specific
data format for information.
d) Functional Requirement: Describes what a software system should do.
A function is a set of inputs, outputs, and associated system behavior.
e) Non-Functional Requirement: Describe the behavior of the system as
it relates to system functionality. Non-functional requirements often
include a constraining attribute.
Specification

A specification uses business language to describe how an application will satisfy a

requirement. A specification is:

 An agreement with your customer on exactly how the system will

operate.
 A point of synchronization for the project team.
 A basis for building a master plan and schedule.
 Instructions to architects on what to build.
 A baseline for change control.

There are 2 types of specification:

  Business use cases describe an entire process or subprocess, and
document the steps in that process.
 Atomic use cases are much more granular, and focus on one specific step
in a process — though they can be subdivided into substeps.

Tips of writing good Specification:

Questions answered by good specification:

a) Who: Identify the user responsible for performing the work or task. It can be
a customer, manager, or the system.
b) What: Identify the work that user performs. User either will enter data,
review data, calculate some value, or take a decision.
c) When: Identify when the work occurs.
d) How: Identify how the user perform the work. User either enter data or
select from a list or user will read data from database.
e) Why: Identify the reason why the user performs the work. Either user
required information for a decision, user should perform some action in a
specific order.

You capture specifications directly in Designer Studio from the Application Profile.

 When you create the specification, you may not know all of the details for the
specification. At a minimum, enter Name, Short Description, and Description.

 Create a short Name that corresponds with the action in the specification.

 The Short Description summarizes the action in the specification.

 The Description defines the expected behavior of the specification and

required steps to complete it.

Determine traceability

 Linking your specifications to business objectives is a critical part in enabling

traceability in your application.

 When you initially create your specification, identify the business objective
that the specification meets.