July 13, 2013

Does Managing Requirements by Project Make Business Sense?

Helix ALM
Requirements Management
It seems like a straightforward proposition. We have a business problem, and we start a project to address that problem. Business analysts look at the problem domain, interview users, and come up with a set of project requirements that drive a subsequent application development effort. But what happens in larger organizations where there are multiple projects going on at the same time? Especially if the various applications work with one another in some way? It’s possible that some requirements in different projects can conflict with one another, even to the extent of one project reversing a feature required by another. The difficulty is not that the process itself was contradictory, but rather that there is generally no way of comparing requirements across projects. If one project requirement said X for a given application, and another said not-X for a different version of the same application, that discrepancy may never be discovered. That could result in the business making a wrong decision, or software behaving in unexpected ways. At Swiss Requirements Day in June, SIX Financial requirements engineer Olav Dreier had an answer. Requirements shouldn’t be bound to a project, says Dreier. Instead, requirements should be associated with defined business processes. With multiple overlapping projects, it is not only possible but likely that requirements for different projects will contradict one another. Dreier used his experiences at SIX Financial to describe the success of connecting requirements to business processes rather than to individual projects. He noted that the company made a concerted effort to associate requirements with their associated business process, without regard to project. Requirements engineers for individual projects then choose requirements from the defined business process to implement for each project. This sounds similar to a practice I was involved with years ago. When I was a product manager in commercial software development, we had two types of requirements. The first we called market requirements. These defined product needs based on a combination of industry trends, customer requests, and our own analysis. It was a single document that was reviewed and updated on a regular basis. The second type of requirement was release requirements. When it was time to define a next product release, we would sift through the market requirements to determine which requirements were most important to customers and to maintain market leadership, while also fitting into the product release cycle. This required ongoing work to make sure the market requirements were current and accurate, but it resulted in a more streamlined way of defining individual releases. Managing requirements by market or business process argues for the use of Seapine TestTrack RM as both a general requirements repository and a project repository. Because TestTrack RM lets teams define business requirements as well as functional requirements, it is possible to number and manage business requirements for the business process while choosing functional requirements on a project-by-project basis.