ArsDigita Archives

Requirements Gathering for Application Design

by Tom Wunderlich (

ArsDigita : ArsDigita Systems Journal : One article

Requirements Gathering for Application Design

Requirements Gathering for Application Design


A solution delivery team and a client agree to develop a software application. Together they agree on scope, specifications, timeline, and price. The delivery team begins coding against the specifications and at the initial milestone date meets with the client to review functionality. The client’s reaction upon seeing the functionality - "This is not what we were expecting!"

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 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.

Customer Driven Requirements

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.

Figure 1: Customer Lifecycle Methodology

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.

Figure 2: Resource Blend For Application Design

The application design phase can result in several benefits:

  • Limited Scope Creep – client feedback should be limited to minor enhancement requests and should not require significant rewriting of existing code
  • Improved Morale – developers will be able to sustain more reasonable work schedules and avoid burn out
  • More Accurate Pricing/Timelines/Staffing – a better understanding and allocation of requirements will make these projections more reliable
  • Better Conflict Resolution – by working closely with the client to define requirements, a natural reporting structure is created, making it easier to resolve issues during the implementation and grow phases
  • Reduced Development Iteration – feedback and iteration with the client will always be part of the development process, but well-defined functional requirements will limit the degree to which iteration is needed
  • Better Alignment With Fortune 500 – larger organizations typically require help in organizing application requirements and building consensus with their constituencies

The Application Design Phase

Figure 3: High-level Application Design Process Flow

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.

Step #1: Establish Client Contacts

Figure 4: Application Design: Establish Client Contacts

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.

Meet With Project Sponsors

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.


  • Define formal reporting structure with client

  • Establish high-level scope parameters

  • Staff client core-team for functional requirements definition

  • Develop plan for requirements gathering

Work Aids

  • Sample client resource profile

  • Matrix for ranking features

  • Framework for evaluating customer readiness

  • Template for requirements gathering plan

Establish Core Team

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.

Define Project Scope

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

Create Plan For Requirements

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.

Step #2: Gather Business Requirements/Prototype Presentation Layer

Figure 5: Application Design: Functional Requirements Definition

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.

Conduct Interviews

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.


  • Develop straw model functional requirements

  • Develop interview guide and prototype

  • Hold one-on-one interviews with client personnel for requirements feedback

  • Update functional requirements and prototype

  • Hold iterative design session

  • Reach consensus on functionality

Work Aids

  • Sample interview guides

  • Sample functional specifications and prototypes

  • Example Workshop Template

  • Storyboard for prototype

Prepare Findings

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.

Hold Iteration Workshop/Achieve Requirements Consensus

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.

Step #3: Client Sign-off on Requirements

Figure 6: Application Design: Requirements Sign-off

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.

Create Proposal

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.


  • Develop proposal and project plan

  • Transition application design team into implementation team

  • Achieve Client Sign-off

  • Adjust client core team to development focus

Work Aids

  • Sample proposal

  • Sample core team structure for the development phase

Development Team Sanity Check

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.

Sponsor Sign-off

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.

Other Approaches to Application Design

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.

  • has a methodology designed for healthcare solutions. Their approach calls for a two day envisioning and scoping workshop to define functional requirements. The workshop results are reviewed and iterated with the customer subject matter experts and the final output is a detailed project work plan and scope statement. The Xcare engagement manager and the customer sponsor negotiate any future modifications to the initial scope and the project plan is updated accordingly.
  • The Rare Medium approach covers the entire lifecycle from strategy through launch and refinement. The functional specification definition occurs across to sequential steps, exploration and prototyping. During exploration, the customer is directly engaged to clarify, define and validated business objectives. The output of the exploration phase is a high level statement of work that represents Rare Medium’s understanding of customer requirements based on limited analysis. The SOW becomes the input for the Prototyping phase. During this phase, content maps, project specifications, storyboards and prototypes are used with the customer to clarify functional requirements. The resulting specifications become the input for the development process.
  • Broadvision’s methodology contains Definition and Design phases for building functional specifications. The definition phase includes multi-day sessions with BroadVision consultants to translate customer requirements in an implementation plan. The sessions include heavy facilitation and scenario storyboarding. The requirements from these session become inputs to the Design phase where more detailed functional specifications are created that become the inputs to development.


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.