WHITE PAPER

Get the Business Requirements Right and Project

Success Will Follow

Amit Aggarwal
FIS Consulting Services

1 800 822.6758
Get the Business Requirements Right and Project Success Will Follow WHITE PAPER

Relevant Industry Trends

The information technology (IT) landscape is littered with failed projects that left stakeholders dissatisfied and
budgets drained. One of the most common failing points in large technology-driven projects is the inability to
obtain the business requirements needed to drive all project participants to deliver anticipated results. This
shortcoming has been documented by numerous sources including Forrester Research. In a 2010 study, they
noted that poorly defined applications have led to a persistent miscommunication between business and IT. This
contributes to a 66 percent project failure rate for these applications, costing U.S. businesses at least $30 billion
every year.1

This message resonates within the banking industry as increasingly complex IT initiatives have become the norm
to keep financial institutions on a par with nontraditional competitors. These complex projects need to deliver
solutions that transform the financial institution, while contributing significant productivity gains to the bank.
Overall, the banking as an industry has failed to significantly improve its average Return on Assets to levels
before the financial crisis of 2008. Further proof that they must better leverage transformational technology.

FDIC-Insured Institutions
2.5
2 1.21 0.97 1.10 0.96 1.03 1.04
1.5 0.65 0.76
Percent

1 0.18 0.03
0.5
0 -0.94
-0.5
-1
-1.5
-2
-2.5
2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016

Fourth Quarter Figures

Average ROA

IT projects need to efficiently deliver productivity solutions that hit the mark the first time. The high cost of failure contributes to
many financial institutions losing their independence. One of the primary ways to increase bank efficiency is to avoid rework
and false starts in IT projects. Getting the correct business requirements right initially goes a long way to achieving project
success and delivering productivity needed for a bank’s survival.

1
From “Re-evaluating Approaches to Requirements Management “on Performance Institute Web site, May 2014

2
Get the Business Requirements Right and Project Success Will Follow WHITE PAPER

Cost of Poor Business Requirements

Examples of the repercussions of poor business requirements exist in today’s world and throughout history. Think
back to the building of the Titanic. Certainly, there was a high-level requirement that the ship was to be
unsinkable. Sadly, the details supporting that requirement were never properly vetted. Business requirements
need to be clear enough to remove uncertainty from the minds of developers.

Another real-life example of the need for solid requirements comes from those with experience in building a
custom home. One can recite the horror stories of friends and family who attempted to create their dream home
from a blank slate. Many dollars, delays and overruns later, the house is built. One does have to wonder how
much angst could have been avoided if solid requirements for the new home were developed before
construction began?

In IT development, getting requirements correct on paper is much preferable to trying to make changes after a
new system has been implemented. According to a recent study by IBM Systems Science Institute, the cost of
fixing defects in development projects increases to 100 times after project completion.2.

2
From “The Need for Secure Software” by Paul Mano, ISC Software Magazine, March 20,2014

3
Get the Business Requirements Right and Project Success Will Follow WHITE PAPER

Attributes of Good Business Requirements

Understanding the impact of bad business requirements: What then are the attributes of good
business requirements?

The following is an example of a clear business requirement. It eliminates ambiguity and provides enough details
to guide the developers working on the project.

“Existing customers are to be authenticated when accessing the online servicing system by entering a
user ID and password.”

“User ID is 6 to 8 characters (alpha and numeric). At least 1 character must be numeric and
1 character alpha.”

“Password is 8 to 10 characters and must contain at least 1 alpha, 1 numeric and 1 special character.”

Developing good business requirements requires answering the questions of who, what, where and when. These
are the same questions journalists must answer as they write the lead to a breaking news story. Business
requirements stop short of describing the “how”. This is left for the developers to solve. Questions to ask to get to
the specifics of who, what, where and when include:

• What data? What action(s) will be required?

• Where is data coming from and going to?
• At what point(s) does an event need to occur?
• Who will be impacted by the requirement?

If the business requirements are fleshed out correctly, the most critical issues and risks will bubble up from the
process and can be resolved prior to code development beginning.

Types of Requirements
Business requirements are the starting point and provide the foundation for the other types of requirements that
feed an IT project. Failure in developing clear business requirements can weaken functional, technical and testing
requirements. The following definitions apply to the types of requirements FIS™ solution architects develop and
manage as part of creating complex solutions for banking clients.

• Business requirements – Contain objectives, goals and financial expectations. Provide high-level
functionality descriptions and eliminate ambiguity.
• Functional requirements – Contain the details on configuration needs, screen layouts, product features and
client support requirements. Are more detailed than business requirements.
• Technical requirements – Contain details on how a system will run and the parameters it will operate under.
They have details on scalability, reliability, security, compliance, performance and operational characteristics.
• Testing requirements – Contain more granularity than other requirements. Allow the ability to isolate a
specific feature or capability to ensure functionality.

The requirements beyond business level are very detailed and outline exactly what needs to be delivered and
would typically be read by business analysts, developers, project managers and testers.

4
Get the Business Requirements Right and Project Success Will Follow WHITE PAPER

