Requirements Definition in an Age of Distributed Development
By Tony Higgins, Vice President of Product Management, Blueprint
Businesses today rely on application software to automate and empower essentially
every single critical business process. Not an organization in the developed
world can process a sale, manage their employees, or manage their financials
without business software. No longer an accessory -- software is the business.
In today's challenging economic environment, project teams are being stretched
to deliver against increasing business challenges to enable organizations to
sharpen their competitive edge. In a global market place, this continual pressure
on IT is not just stretching team capacity; it is actually stretching the organizational
structure as well. In fact, in 2009, over 70 percent of business and IT teams
are geographically distributed and globalization is the business driver for
the majority of new projects.
With geographical distribution becoming the standard operating procedure, collaboration
between business and IT teams around project requirements has become a new focal
point to control project team efficiency and effectiveness. Organizations must
improve the fidelity and precision of their software requirements to ensure
that IT delivers the right solutions that the business needs. Communication
of project requirements must evolve to eliminate the cultural, geographic, and
time-zone barriers that now exist between these separated colleagues.
This paper will explore how software projects are improving the collaboration
between distributed IT and business teams by focusing on requirements communication.
We will explore how visual requirements simulation plays a critical role to
ensure understanding and to eliminate barriers to productivity that naturally
exist within distributed, global teams.
Requirements are the blueprint to the functionality, interoperability, and
integration of business software. As organizations drive to streamline, consolidate,
and modernize existing applications, requirements complexity is also increasing.
Requirements analysis has become a job within itself, with an emerging dedicated
stakeholder (usually referred to as a business analyst or systems analyst) that
services the development and communication of project requirements to business
and IT stakeholders.
As the world gets smaller and businesses expand to reach new markets and lower-cost
suppliers, globalization has become a major driver of IT projects. In 2009,
the majority of IT projects are designed to assist businesses scale to meet
the needs of globalization. According to a recent CIO survey by Smart Enterprise
on Globalization and IT, over 50 percent of IT teams are being asked to build
systems for non-US supply chains, 40 percent are being asked to deliver software
applications that leverage third-party technology service providers, and 60
percent of new projects are serving customers that sit in a different country.
As projects become more complex and global, development teams have also become
more distributed. A recent report from the IEEE cites that, "key risk factors
associated with IT development projects are magnified or multiplied when dealing
with distributed project teams."
Distributed teams are largely in place due to business impacts from globalization.
Mergers and acquisitions, the need for new talent pools, the leveraging of lower-cost
resources, outsourcing, and overall business geographic demand are all driving
this distribution. According to the IT Strategy Center, the most significant
impacts of distributed teams are directly related to communication of business
context, the implementation of language barriers, time zone separation, the
lack of physical exchange, and the reliance on batch oriented communication.
Increasing geographic distribution
Enterprises range across four distinct levels of team distribution. Each level
creates a unique set of challenges for defining and communicating project requirements.
At level one, business and IT teams are co-located in the same building. Just
a decade ago, this was the most common scenario, but today this represents less
than 30 percent of Fortune 500 IT teams. At level two, business and IT teams
are distributed at a department level. IT is usually centralized and acts as
a service arm to the business. At level three, business or IT teams themselves
are geographically separated, increasing the complexity and challenges of interdepartment
collaboration. Finally at level four, globalization has created the ultimate
geographic challenge, with team separation and distribution pervasive across
the globe. With globalization and the rise of outsourcing, this has become all
Increasing challenges of requirements communication with global teams
As organizations embrace more distribution, the challenges to understand the
context of application requirements increase significantly. These challenges
include intra-teams functional capabilities, task understanding, gaining organizational
consensus, and the cultural challenges to understanding. These challenges (and
risks associated with them) increase significantly as teams become more distributed.
Communicating requirements is at the center of the challenges of distributed
teams. Traditional methods of communicating requirements, including enumerated
lists of features, functional and non-functional requirements, business process
diagrams, data-rules, etc., generally are documented in large word-processing
or spreadsheet documents. When applied to distributed teams, this method of
communicating requirements creates significant waste and opportunities for failure,
as the barrier to understanding can become too great to overcome.
Incorrect interpretation and the lack of requirements validation can create
artificial (or false) goals which consume valuable resources. Due to the nature
of software development, these false goals manifest themselves into incorrectly
implemented code, resulting in costly waste and rework. Outsource providers
often treat such rework as change, resulting in costly charge-backs to the business.
Multi-aspect definition, validation and simulation enable more effective
CIOs can adopt new requirements definition practices and techniques to appropriately
eliminate the risk associated with distribution. These practices include shifting
away from the heavy use of natural language expression and moving toward the
use of multi-aspect requirements definition with visual simulation and validation.
Multi-aspect requirements definition enables organizations to standardize on
rich requirements that eliminate ambiguity and imprecision that often exists
in the geographic separation of teams.
To significantly reduce the probability of ineffective requirements communication
through natural language documentation, IT organizations are transitioning to
more precise vehicles to communicate requirements.
One of these vehicles is the adoption of the multi-aspect definition approach
to communicate requirements in a highly visual way. Multi-aspect definition
provides detailed context capture through highly precise data structures. These
definition elements used in these holistic representations include use-cases
for role (or actor) based flows, user-interface screen mockups, data lists,
and the linkage of decision-points to business process definitions. These structures
augment enumerated lists of functional and nonfunctional requirements.
The benefits of this approach include the use of simulation to ensure requirements
understanding. Simulation is a communication mechanism that walks requirements
stakeholders through process, data, and UI flows in linear order to represent
how the system should function. Stakeholders have the ability to witness the
functionality in rich detail, consuming the information in a structured way
that eliminates miscommunication entirely.
Multi-aspect definition and simulation also provide context for validation.
Validation is the process in which stakeholders review each and every requirement
in the appropriate sequence, make appropriate comments, and then sign-off to
ensure the requirements are accurate, clear, understood, and are feasible to
be implemented. Requirements validation can be considered one of the most cost-effective
quality control cycles to ensure team understanding.
Since requirements are the "blueprint" of the system, distributed
stakeholders use multiaspect definition and simulation during implementation
to understand the goals of the project. Simulation eliminates ambiguity by providing
visual representation of goals which, in turn, eliminates interpretation.
Rich requirements documentation often is a specified deliverable for most IT
projects, due to regulatory compliance (Sarbanes Oxley, HIPAA, etc.), internal
procedural specifications, and other internal review cycles. Multi-aspect definition
can serve as the basis of this documentation, and next generation requirements
workbench solutions can transform models into rich, custom Microsoft Word documentation.
The amount of effort required to build and maintain these documents is minimized,
since these documents are autogenerated.
The economic landscape is only becoming more global and distributed each year.
Requirements definition for distributed development will continue to be one
of the bigger challenges facing large organizations. But by building in multi-aspect
definition, validation, and simulation into your requirements definition process,
organizations can learn to effectively build and communicate requirements across
About the Author
Tony Higgins is the Vice President of Product Management for Blueprint, a leading provider of requirements definition solutions. He can be reached at firstname.lastname@example.org.