- What are software requirements?
- Are software requirements important?
- How can I get better software requirements?
- 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?
- When does agile software development work best?
- What limits the success of agile software development?
- Are software requirements still agile?
- Should I tailor my agile process?
- What should I consider when tailoring my agile process?
- What’s the difference between tailoring an agile framework and changing it?
- Should I change or adapt Scrum?
- What should I do when my agile team isn’t doing very well?
- How are user interfaces produced with agile?
- Can I use high-fidelity wireframes with 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 can I get better software requirements?
Time with users is probably the single most significant factor in gathering good software requirements. Adequate time to develop a relationship, build trust, listen intently, ask questions and hear feedback. Adequate time to see how users work, understand the daily pressures of the environment they work in, and other tools they use. Adequate time to understand the competitive landscape, the needs of the business and the opportunities to do better or differently. With a keen eye and an inquiring mind, you start to understand the real needs of the users and stakeholders, and with luck, suggest features they may not even know to ask for. This is the point where magic starts to happen. Software requirements follow, a written hypothesis of user needs to build and then test.
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.
When does agile software development work best?
Agile works best in situations with a high degree of uncertainty. A good example is trying to enter a highly competitive, saturated consumer market where product differentiation and uniqueness are key. You may have a well-researched hypothesis, but determining every feature six months in advance is an endeavour fraught with danger. You simply can’t know how your proposition will fare in the marketplace.
Agile has you build the most valuable or risky things first, and only to the extent required to test the concept for real. Don’t code for six months, if you can code for two and release to some actual users. Ask them what they think, check if they use it, decide if you should continue, make necessary adjustments, fine-tune the roadmap. Better yet, ship new versions even more frequently if possible, say every 2 – 4 weeks, increasing the rate of user feedback and reducing the risk of getting it wrong.
What limits the success of agile software development?
There are numerous reasons for this, but a command and control approach is the most significant limiting factor in our experience. Organisations are fundamentally structured ‘top-down’, with planning and budgets allocated upfront, in advance. Managers need to explain what they are building, often in detail, before funding is released. Test and learn approaches get squashed as agile becomes nothing more than a waterfall delivery sliced into two-week intervals. User feedback contrary to upfront planning assumptions, is ignored or deferred, so the 12-month plan remains on track.
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.
Should I tailor my agile process?
Yes, because software requirements are only as good as the process they are used in. A well-functioning agile process is the foundation for this, but getting it right involves rolling up your sleeves and really understanding the specifics of your team’s software development process and the organisational context they work in.
Defining the right requirements, at the right time, to the right level of detail, for the development team you have is what’s required, and tailoring your choice of agile framework is how you discover the winning combination for your team. Make small, incremental changes and observe the result over time. Adjust as necessary.
What should I consider when tailoring my agile process?
Here are a few suggestions to get you started. User stories should focus on what the software needs to do, rather than how it should be done (leave that for the developers to decide). Acceptance criteria usually makes up 80% of a story’s content. A developer and tester should review each user story, and only once both are satisfied, should the story be considered as ready for development. Decide if stories must be refined ahead of the current sprint, or if they can be picked up and refined at any time. Avoid writing stories too far in advance and deliberately keep the backlog small.
What’s the difference between tailoring an agile framework and changing it?
Tailoring is making changes within the rules or guardrails of the agile framework you are using, ensuring the framework integrity remains intact. More frequent refinement sessions, changing the sprint duration, and adopting a new estimation approach are valid examples of tailoring that could be performed within Scrum.
Choosing to deliberately ignore rules or guardrails or substantially modify the practices required by an agile framework is tantamount to changing it ie. creating something new. Working without timeboxed increment, not holding planning sessions, and not agreeing on a sprint goal are changes that would render a Scrum process no longer ‘Scrum’ (nb. sometimes referred to as a ‘Definitely Not Scrum’ framework).
Changing an agile framework isn’t necessarily bad, but it does introduce a divergence in thinking and practices. For established and well-functioning teams, this is likely a sign of maturity. However, many (less experienced, less capable) teams would do better to examine their motivations for doing so more closely and work to improve within their agile framework of choice. Having an experienced agile coach/external facilitator on hand to help the team would be beneficial.
Should I change or adapt Scrum?
Honestly, I wouldn’t recommend it. The prescriptive nature of Scrum provides an excellent framework for most teams to work within. There are quite a lot of useful guardrails built in whilst retaining the flexibility to experiment. You should be able to go a very long way on just ‘plain old vanilla Scrum. Teams that need to scale in size should consider a scaled framework, instead of bespoking Scrum. I make an exception for teams who have fully mastered Scrum, and are now feeling their potential is being constrained by the framework itself. But I haven’t come across many of those in my career.
What should I do when my agile team isn’t doing very well?
The benefit of Scrum is that it’s quite prescriptive, and underperforming agile teams do well returning to first principles. A schedule of reoccurring ceremonies is rolled out, and anything bespoke that doesn’t absolutely need to remain is forsaken, favouring a textbook implementation of Scrum for a while.
User stories are regressed to something not much more than implementation specifications; and junior, inexperienced, or non-English speaking developers benefit from more prescriptive guidance and direction. It’s a temporary measure and I have no shame in doing this, knowing the team should settle into a more relaxed way of working in time.
How are user interfaces produced with agile?
Typically, the product backlog is populated with user stories and developers build them as best they can, including the user interface. Often, wireframes and sketches may accompany the story, more as a guide than anything else. Sometimes an actual user (‘onsite customer’ in Extreme Programming terminology) is dropped into the team, being the individual best placed to explain the features and collaborate with developers as the software takes shape, including the user interface design. Ideally, the developers will use standard UI component libraries and frameworks to accelerate frontend development, ensuring consistency of look and feel. A library of standard UI layouts and interaction patterns, specific to the product, should be developed over time.
Can I use high-fidelity wireframes with agile?
A UX-led approach to agile is certainly possible, even desirable, given the grey screens and comboboxes some developers typically favour. However, a few modifications to your textbook agile setup are required, some of which may surprise you.
Product/UX designers become the ‘voice of the customer’, responsible for designing entire end-to-end user experiences. Periodic user research and focus group sessions inform the product roadmap and which features to design next. Wireframes and high-fidelity UX collateral become the defacto requirements developers work from, and your typical ‘as a, I want, so that’ user story no longer appears in the development backlog.
The product design process should include the technical team, at least at key points, to assess the backend capabilities required for each journey. Finished designs are ‘cut up’ into frontend and backend stories and added to the backlog for developers to refine and build accordingly. Greater coordination of development work is required to ensure backend systems are ready for integration with frontend screens at the right time. Direct user feedback follows each new product launch, often infrequently, every three to six months.
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.