The Role of Business Process Improvements

Another type of requirement that should be explained and incorporated into design documentation is the business
process improvement. Process changes usually occur as part of any transformative initiative. Business process
improvements are changes to activities that people in a financial institution perform. Once these changes are
defined, they will generate business requirements to be captured.

These improvements create greater efficiencies and are often developed in conjunction with the deployment of
new technology that creates new workflow alternatives. The solution architect needs to note these changes and
ensure their documentation is as clear as any other technical requirement.

People critical to creating solid business requirements

The individuals that gather business requirements serve as facilitators. They must meet with a wide variety of
stakeholders and contributors within a project to gain a comprehensive view of the needed business
requirements. The solution architects working on business requirements must have industry and domain expertise
and a broad perspective on banking technology and capabilities.

At times the value of solution architects is subtle, but profound. Their ability to ask the right questions during
planning sessions can uncover critical issues, best solved before a single line of code is written. In large initiatives
spanning multiple platforms, vendors and business units, the solution architects employed must have a broad
vision and expertise − allowing them to keep sight of the big picture and document the best possible business
requirements. These architects do not operate in a vacuum. Rather they facilitate the people critical to
requirements gathering as depicted in the following diagram.

Taking the input from individuals in the above roles, the solution architect creates requirements by acting as a
focal point for diverse information as shown in the following process graphic.

5
Get the Business Requirements Right and Project Success Will Follow WHITE PAPER

Bank Operations Product Past

Application
business & Consultants Sales knowledge product
teams
lines technology knowledge

One set of
Solution definition
architect deliverables

A proven process for gathering requirements

Individuals responsible for gathering business requirements should follow a proven, logical approach to gathering
and validating business requirements. FIS solution architects employ these steps to help them collect, document
and validate client business requirements.

• Conduct interviews and structured workshops – Conduct formal and informal interviews and briefing
sessions. If you are operating under tight time constraints, consider a facilitation method such as Helix to help
reach consensus on important decisions.
• Document findings – Start documenting business requirements sooner rather than later in the process. The
more time you can give stakeholders to react to potential requirements, the better.
• Validate findings – Conduct meetings, webinars and informal sessions to review written business
requirements with all stakeholders at the financial institution.
• Finalize and communicate requirements – Leverage a formal business requirement document to present
and distribute the requirements to all stakeholders including external third-party partners that are key to a
project’s success. Have a formal approval process as a part of this distribution effort.

The primary objective of the business requirements document is to frame key deliverables and objectives in a way
that is meaningful to the intended audience.

Case Studies
Third-party integration effort
The first example of gaining proper requirements encompasses the effort to integrate a third-party loan origination
system with a core processing system from a different vendor. Each of the two vendors and the bank staff
required explicit instructions to achieve a cohesive outcome. Multiple interface points between the point solutions
vendors and other third-party sources (e.g., credit bureau, scorecard firm, fraud component and pricing engines)
had to be accounted for in the planning. The approach to capturing the business requirements included clear

6
Get the Business Requirements Right and Project Success Will Follow WHITE PAPER

identification of each organization’s responsibilities along with an identification of any product gaps and how they
would be filled.

Details of the communications between the entities involved in the integration effort included:
• API and file formats
• Frequency of updates between systems
• Data mapping details
• Process flow and integration diagrams

Developing new target operating model

Another example of an approach to developing solid requirements is in the case of a core transformation. These
large, complex programs may require a team of solution architects to reach across many lines of business and
develop a relatively large set of business requirements. The first step to developing requirements in this type of
effort is to develop a program structure conducive to working “on the fly”. Many times these transformation efforts
have predetermined deadlines and requirements gathering must be compressed. The architects must quickly
assess and provide feedback on the nature of requirements in order to facilitate decision making and not get
stuck in analysis paralysis.

Impacts of business requirements are often presented in a ranking (high, medium and low), and rough time and
cost estimates are needed to move forward. In this particular case study, the architects kept a working copy of the
business requirements at all critical meetings to document changes in a real-time mode and to serve as a
reminder of what points required further validation. In a compressed timeframe, every meeting contains a
relatively high value and a structured requirements gathering process is vital to meeting deadlines.

Summary
By following a standard methodology and proven best practices, a solution architect can develop the appropriate
business requirements to keep even the most complex efforts on track. The following are the key practices for
developing high-quality business requirements.

• Maintain diligent management of requirements. Continuously update documents as requirements change. If it’s
not documented, it’s not a requirement.
• Document and execute changes using a defined change control management process.
• Establish a clear governance structure. The roles and responsibilities of all stakeholders should be understood
by all involved in the project.
• Inform all stakeholders as change occurs. Thorough communication creates the foundation for
project success.

For More Information

The IBS Consulting team of specialists comprises practitioners in financial services, operations, technology, and
retail and commercial banking. Our expertise spans the many facets of business requirement development.

For more information on IBS Consulting, call 800.822.6758 and/or visit www.fisglobal.com.

7
©2017 FIS and/or its subsidiaries. All Rights Reserved.