Published: 01 May 2012
Thanks to collaborative features in ALM tools, software teams can now connect with customers as well as communicate more effectively internally. Let’s take a look at how requirements management in agile ALM environments is allowing for strong collaboration throughout the lifecycle.
In traditional Waterfall development environments, requirements are documented in lengthy tomes that must be complete and approved before a line of code is written. Just when the team thinks the requirements have all been approved, a lengthy change is suggested, requiring a re-review from everyone. And despite the attempt at freezing requirements once the document has finally been approved, changes are invariably needed throughout the lifecycle, causing scope creep and schedule delays.
Those who have been through this tedious process recognize that unless there is communication and collaboration throughout the entire lifecycle, like a game of “gossip,” the end product is going to look very different from what was expected. But any changes that are requested during user acceptance testing are much more difficult to implement than if they were caught early. The later code changes are requested, the more complex they become because of the dependencies in the application.
The authors of the Manifesto for Agile Software Development recognized that business and IT collaboration throughout the lifecycle would allow for a partnership and flexibility that would lead to a higher-quality product. ALM vendors have followed suit by including collaborative features in their tools, which allow for strong teaming and the ability to respond quickly to changing needs, regardless of where team members or customers are. In this agile scenario, updating requirements throughout the cycle becomes a collaborative process and business users and customers end up with the quality products they expect.
ALM tool suites are designed to break down the former silos that existed between groups and instead provide an integrated and collaborative approach to software development. Technology trends such as cloud computing, social media and mobile computing have facilitated a work-from-anywhere world where collaboration and communication is possible without the physical boundaries imposed by an office. Such technology advances mean that distributed teams will continue to grow in number but will require strong collaborative ALM for successful teaming.
ALM tools are incorporating features both for facilitating stronger teaming internally as well as creating avenues for interaction with external customers.
Collaborative ALM features include things like the following:
- Any kind of communication feature (IM, forums, status updates)
- Linking artifacts
- Dashboards that combine data from various parts of the lifecycle
- Sharing of documentation or other artifacts
- The ability to “follow” discussions
- Notification of changes
- Capture collective feedback
- Polls and voting
Anything that allows for stronger communication and group teaming is considered a collaborative feature.
Interacting with customers
Though many ALM collaborative features are aimed at stronger internal communication and collaboration, some features are allowing organizations to communicate directly with customers. Many of these features are borrowed from the popular Web 2.0 or social media movement which allows for communication with anyone who has access to the Web.
Forrester analyst Tom Grant says that collaborative features in ALM tools are either actionable or contextual. In using these features to gather information from customers, he says:
“I think that’s where the distinction between the actionable and contextual information is important. There’s information that’s coming in all the time in requests for new functionality that have to be processed and that’s actionable information. And with social media tools, that ramps up the amount of that information that’s coming in. There is also the contextual information so as a business analyst or product manager, I want to know how representative are these individual requests so I can go back and do some sort of aggregate analysis. How many people have ever asked for something like this? Why are they asking for it? That’s contextual information. So absolutely, there’s a lot of information that needs to flow in. Some of its very deliberate information as part of an ongoing conversation with the user; part of it is archival so I can go back and test hypotheses that I have. But this is another area I’ll certainly say I strongly believe there is no science yet to it.”
Responding quickly to changes
Collaborative features in ALM requirements management is more than communicating with customers, though. The internal business and development teams need to stay current on which features are being included in the product and know when clarifications or changes are made to requirements.
SearchSoftwareQuality.com’s requirements expert Scott Sehlhorst notes:
“There are two challenges in communicating changes in requirements: making sure the people consuming the requirements realize what has changed and making sure the requirements are still referentially consistent (that changes that propagate or ripple through the dependencies) are identified, documented and communicated.”
From a requirements-management point of view, collaborative features in an aLM would include things such as the following:
- The ability for all stakeholders (customers, business, development, quality assurance, product managers, business analysts, executives) to review and comment on the requirements in-line
- The ability to flag and discuss issues
- The ability to propose changes and resolve issues as a team
- Version control of changes to the requirements
- The ability to vote or take polls
- The ability to capture decisions and approvals from stakeholders
- The ability for stakeholders to be notified of changes
- The ability to create output documents tailored to different audiences
Sehlhorst explains how using a tool with such collaborative features, in which data is stored in a common repository, is much more efficient than the old-fashioned approach of a requirements document that is passed around for reviews and approvals.
“When you use a monolithic document (like an MRD or PRD or FRS), you can track changes to see where the document has changed. On large projects, this can become a significant burden, with high risk that changes will be missed by the consumers. There is also a high cost of repeatedly re-reviewing the things that didn’t change in order to discover the things that did. Most monolithic documents also fail to provide tools to discover the inter-dependencies between requirements.
When you manage your requirements as atomic entities in a repository (database), you can provide better tools for discovering when one requirement has changed (eliminating the need for consumers of requirements) to re-review those items that haven’t changed. You can also explicitly manage the network of inter-dependencies through traceability, enabling the product manager to make sure that they are discovering all of the ripples of change, assuring requirements consistency and completeness.”
Requirements management has come a long way since the early days of passing around lengthy documents for approval. With today’s collaborative ALM tools, software teams are able to gather data from customers, stay notified of changes and communicate effectively throughout the lifecycle.
About the Author
Yvette Francino, the site editor for SearchSoftwareQuality.com, has more than 20 years’ experience in all phases of the software development lifecycle, having worked at IBM and Sun Microsystems. She has held management positions in software development, quality assurance and customer operations, managing diverse workgroups. She has a master’s degree in management and project management Regis University, and a bachelor’s in electrical engineering and computer science from the University of California, Davis.