Statistics tell us that 50 percent of all business productivity in the United States is
attributed to information technology (IT). But, most organizations would never
guess that 60 percent of all IT projects undertaken don’t meet original expectations, and
80 percent of those failures can be traced to
bad business requirements. Business requirements reflect or represent an identified business functionality that’s going to be built into
IT or a software application solution.
“Any organization looking to make IT applications a big part of the way they conduct
business needs to be concerned with the capture and the identification of business
requirements,” says Bill Russell, executive
vice president, Allegient. “And the technology team and the business side have to get
together and collaborate in the definition of
those business requirements.”
Smart Business spoke with Russell about
how IT success depends on finding, elaborating, articulating and managing requirements.
Are business requirements about improving
processes or creating new ways to deliver
products, services or processes?
It’s all that and more. It’s about finding
and defining a business function that you
want to utilize, the process that’s going to
deliver that function and the business rules
around that function. Any of those three
can be built into software so it can then be
automated. That’s how businesses accomplish scale. They could use people to do all
of that, but they can’t afford to. So how do
you replace people? You take the same
thing they do by way of a business function
and build that set of functions, processes
and rules into software.
Who specifies requirements?
Typically, it’s the subject matter experts
(SMEs) from within a business who truly
understand the function, workflow and
rules. Since SMEs are so constrained by
time, they articulate these elements, typically to either outside consultants or internal specialized resources called business
analysts, who ensure the information is
translated into a standard, consistent set of
artifacts to be handed to the technology
team, who has to go about designing and
building the software.
What approaches are used to find and elaborate business requirements?
The most common approach is for a designated group of resources, including SMEs,
technology SMEs, business analysts and
sometimes consultants, to collaboratively
design or define the business functions,
processes and rules. The group can break
those down into representative parts and
articulate them in a common format. There’s
a few different ways to do that. One
approach is called the Use Case Model, and
another less formal model is called a
Business Scenario Model or ‘agile’ method.
These are planned methodologies for breaking down business requirements into useable
parts that a software architect/team can take
and build a technical design and software.
How do requirements come into play?
Business requirements are important at
both ends of the process. First, the requirements analysis results go into the definition
of what the user interface will look like and
into a design model. The technology team
then starts to develop a detailed design called
an object model that represents all the functionality the team is going to build into the
system. Second, if you have requirements,
they become the platform or baseline for
building and running a set of test scripts after the system is built to make sure the technology team delivered what you wanted.
What are the technology aspects?
You can’t build a quality-based IT application and software solution without business
requirements. That’s why so many IT projects fail. There are a number of technology
tools available to help guide an organization
in how to state its business requirements,
how to articulate the requirements and how
to maintain and track them. The simplest are
desktop tools like Visio charts to model the
business processes and spreadsheets to build
a feature and rule list. Frankly, those probably are not good enough for a complex IT
project. There are more sophisticated tool
kits on the market, like IBM’s Rational tool kit
or Microsoft’s .NET, whose major function is
maintaining business requirements.
What are best practices for managing business requirements?
Managing requirements starts at the very
beginning of the process when you have to
define them. It’s crucial to have extensive collaboration between the SMEs, the business
analysts and the technology team because
the better the collaboration, the better the
definition, and the better the definition, the
better the system is going to be. Once you
have defined the requirements, they should
be maintained throughout the life of the software application. As you make changes to
the system by way of enhancements or a
major new functionality, you want to make
sure you drive those changes back into your
use cases and back into your business
requirements or scenarios. That traceability
matrix will help you update your testing from
the time those changes were made. You have
to have consistency from your test case or
test scripts, back to development and all the
way back to your original business requirements. This is true for the more ‘agile’ style
development approaches, as well.
BILL RUSSELL is executive vice president of Allegient in
Indianapolis. Reach him at [email protected] or (317) 564-5701.
