I was at the Agile Conference 2009 recently and heard an interesting talk about validating requirements. The speaker talked a lot about differences between validating requirements in waterfall and agile. She found that validation of requirements with her agile partners was done early and often unlike waterfall and primarily done through conversations with customers. While conversations can be very quick, relying solely on conversations can be problematic as you can easily misinterpret what is said or forget an important point. I’ve listed below several different practices for validating requirements and some pros and cons of each. Ultimately, I think it’s important to use as many of these practices as possible. They will help capture those high quality requirements that ensure delivery of the right product to customers.
1) Conduct conversations/face to face meetings – conversations can be great for quickly uncovering incomplete and inaccurate requirements. However, there are several things that you have to do to make sure conversations are effective:
Participants : you have to make sure the right people are taking part in the conversation. You need to have a representative from all your stakeholder groups: testers, developers, architects, customers. Conversations can be very challenging for geographically distributed teams.
Capturing feedback: Someone needs to very meticulously capture the main points of the conversation: capture defects, missing requirements, etc… This is probably the greatest potential weakness in conducting conversations.
Communicating feedback to all stakeholders: It’s unlikely everyone will be able to participate in the conversations but they still need to know the results and to be able to provide their own feedback.
Capturing post-conversation feedback – What happens after the initial conversation? You need a way to capture feedback after the initial meeting has occurred. Sometimes my best ideas occur when I’m out walking the dog and I’m thinking about what happened during a meeting.
2) Provide written feedback from inspections of requirement documents – I admit it. I like things written down. E-mail or logs from instant messaging, for example. I can’t tell you how often I go back to chat histories or my email to review the details of what someone said. So much is often lost through conversations even with someone taking notes. Things can be misinterpreted. Having people review a document and then respond to it in written format avoids that. It may not be as quick as a meeting or conversation. And you run the risk of people not participating, but when they do, it can be very effective.
3) Include customers – I’m often surprised at how few people really talk with end-users to validate requirements. No matter how well you think your product manager or architect or sales people know the customers, they always have a slightly different perspective. Just watch a requirements validation meeting when customers are present. You’ll be amazed at the difference. Often the organization doesn’t want to include customers for fear they will divulge confidential information. But with legal agreements it’s not a problem. IBM Rational has both extensive beta programs and design partner programs. The feedback we’ve gotten through these programs greatly enhances the solutions we produce. I can’t imagine not having our customers involved from the beginning. We’d certainly have a lot of false starts.
5) Validate all types of requirement artifacts such as documents, use cases, sketches, storyboards, business process diagrams – I think we also have to have different ways of validating requirements depending on the artifact type. In Rational Requirements Composer, Rational’s collaborative, jazz-based, requirements definition and management solution, different user types have their choice of defining requirement artifacts through rich text, user stories, use cases, business progress diagrams, and sketches and storyboards. You would most likely use different techniques to validate rich text documents vs. use case diagrams, for example. The really good thing about Composer, though, is that with a central repository, a project dashboard, and collaborative platform, both general and very granular feedback can be provided by stakeholders – including external customers if they have been given access.
6) Hold facilitated use case workshops – Use case workshops can be incredibly effective if you have the right participants and people are fully engaged. Many times I’ve seen major requirement errors uncovered in these workshops, often found by a tester who was present and thinking about how they were going to develop test cases.
7) Developing conceptual test cases which are independent of implementation – Testers can start to write conceptual test cases as requirements are defined. Just as a use case workshop, these test cases are very good at identifying ambiguities and uncovering missing requirements as they find mismatches between requirements and test cases.
8) Collect customer acceptance criteria – Acceptance testing should focus on the most important usage scenarios for customers and include non-functional requirements too, such as performance. Having your customers develop acceptance criteria is one of the most important methods of validating requirements. If they are not happy with the product, your time and money is wasted.
These are just some of the practices that are important to employ in validating requirements. Using these will help any development methodology be more effective in practice. IBM Rational has incorporated some of the best practices above into Rational Requirements Composer: project transparency, various methods to capture requirements, web review and validation, linking requirements to work items and test cases.
For another perspective on this topic, read the white paper in the business analysis e-kit: Getting your requirements right: Collaborate with stakeholders to work smarter
What else have you experienced that works (or doesn’t)? Please respond by commenting below.