Specifying Requirements for Outsourced Projects

Karl Wiegers
Sep 25, 2020 · 6 min read
Image for post
Image for post

Rather than building software systems in-house, many organizations outsource development to contract development companies. They might outsource the work to take advantage of skills they lack in-house, to augment their internal staff, or in an attempt to save money or time. The outsourced development supplier could be located physically nearby, on the other side of the world, or anywhere in between.

The role of a business analyst (BA) is even more important on these projects than on a co-located project. If the team members are all in one location, developers can walk down the hall to ask the BA a question or to demonstrate newly developed functionality. This close collaboration can’t happen in the same way with outsourced development.

Compared to in-house development, outsourced — and particularly offshore — projects face several requirements-related challenges:

  • It’s harder to get developer input on requirements and to pass along user feedback to developers.
  • A formal contractual definition of requirements is necessary, which can lead to contention if differences of interpretation are discovered late in the project.
  • There might be a bigger gap between what the customers ultimately need and the product they get based on the initial requirements, because there are fewer opportunities to adjust the project’s direction along the way.
  • It can take longer to resolve requirements issues because of large time zone differences.
  • Communicating the requirements is more difficult because of language and cultural barriers.
  • Limited written requirements that might be adequate for in-house projects are insufficient for outsourced projects, because users and BAs are not readily available to answer developer questions, clarify ambiguities, and close gaps.

This article suggests some techniques for successful requirements development and management on outsourced projects.

Appropriate Requirements Precision

Outsourcing product development demands high-quality written requirements, because your direct interactions with the development team are likely to be minimal. As shown in Figure 1, you’ll be sending the supplier a request for proposal (RFP), a set of requirements, and product acceptance criteria. Both parties will engage in a review and will reach agreement, perhaps with negotiation and adjustments, before the supplier initiates development. The supplier will deliver the finished software product and supporting documentation.

Image for post
Image for post

Figure 1. Requirements are the cornerstone of an outsourced project.

Poorly defined and managed requirements are a common cause of outsourced project failure. With outsourcing, you won’t have the same opportunities for quick clarifications, decision making, and changes that you enjoy when developers and customers work in close proximity. Particularly with offshore development, expect that the supplier will build exactly what you ask them to build. You will get no more and (hopefully!) no less, sometimes with no questions asked. The supplier likely won’t implement the implicit and assumed requirements you thought were too obvious to record.

As with in-house development, visual requirements models augment functional and nonfunctional requirements for outsourced teams. Models are even more valuable if you’re working across cultures and native languages, as they give developers something to check their interpretations against. Be sure the developers understand the modeling notations you use and interpret your diagrams accurately.

Prototypes can also help clarify expectations for the supplier team. Similarly, the supplier can create prototypes to demonstrate to the acquirer their interpretation of the requirements and how they plan to respond to them. This is a way to create more customer-development interaction points to make course adjustments early in the project rather than late.

Watch out for the ambiguous terms found in Chapter 11 of Software Requirements, 3rd Edition that cause so much confusion. I once read a requirements specification intended for outsourcing that contained the word “support” in many places. The requirements author acknowledged that the contractor who implemented the software wouldn’t know just what “support” meant in each case. A glossary also is valuable when dealing with people who don’t share the tacit knowledge held by those who work in the acquiring company.

Acquirer-Supplier Interactions

Without real-time, face-to-face communication you need other mechanisms to stay on top of what the supplier is doing, so arrange formal touch points between the acquirer and the supplier. Plan time for multiple review cycles of the requirements. Use collaboration tools to facilitate peer reviews with participants in multiple locations.

Incremental development permits early course corrections when a misunderstanding sends the supplier’s developers in the wrong direction. If the supplier raises questions, document them and integrate the answers into the requirements. Use an issue-tracking tool to which both supplier and acquirer teams have access.

Outsourced projects often involve teams with disparate company cultures and attitudes. Some suppliers are so eager to please that they agree to outcomes they can’t deliver. When you bring an error to their attention, they might strive to save face by not fully accepting responsibility for the problems.

Some developers might hesitate to ask for help or clarification, or to say “I don’t understand.” Employ elicitation and facilitation techniques such as reading between the lines for what isn’t said and asking open-ended questions. Establish ground rules with all team members regarding how they should interact when they work together.

Developers whose first language is different than the language in which the requirements are written might not pick up nuances or fully appreciate the implications of certain statements. They might make user interface design choices that you wouldn’t expect. Things as diverse as date formats, systems of measurement, the symbolism of colors, and the order of people’s given and family names vary between countries. The requirements should avoid the use of colloquialisms, jargon, idioms, and references to local culture that could be misconstrued.

Change Management

At the beginning of the project, establish a change control process that all participants can use. Using a common set of web-based tools for handling change requests and tracking open issues is essential. Identify the decision makers for proposed changes and the communication mechanisms you’ll use to keep the right people informed.

The outsourced development contract should specify who will pay for various kinds of changes, such as newly requested functionality or corrections made in the original requirements. The contract should also define the process for incorporating changes into the product.

Acceptance Criteria

Define in advance how you’ll assess whether the contracted product is acceptable. How will you judge whether to make the final payment to the supplier? If the acceptance criteria are not fully satisfied, who’s responsible for making corrections and who pays for them? Include acceptance criteria in the RFP so the supplier knows your expectations up front. Validate the requirements before you pass them to the outsourced team, to help ensure that the delivered product will be on target.

Properly handled, outsourcing development work can be an effective strategy to build your software system. An essential starting point for a successful outsourcing experience is a set of high-quality, complete, and explicitly clear requirements. If the requirements you provide to the supplier are incomplete or misunderstood, failure likely is at least as much your fault as theirs.


This article is adapted from Software Requirements, 3rd Edition by Karl Wiegers and Joy Beatty. If you’re interested in requirements, business analysis, project management, software quality, or consulting, Process Impact provides numerous useful publications, downloads, and other resources. Karl’s latest book is The Thoughtless Design of Everyday Things.

Analyst’s corner

We are passionate about helping businesses do their job better!

Sign up for Top business analysis stories

By Analyst’s corner

A curated collection of recent stories from the Analyst's corner. Never miss an insightful article worth reading! Take a look.

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Karl Wiegers

Written by

Author of 12 books on software, design, management, consulting, and a mystery novel. Guitars, wine, and military history fill the voids. https://karlwiegers.com

Analyst’s corner

All aspects of organisational analysis: business analysis | enterprise architecture | quality

Karl Wiegers

Written by

Author of 12 books on software, design, management, consulting, and a mystery novel. Guitars, wine, and military history fill the voids. https://karlwiegers.com

Analyst’s corner

All aspects of organisational analysis: business analysis | enterprise architecture | quality

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store