Requirements Gathering for Application Design
by Tom Wunderlich (twunderl@arsdigita.com)
ArsDigita : ArsDigita Systems Journal : One article
Even with a seemingly well-defined set of functional requirements, web
service developers and customers often have different interpretations
for how requirements translate into applications. But regardless of
why or how these differences surface, the customer expects the
development team to be accountable and to meet predefined project
timelines and budgets. The outcome is solutions that are delivered
late and result in significant incremental costs to the delivery team
(e.g. additional development resources are needed, developers are
overworked, morale suffers, other projects are neglected). Often the
original project timeline is compromised and customers are generally
unhappy.
With dot.com type clients, these risks are real but manageable. With
larger, more established clients (e.g., Fortune 500), these risks can
result in very public and damaging failures. As web service companies
continue to grow and extend their customer bases, success will be
largely predicated on how quickly and comprehensively they can get to
know their customers and understand their needs.
Typically, web service developers rely on client organizations to
define functional requirements and specifications. In some instances
clients are well organized and projects run smoothly, but many times
there are disconnects between what the client wants and what the
development team thought the client wanted. The results were
predictable: developers logged ungodly hours, worked against
continually moving targets and were expected to achieve unrealistic
milestones. To the credit of the developers, their hard work and
heroic efforts often keep customers happy. But heroics need to be the
exception, not the rule.
The consequences of poor communication during the initial stages of a
project are well documented and integrators are taking steps toward
improving up-front client communication and functional requirements
definition. To this end, web service companies are extending their
customer lifecycle methodologies to include a one to three week
upfront application design for joint development of functional
requirements with the client. The closer development teams and client
can get to a common understanding of functional requirements, the
better the chance for meeting project timelines, budgetary projections
and customer expectations.
The standard customer lifecycle methodology consists of three phases:
the application design phase, for defining functional specifications
and improving communication with the client; the implementation phase,
for developing and launching the initial version of the application;
and the grow phase, for ongoing enhancement and support of the
application.
The application design phase requires a team of business and technical
resources to gather, organize, facilitate, and evaluate functional
requirements. Once the requirements are solidified and the client
approves them, the application design team recruits additional
development resources and seamlessly moves to the implementation phase
with the business resources playing more of a client liaison role.
Technology focused companies often find that they lack the business
resources required for the application design phase and decide to
partner rather than hire these resources internally.
The application design phase can result in several benefits:
Execution of the application design phase requires a one to three week
up-front time commitment from client resources. The output is a set
of functional requirements that are jointly developed and understood.
The approach is to get alignment with the client decision makers early
in the project and put them and their designees through a series of
facilitation workshops and prototyping session to achieve a common
understanding of functional requirements. After several rapid
iterations, the client decision makers are expected to agree and
sign-off on a set of functional requirements. Below, the details and
rationale for of the application design phase are outlined.
The objective of the Establish Client Contacts step is transition the
client project responsibilities from the high level project sponsor to
a client team with defined roles and daily project responsibilities.
The process calls for the internal resources to be aligned directly
with client team members, the result being a joint chain of command
for overall project management and issue resolution.
The initial task is to introduce the client project sponsors to your
way of doing business and set expectations for how the project plan
will be designed, staffed and executed. It is particularly important
for the client personnel to understand their roles throughout the
project.
Activities Work Aids
The client must identify resources to work side by side with internal
resources to build a chain of command for issue management and
resolution. Anytime there is a client services, development,
contract, or other issue, there should be a direct channel to get it
resolved. All issues that cannot be resolved are escalated to the
project sponsor. Included in the core team are resources for defining
the project scope and planning and facilitating requirements
gathering.
The first task is to layout the project scope and to rank each feature
in terms of business importance and technical complexity. This
activity accomplishes a couple of things. First, it gives an
indication of how ready the client is to move forward. If the scope
is not well defined, it does not make sense to begin developing
detailed functional requirements. Second, the ranking of features
becomes the input to defining the initial launch functionality. Armed
with a list of ranked features, you can go back to the development
team and craft a proposal for initial launch functionality (12 18
weeks) and future enhancements. After several iterations with the
core team, there should be agreement on the overall scope and rollout
plan. The focus then shifts to defining detailed functional
requirements and specifications for the initial launch functionality
To the extent that there are other client resources beyond the core to
contribute to the requirements definition process, these people (the
extended team) should be scheduled for interviews or focus groups
(depending on the number of people) to review the initial launch
functionality and to begin fleshing out details. An iteration
workshop should be scheduled in advance for all core team and extended
team members to finalize the functional requirements and
specifications.
The requirements gathering and prototyping activities run in parallel.
The team creates a requirements document and an initial user interface
prototype that reflects the requirements. Throughout the interviews
and workshops, the requirements doc and prototype are continually
updated based on user feedback. By the end of the requirements
gathering, the prototype and functional requirements are developed to
the point that all parties have a common understanding of the to-be
developed functionality. The iterative and visual approach to
requirements definition limits the amount of ambiguity.
The scope definition for the initial product launch is the input for
the functional requirements document. The team creates an initial
version of the requirements to be used to facilitate client
discussion. Along with the written version, the team either creates a
quick UI prototype or references existing applications that
demonstrate the functional requirements. The team defines the initial
requirements and prototype for best integration with the competencies
of the systems integrator.
At each interview, the client is presented with the functional
requirements document and walked through the visual representation of
the requirements. The interviewer gathers feedback from the
presentation and keeps a running list of recommendations for each
feature. When the interview process is complete, each feature has a
set of recommendations and the number of time each recommendation was
made.
Activities Work Aids
In preparation for the iteration workshop, the functional requirements
and prototype are updated to reflect the obvious feedback. All other
recommendations are listed as open items to be resolved during the
iteration workshop. At this point, the scope issue is revisited to
make sure that the functional requirements are reflective of the
initial scope estimates. If the scope is larger than anticipated,
additional features are moved to subsequent development phases. If
this becomes necessary, make the necessary cuts for presentation at
the iteration workshop.
The project sponsor, core team members and all interviewees are
expected to attend the full day iteration workshop. During the
morning session, the updated functional requirements and prototype are
presented. In addition, the team provides justification for making
scoping decisions. This presentation will elicit discussion among the
group and will lead to additional modifications to the requirements.
The facilitator of the session is responsible for driving the group to
consensus and for defending decisions on what is in or out of scope.
At the lunch break, the team quickly updates the prototype and
functional requirements to reflect the modifications from the morning
session. The afternoon is a replay of the morning session with more
pushback on requested changes and greater emphasis on drawing issues
to conclusion. If changes continue to be significant, do another
iteration of the prototype and functional requirements. Continue this
routine until consensus is achieved.
Once consensus is achieved on functional requirements, the team
develops a contract proposal, organizes the implementation team and
presents the proposal to the client sponsor for approval and sign-off.
The final version of the functional requirements is developed into a
proposal that includes cost estimates, project plan and timelines, and
resource estimates. It also includes a high-level plan for the future
enhancement releases.
Activities Work Aids
Once the proposal is complete, it is turned over to the development
team for further scrutiny. The development team reviews all
functionality estimates and begins to develop technical specification
to further validate the proposal. At this point the application
design team is transformed into the implementation team by adding
additional development resources and adjusting the roles of the
business focused resources.
The proposal is presented to the client for approval and signoff. The
sponsor reorganizes the core team with resources to support the
implementation effort. The client business resources from the core
team continue to face-off with internal business resources for overall
project management.
Many solution providers recognize the need for formal up-front
interaction with the customer to gain a common understanding of
functional requirement and to establish a project management
structure. Typically business focused consultants run this up-front
phase, facilitating workshops and conducting interviews with customer
personnel to define requirements. The completed requirements are then
passed from consultant to developer for implementation, and the
business consultants play a continuing role in client and project
management.
Below is a sample of methodologies and approaches that make use of an
application design phase.
Application Design has been and continues to be an important component
of any solution delivery process. The extent to which web service
providers are involved in the up-front requirements definition and
design of an application will lead to a better understanding of and
agreement with the customer. Such understanding and agreement lead to
successful projects.
|
|
