Industry gurus Steve McConnell and Karl Wiegers have articulated two statistics that are vitally important:
- Requirements defects in software projects account for approximately 50% of product defects.
- The percentage of the re-work on software projects due to requirements defects is greater than 50%.
Given that requirements have a major impact on project schedules and the ultimate value provided to the customer as a result of using the software, it is in everyone’s best interest to get the requirements right. This requires discipline and thought from both the business users and the software development team.
Software development is a meeting of the minds. The business must provide the right resources – those who understand what the business needs and is capable of articulating those needs – and the software team must make every effort to understand what the business needs. And this means more than just accepting a bullet list of requirements. The requirements should be explored.
Software developers confuses the situation through the use of metaphors that lead to misunderstandings. We “design” and “construct” software, analogous to building a house. Unfortunately, software development is not just like building a house. A house is physical and has specific characteristics. When you want a 3-bedroom house with 2 bathrooms, you can easily lay the house out on a blueprint. Software doesn’t blueprint that easily.
Unlike a house, software behaves – unless you are Bill Gates, who expects paintings to change to his personal preference when he walks into a room. When you walk into a room in your house, you don’t expect anything to happen, do you? (Except for those times when you are interacting with that special someone, but you are expecting them to react, not the house…)
When users interact with software, they expect certain things to happen. “When I select this item from the list, I expect a certain set of choices with other items on the screen,” or “When I click Submit, I expect to get a quote back for my auto insurance.”
Software has rules that govern what can and can’t be done, as well as formulas and algorithms. Software chooses to take a user down one path or another based on the rules, formulas, and calculations that it performs.
This means that requirements need to be more than simple statements about a need. Many times, the customer (users) – those who don’t understand software development because they aren’t software developers – will state what they think that they need. Too often that need is centered around an immediate need, and if taken literally without examining the true goals of the user, you will design and a narrowly-focused feature that will need work and ajustment later.
Since users don’t understand what it takes to translate business operations into working code, those on the software side need to engage the customer in an appropriate dialog to understand more fully what the users are trying to accomplish. This conversation with the customer will take more time, but if you approach it from the standpoint of understanding what the customer truly needs the software to do, and engage them in a discussion about how they expect to interact with the software, the software team will gain a greater insight to what needs to be built and what will be deemed both correct and successful from the customer’s point of view.
Most users are not good at abstraction. Their perspective of software is geared towards what they see – the user interface. Use their perspective and language when discussing how software will behave by using screen mock-ups (paper prototypes or functional prototypes). But get at the underlying behavior the software needs to perform.
To do this successfully, be like a young child that is going through that “‘cause why” stage. Ask why until it hurts! Keep in mind that understanding the true business goals can help craft a better solution. A meeting of the minds also means that those on the technology side can offer up solutions to business problems that might not have occurred to the business.
For example, the business may approach a software team with the concept of automatically inputting customer data received via e-mail. The software team may take a look and determine that it is faster and easier to import the data through an already established collection point elsewhere, and that the e-mailing of this data was done to accommodate a gap in the existing software that can now be addressed.
We've also used the technique of developing personas. A persona is a fictitious representation of one or more uses of the software, but a detailed one that provides a solid, working example of an example user. A persona helps the development team keep the business goals and users in mind, and can be a great way to remind developers how the design and development of the software relates back to those that they are building the software for – without constantly engaging them in conversations. Granted, there still needs to be on on-going dialog, but a good set of personas can help limit some of need for input by the business side of the house – a win for everyone.
We’ve adopted the Agile development methodology, which captures requirements in the form of user stories. These are a simple, but effective means of capturing what users want out of the software. A basic template for writing user stories is as follows:
As a [user role], I can [software feature] so that [business reason].
I won’t elaborate on writing requirements or user stories here, but I will provide some references.
A couple of links to writing user stories:
The Easy Way to Writing Good User Stories
ExtremePlanner: Agile Project Management for Distributed Software Teams
Two books that I highly recommend:
User Stories Applied: For Agile Software Development by Mike Cohn
Software Requirements, Second Edition by Karl Wiegers