Project teams are searching for ways to develop requirements that are as free from defects as possible. Here's how you can use collaborative workshops, along with walkthroughs and QA checklists, to develop high-quality requirements.
Just how important is it to fully develop your project's requirements? After all, nailing down your requirements is usually only 8% to 15% of your overall project effort. Truth be told, it's not really something you'll want to spend your resources and energy on- unless, that is, you care at all about the quality of your product, your customers' level of satisfaction, and the amount of post-implementation repair you'll have to take care of down the road.
Why is it so important to get requirements right? For one thing, you're likely to introduce more defects into your software product in the requirements phase than in any other phase-and these defects account for as much as half of the product's total defects. Defects in requirements are harder to remove than defects originating in any other phase. But that's not all. Fixing them later in the project will cost you more, too-as much as 100 times more after implementation than if you detected and corrected them in the requirements phase. It's no wonder that rework due to requirements defects can eat up as much as 50% of your overall budget.
One other aspect of low-quality requirements is harder to measure, but just as treacherous. It's called "scope creep," and it's often cited as the most vexing problem in software development. Unrestrained by carefully developed requirements and mutual IT-customer or product development agreement, the scope of the project keeps creeping-expanding as the work proceeds.
For all these reasons, project teams are searching for ways to develop requirements that are as free from defects as possible. One way to develop high-quality requirements is based on the use of collaborative workshops along with walkthroughs and QA checklists. As this article will illustrate, that combination of best practices gives you a powerful and efficient way to deliver quality user requirements-and, by extension, quality software products.
What Makes Workshops Work?
In collaborative workshops, participants share a common goal, and they agree to join together to create work products in the pursuit of that shared goal. Workshop participants, sometimes called a task group, are productive because collectively they have the right mix of skills and knowledge to create the work products. Members of the task group act interdependently, relying on one other's knowledge, experience, skills, and perspectives. They are cohesive, meaning that they are motivated to act together. With appropriate direction, such a group can be highly productive.
If you're familiar with the acronym JAD (joint application design), then you're already familiar with one type of collaborative workshop. JAD workshops are structured events in which a carefully selected group of stakeholders and content experts works together to create, correct, and document a predefined deliverable, or work product. The group agrees ahead of time on the deliverables, and the participants often produce some of them before the workshop; this sort of timeboxing enables the group to focus on what's really important. The most successful workshops are composed of a healthy mix of business experts (or product development people representing those experts) and IT people, led by a neutral facilitator and a scribe who documents the group's work as it proceeds.
How are JADs and other collaborative workshops different from other kinds of business meetings?
On the surface, collaborative workshops are like "meetings" in that both types of gatherings involve people meeting together at the same time, and both (presumably) follow a logical flow. But there are significant differences. Among them is the presence of two people who fulfill two specific process roles: facilitator and scribe. The facilitator is responsible for managing the group's activities, dynamics, and work products. The