As consultants, we live and die by requirements, use cases, and user stories. The logic for their use is as follows:
- We perform professional services for our clients, which usually involves some type of software development. The end result of this relationship is that the client is happy and we are paid.
- In order to secure both happiness and payment, our clients wants to see results from an acceptance test to verify that the software is functioning correctly.
- The acceptance test is based upon use cases and requirements identified in a requirements gathering phase.
- Missing or poor requirements leads to incorrect software design and implementation, an absent or spotty acceptance test, and ultimately to unhappy clients and potentially lack of payment.
Since unhappy clients and lack of payment are to be avoided like the plague, it is in everybody’s best interests to spend time refining requirements and use cases. The client can sharpen and clarify their vision, the development team can create a design that satisfies the requirements, and the test team can base their test cases directly upon the use cases.
So why do so many people resist defining requirements? There are as many reasons as there are stakeholders in a project. Some people worry about defining project scope too early. Some people have not been trained with requirements gathering techniques and feel uncomfortable using them. Some people think that requirements gathering (and possibly project planning) are extraneous activities that take away from the real work to be done.
Regardless of the specific reasons for resistance, the fact remains that the resistance is real, and the amount of that resistance will vary based upon the composition of a project team. Our job as consultants, and possibly your job as well in the role of requirements gatherer, is to gently overcome that resistance and lead the team towards consensus regarding the requirements and use cases.
There are many good books that have been written regarding requirements and use cases. Software Requirements by Karl Wiegers is a favorite for requirements gathering. For use cases, three books stand out in our eyes: Use Cases: Requirements in Context by Daryl Kulak and Eamonn Guiney, Writing Effective Use Cases by Alistair Cockburn, and Advanced Use Case Modeling: Software Systems by Frank Armour and Granville Miller. All of these books contain excellent treatments of the subject.
Some readers may have noticed that we listed three use case books and one requirements book. The reason for that is simple: it is easier to engage a project team by employing use cases to directly describe system behavior than it is to break down that system behavior into arbitrarily-scoped functional requirements. The marketing component of the project team is happier, as their vision has been directly translated into use cases. The testing component of the project team is happier, as the basis for the bulk of their test cases has been outlined in the set of use cases. Depending upon the design methodology chosen for the project, the development team may or may not be happier, as there is some translation that must be undertaken to map use cases and functional requirements to an object-oriented design.
Individual requirements still have their place, because not all requirements can be captured within the structure of a use case. Specifically, nonfunctional requirements and design constraints, such as internationalization, choice of programming language, supported communication protocols, and the like, must still be captured. Typically these types of requirements and constraints are “well-known”, and small in the scope of the requirements gathering effort (although they may not be small in the scope of the implementation effort).
When you are planning your next project, we’d recommend that you consider whether your team’s time and energy is better spent breaking system behavior into arbitrarily-scoped functional requirements, or whether it is more efficient to simply dive right into use cases and directly describe how the system operates. We’ve found use cases to be the easiest way to engage a team, and using this approach, our consultants can provide value to our clients on day one.