- 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 solution design?
- What is agile software development?
- Are software requirements still 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, 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; an interesting but specialised job role.
Are software requirements important?
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 of not having good requirements, the very individuals least well-placed to know what’s going wrong. The result is poor quality software, delivered slowly, not working as expected, by frustrated or demotivated developers. Only to be sent back for reworking. Nobody wins, and it doesn’t feel good.
How long do software requirements take?
A good rule of thumb is that for every 3 to 5 developers, you need one full-time business analyst to take care of the requirements. ie. for every month of software development, the software requirements take a month of effort to prepare, which is a 20% overhead.
The software requirements work needs to commence ahead of the development, but just enough to get the developers started. Avoid the temptation to define all the requirements in advance. Instead, most of the software requirements should be worked on in parallel with software development, incorporating learnings and emergent requirements as they become known.
The 20% overhead rule of thumb is completely unscientific, but it has held up as a heuristic pretty well over the years. Mileage will vary; 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; non-functional requirements, often abbreviated to NFRs, describe how it should do it. Non-functional requirements are also known as ‘quality attributes’ because they relate to the standard of service a user should expect from the software.
Here’s an example to better illustrate the differences. ‘I want to make a payment by credit card’ is a functional requirement; it describes a user action that is part of achieving a bigger goal. ‘The payment should be secure’ is a quality attribute that explains how the payment should be performed ie. securely. Further elaboration is possible by specifying implementation-specific details, eg. ‘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 functionality. ‘I want to make a payment by PayPal’ is a second payment requirement, but the expectation of doing it 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 to describe this.
What is a solution design?
Software requirements describe what the software should do; a solution design defines precisely how it will be done. Software requirements avoid specifying solutions and implementation details where possible, allowing the requirements to proceed without undue concern for solution options too early in the process. However, once the software requirements have been defined and agreed upon with the stakeholders, then a solution design can be produced.
Developers won’t need a solution design for trivial requirements because they can simply extend the existing codebase in a familiar pattern and work out the minor details themselves. Existing development standards and design patterns are leveraged. Slightly more complicated changes can still be delegated to the technical team, often overseen by a technical lead or performed in collaboration with another developer. Writing documentation and noting key architectural decisions is a pragmatic way to proceed.
Starting a new software project, substantial changes to an existing application and complex functionality will require a more detailed consideration of the software design. Usually, a dedicated technical architect or an entire architecture function will be responsible for this. Several implementations may be possible, but the solution design clarifies which one to use. Large development projects, junior developers and remote development teams especially value having detailed designs to follow.
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 development typically ships a new version every two to four weeks. The most important or valuable features are identified and worked on in each increment, and users come to expect new and improved features on a regular basis. It’s not hard to see the popularity of agile software development.
However, short development cycles and frequent releases bring challenges that require careful management. Better software requirements and solution designs are essential, along with very high testing rigour to ensure software works as intended and without unnoticed regressions.
Unlike waterfall approaches, requirements gathering 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. Stories should be prepared in advance of each increment commencing.
Are software requirements still agile?
Software requirements and solution designs are even more critical for good agile software development, not less. The confusion about this comes from the idea that all requirements and design should be done up front and without the involvement of the technical team, neither of which an agile team should aspire to. Instead, just enough detail at the last possible moment is the right approach, supported by a product roadmap and overarching high-level design to guide the team in their daily decision-making.
Better software requirements in the form of agile user stories are incredibly valuable, and having these prepared ahead of developers picking them up prevents their work from becoming unexpectedly blocked. Not bothering with user stories only works when you have a well-rounded developer physically sitting next to the product owner, both happy to have conversations throughout the day as the work progresses; an excellent arrangement if that’s your situation.
What is the difference between outsourcing and offshoring?
Outsourcing is when you rely on a 3rd party supplier to develop your software, whereas offshoring is when you 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 market-leading software on your behalf, avoiding the technical risks and expertise required to do so yourself. Strategic partnerships are well placed to advise your business in product decisions and 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 consciously support developing countries as part of your corporate and social responsibility. Choosing an offshore location with lower living standards and a favourable exchange rate can have a material impact on individuals, families and potentially whole communities.
However, most offshoring is driven by budget holders seeking to reduce development costs, but hiring offshore developers is a risky business with hidden costs that often overshadow the end result. Firstly, know that good-quality developers in a similar time zone and who speak the same language as you will usually cost the same or similar to what your local market already demands. 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, cultural challenges or political instability – 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, all for a higher cost than expected.
Offshore development can work really well. Just be adequately informed in your decision-making and realistic about what to expect.
What are your favourite offshoring locations?
We favour Eastern Europe, particularly Poland or Romania. The tech calibre is very high, there is a good grasp of English, and working hours are similar to the UK. Perhaps most importantly, Eastern Europe seems to have a culture of excellent software 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 given the choice.
If you are looking for more significant cost savings, 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 more than compensate for increased challenges compared to their Eastern European counterparts. Of course, there are no guarantees, and further afield comes with higher risks of things going wrong. Better software requirements can help. There are many Indian offshore development firms; however, they would not be my first choice.