Get the Business Requirements Right
and Project Success Will Follow
Amit Aggarwal
FIS Consulting Services
800.822.6758
Get the Business Requirements Right
and Project Success Will Follow
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 in order to
keep financial institutions on par with nontraditional competitors. These complex projects need to deliver solutions that
transform the financial institution, while contributing significant efficiency gains to the bank. Overall, the banking industry
has failed to lower its efficiency ratio, which has lagged at 60 percent for the last three years. Below is a graphic that depicts
this industry productivity stagnation.
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
©2014 FIS and/or its subsidiaries. All Rights Reserved.
Get the Business Requirements Right
and Project Success Will Follow
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
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.
2
From “The Need for Secure Software” by Paul Mano, ISC Software Magazine, March 20,2014
3
©2014 FIS and/or its subsidiaries. All Rights Reserved.
Get the Business Requirements Right
and Project Success Will Follow
“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
©2014 FIS and/or its subsidiaries. All Rights Reserved.
Get the Business Requirements Right
and Project Success Will Follow
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 work flow 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 in order 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.
Technical
Business
Stakeholder
Testers
People
critical to
requirements
End users
and/or clients
5
©2014 FIS and/or its subsidiaries. All Rights Reserved.
Get the Business Requirements Right
and Project Success Will Follow
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.
Bank
business
lines
Operations
&
technology
Application
teams
Consultants
Solution
architect
Sales
Product
knowledge
Past product
knowledge
One set of
definition
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 versus 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.
6
©2014 FIS and/or its subsidiaries. All Rights Reserved.
Get the Business Requirements Right
and Project Success Will Follow
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 in order 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 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 many times presented in a ranking (high, medium, 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 time frame, 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 highquality 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.
7
©2014 FIS and/or its subsidiaries. All Rights Reserved.
Get the Business Requirements Right
and Project Success Will Follow
For More Information
The FIS Consulting Services 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 FIS Consulting Services, call 800.822.6758 and/or visit www.fisglobal.com.
8
©2014 FIS and/or its subsidiaries. All Rights Reserved.