Announcement: All software requirements services are now delivered through Better Software UK.

Frequently Asked Questions


What are software requirements?
Are software requirements important?
How long do software requirements take?
What is the difference between functional and non-functional requirements?
What is a software design specification?
What is agile software development?
Aren’t software requirements anti-agile?
What is the difference between outsourcing and offshoring?
When does outsourcing make sense?
Should I offshore my software development?
What are your favourite offshoring locations?


What are software requirements?

Software requirements describe what a software product should do. They represent the needs and wants of product users and broader stakeholder groups and, as such, should be clearly written down and prioritised.

Many formats exist to capture requirements, including use cases, agile user stories, business requirement documents (BRDs), and requirements catalogues. All are valid and have their place, depending on context and environment.

Software requirements are easy to do poorly and notoriously tricky to get right. Business analysts and requirements engineers are responsible for gathering and managing software requirements – it’s an interesting but specialised job role.

Are software requirements important?

Yes! Yes, yes, yes. Because without them, chaos happens. Your developers won’t know what to do, so they get stuck and frustrated, or spend their time day trading instead of working. Others may work it out for themselves, building what they think is needed and making important decisions as they go. Even the most ‘agile’ of developers still need a way to clarify what’s required.

Sadly, the business pays the hidden cost, the very individuals least well-placed to know what’s going wrong. Not having good requirements will result in poor quality software, delivered slowly, often not working as expected, by angry or demotivated developers. Only to be sent back for reworking, once again. Nobody wins, and it doesn’t feel good.

How long do software requirements take?

Assuming a five-person development team within a large enterprise setting, a good rule of thumb is one or two months of requirements gathering and management for every three months of development. However, 2 – 4 weeks of full-time requirements work would happen up front with stakeholders to flesh out the product roadmap and compile an initial backlog, followed by ongoing support to run regular refinement sessions, answer questions from engineers, and handle emergent requirements as they become known. More complex products and bigger development teams require greater coordination; simpler products and smaller teams require less.

What is the difference between functional and non-functional requirements?

Functional requirements describe what the software should do, whereas non-functional requirements describe how it should do it. Non-functional requirements (NFRs) are also known as ‘quality attributes’ because they are more akin to the service standards a user should expect.

Here’s an example. ‘I want to make a payment by credit card’ is a functional requirement; it describes something a user wants to perform to meet a goal. ‘The payment should be secure’ is a quality attribute that explains how it should be performed ie. securely. Further elaboration is possible by specifying implementation-specific details, ie. ‘256-bit encryption for card details’ and ‘compliance to PCI-DSS’, an industry standard for card payments.

Non-functional requirements often apply to entire software products or whole sub-systems, unlike functional requirements that describe individual pieces of functionality. ‘I want to make a payment by PayPal’ is a second payment requirement, but the expectation of doing so securely still applies. For this reason, NFRs are often specified at the product level and then referenced within individual software requirements or inferred as generally applicable. ‘Cross-cutting concern’ is a commonly used term for this.

What is a software design specification?

Software requirements describe what the software should do, whilst a software design specification defines precisely how it will be done. Software requirements avoid specifying solutions and implementation details where possible, allowing the requirements gathering to proceed without undue concern for solutions too early in the process. However, once the requirements have been well defined and agreed upon, then producing a software design specification commences.

Several implementations may be suitable, but the design specification clarifies which one to use. Developers won’t need a software design specification for trivial requirements, simply extending the existing codebase in a familiar pattern and working out the minor details themselves. However, more substantial changes, new products, and large or remote development teams will do.

A dedicated technical architect or entire architecture function will be responsible for producing the software design specification, which sometimes consists of several architectural blueprints, solution designs, low-level details, and implementation guidance. Deciding when a specification is required and what level of detail is appropriate relies on good judgment.

What is agile software development?

Agile development builds software in small, frequent increments. Instead of waiting six or more months for a finished product, agile typically ships a new version every two to four weeks. Users come to expect new and improved features, frequently shipped, so it’s not hard to see the popularity of agile software development.

Short development cycles and frequent releases bring challenges that require careful management. The most important or valuable features are identified and worked on in each increment, and very high testing rigour must be present to ensure the software works as intended and regressions don’t go unnoticed.

