Specifying Requirements for Outsourced Projects

If you’re thinking of outsourcing your software development, you need to approach requirements a bit differently. These tips can help.

Karl Wiegers
Analyst’s corner
Published in
6 min readSep 25, 2020


A global map with the word outsource pointing to North America, Europe, Asia, and other continents.
Image by Jireh Gibson from Pixabay

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.




Karl Wiegers
Analyst’s corner

Author of 14 books, mostly on software. PhD in organic chemistry. Guitars, wine, and military history fill the voids. karlwiegers.com and processimpact.com