- What are software requirements?
- Are software requirements important?
- When do I need better software requirements?
- How can I get better software requirements?
- How can we improve the quality of our software?
- How long do software requirements take?
- What is the difference between functional and non-functional requirements?
- What is a solution design?
- Who produces a solution design?
- What is agile software development?
- What are agile user stories?
- 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?
- What do you think of Scrum?
- Should I change or adapt Scrum?
- What are signs of an underperforming development team?
- What should I do when my agile team isn’t doing very well?
- How do I manage my developers?
- 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?
- Is it ethical to offshore software development?
- How should I manage our outsourced development project?
- What are the benefits of offshore development?
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.
When do I need better software requirements?
You need software requirements when developers don’t speak directly to end users. The further removed the developers, the greater the need for requirements, particularly for remote and offshore development. Requirements bridge what is needed and the people doing the work. Developers struggle to navigate complicated domains, large enterprises and politically oriented environments, further necessitating the need for software requirements.
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 can we improve the quality of our software?
If you do only one thing, then make sure you refine your software requirements/user stories before the developers pick them up. Have the product owner, a developer, and a tester discuss each story together, ensuring they are well understood. Review acceptance criteria and other things like business rules. Only well-defined stories will go through to development, whilst incomplete stories are held back until ready. Stories requiring third-party dependencies will also be held back until these are in place. Agreeing on what makes a ‘ready’ story is helpful, too; many examples exist that you can modify for your own purposes. Struggling to get enough stories ready for development sometimes happens, a likely indication that upstream activities such as user research, product planning, and software requirements require more effort.
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.
Who produces a solution design?
Simple changes to an existing codebase don’t require a solution design because developers can extend it in a familiar pattern and work out the minor details themselves. 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 in collaboration with another developer. Writing documentation and noting key architectural decisions is a pragmatic way to proceed.
New software projects, substantial changes to an existing application and complex functionality will require a more detailed consideration of the software design. A dedicated technical architect or an entire architecture function will usually be responsible for this. Several implementations may be possible, but the solution design clarifies which one to use. Large development projects, inexperienced developers and offshore development teams 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.
What are agile user stories?
User stories describe an action a user wishes to perform in order to achieve a goal. They are single sentences written in a prescribed format, usually ‘As a I want to so that ’. They are usually accompanied by acceptance criteria clearly outlining everything that needs to happen.
User stories are a type of software requirement, but often mistakenly written to be ‘mini-specifications’. Instead, they should remain high-level statements so developers are encouraged to discuss the lower-level details. Collaboration throughout development is the goal. User stories are the primary way to capture requirements in agile teams and they probably originated from Extreme Programming, if you want to read more about them.
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.
What do you think of Scrum?
Scrum is an excellent way to build software, and I’ve had many good experiences with it. It’s fairly prescriptive, fosters good planning, promotes transparent communication and sustainable development practices, and requires whole team inspection points for improvement. That’s the kind of Scrum I know and I’m familiar with.
Unfortunately, it doesn’t take much for Scrum to become a developer’s worst nightmare, eg. micromanagement, feature factory development, loss of creativity, unsustainable sprinting, and surface-level ceremonies. An excellent Scrum Master or Agile Coach can foster the right conditions for true agile working and protect your development team from experiences like these.
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 are signs of an underperforming development team?
Most signs are pretty evident as an impartial observer. High defect rates, increasing support tickets, feature requests, high developer turnover, low morale, sickness and absence, and interpersonal conflict are good examples. However, development teams can also struggle through no fault of their own eg. absence of product vision, missing requirements, poor management, insufficient resourcing, lack of technical guidance. It’s important to accurately diagnose the problem as the real cause might not be obvious.
What should I do when my agile team isn’t doing very well?
Underperforming agile teams do well returning to first principles, and Scrum’s benefit is that it’s quite prescriptive. Roll out a schedule of reoccurring ceremonies and forsake anything bespoke that doesn’t absolutely need to remain. Favour textbook Scrum for a while. Regress user stories to something not much more than implementation specifications as junior, inexperienced, or non-English speaking developers benefit from prescriptive guidance and direction. There’s no shame in doing this as a temporary measure and the team should settle into a more relaxed way of working in time.
How do I manage my developers?
I assume you mean keeping track of your software development. If so, focus more on your process and tooling than on individuals. Clear structure, roles and responsibilities, and open communication are the starting points. Whole-team planning, well-defined requirements, regular collaboration, and things like burndown charts will bring the transparency you seek. A well-functioning development team will more than makeup for differences in individual performance. It will also avoid the temptation to micromanage your staff.
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.
Is it ethical to offshore software development?
International trade is here to stay, and that applies to services and physical goods. Access to global talent and lower costs are compelling reasons to offshore, but remote workers may not enjoy the same legal rights and working conditions afforded to local staff. Don’t propagate basic human rights violations, knowingly or by looking the other way.
Be a good global citizen and do your due diligence by considering things like fair wages, employment rights and good working conditions. Visit the offshore supplier and speak directly to their staff in person. Western buyers of offshore development services are in a powerful position to influence their suppliers for the good.
How should I manage our outsourced development project?
You almost certainly want to avoid fixed scope, fixed price arrangements which outsourced suppliers routinely offer when bidding for work. Software is never a known quantity, so they’ll either charge you for every scope change and/or adjust quality to compensate. Sometimes, a ‘5 developers for the price of 4’ arrangement is thrown in as a sweetener, another false economy to avoid (according to The Mythical Man-Month). Instead, see your outsourced development team as a strategic partner and foster collaborative working. Adopting a fixed-cost, variable-scope approach to software development will significantly encourage this.
What are the benefits of offshore development?
Access to a global talent pool and lower costs are oft cited, but I’d like to nominate another, perhaps surprising, benefit. Good remote development demands diligence beyond what typically happens in a local team.
Better planning, coordination of work, and ongoing communication are all necessary for offshore development teams. Well-defined user stories, frequent backlog refinement sessions, and clear definitions of ‘ready’ and’ done’ are also helpful.