Software requirements and software designs are essential for good agile development. However, spending time on gathering requirements is limited to the minimum required for each increment, avoiding wasted effort and future rework. Agile teams often favour user stories, a particular format of software requirement, for communicating what the software should do, and the business analyst should have these prepared beforehand.

Aren’t software requirements anti-agile?

Software requirements and solution designs are even more critical for good agile software development, not less. The confusion lies in the idea of fully ‘signed-off’ requirements or ‘big design up-front’ (BDUF), neither of which an agile team should aspire to. Instead, just enough detail at the last possible moment is the right approach, along with an overarching high-level design or product roadmap in place as the North Star for the team members to pull towards.

Software requirements in the form of agile user stories are helpful, and having these refined ahead of developers picking them up prevents their work from becoming unexpectedly blocked. The only time I’ve seen not bothering with user stories work well is when a single developer sits next to the product owner, both happy to have frequent conversations throughout the day, which is perfectly fine if that’s your situation.

What is the difference between outsourcing and offshoring?

Outsourcing is when you contract your software development to a 3rd party supplier, whereas offshoring is when you decide to locate your software developers in a different country. In reality, though, it’s a bit more nuanced. Outsourcing typically occurs when you contract most or all of your development to a 3rd party strategic partner, deciding they can develop software better than your own company or deciding that you don’t want to be in the software industry yourself. The cost of engaging a strategic supplier should be more than compensated by acquiring access to their expertise and avoiding the opportunity cost of trying to develop that yourself. The outsourcer may, in fact, offshore their own development, in which case you have actually outsourced and offshored your software development. You may not even know this has happened.

When does outsourcing make sense?

Anyone can hire a developer to build some software, but good software development is complex and costly, something many businesses are better off not doing themselves. Outsourcing your technical decisions and software development makes sense when the specialist skills you need are missing internally, particularly if you need them quickly or the nature of your business is not technical. Many companies are not geared up to hire developers and build their own software. You can, however, build strategic and competitive advantage by having your outsourced provider develop excellent software on your behalf, avoiding the technical risks and expertise required to do it yourself. Strategic partnerships are well placed to advise your business in technical matters, whilst agency outsourcing lets you scale development capability. Long-lasting, mutually beneficial relationships can occur in both forms of outsourcing.

Should I offshore my software development?

Certainly, if you want to support developing and emerging countries as part of your social and corporate responsibility. Choosing a location with lower living standards and a favourable exchange rate can have a material impact on individuals, families and potentially whole communities. Do your due diligence and select a supplier who shares your values and will pass on the financial benefits. Another good reason is when your local market can’t provide you with the skills you require, looking beyond the local talent pool makes a lot of sense in this case.

Most offshoring is driven by budget holders seeking to reduce development costs; however, hiring offshore developers comes with hidden costs that can overshadow the end result. Firstly, know that good quality developers in a similar time zone, and who speak the same language, will usually cost the same or similar to what you already pay. So, the economic case isn’t made like this.

Lower development costs need compromises to happen. Whether it’s far away time zones, junior boot camp developers, language differences or cultural miss matches – these result in attractively low rates. Your economic case for offshoring revolves around being confident in delivering on par with a locally sourced team, despite these compromises. Otherwise, you face hiring local staff to manage offshore staff, tolerating poor quality and longer release cycles whilst feeling stressed and for a higher cost than expected.

I certainly don’t advocate avoiding offshore development because when it works, it works well. Instead, be adequately informed in your decision-making and realistic about what to expect.

What are your favourite offshoring locations?

Hmm, tricky question, but if I had to choose, it would be Eastern Europe, particularly Poland or Romania, because the tech calibre is very high, there is a good grasp of the English language, and working hours are similar to the UK, but most importantly, a culture of excellent craftsmanship. However, that also means the cost of Eastern European developers is no longer much cheaper than the local UK market, although I would still prefer to hire remotely.

If you are looking for more significant cost savings (nb. doesn’t necessarily happen), then I would look to Southeast Asia, places like Vietnam and the Philippines that have decent emerging offshore software development industries. Favourable currency rates and lower costs should compensate for increased difficulties compared to their Eastern European counterparts. I’ve worked with many Indian offshore development firms, however they would not be my first choice.


Frank Ray Consulting. Software requirements for agile development teams, particularly remote, outsourced and offshore development teams working in financial services.

Get in touch if you need our help

Woking, Surrey, GU22, United Kingdom