Requirements, shmequirements

Working on the PM tools research (drafted, in editing) has led to a recurrent question: what sort of requirements tool? Requirements definition? Requirements management? Something else?

Does it matter? The distinctions seem a bit arbitrary. The raw data is the same, regardless of the immediate task (collecting, analyzing, using them in a product plan, using them in feature or use case documents, tracking the progress of a release towards meeting these requirements, etc.). Why should these different bits of information be stored and managed in separate systems?

If you don't believe that having a shared repository of dynamically assembled requirements information, go work for a PM group for six months, and count the number of times you type the same information into multiple formats. For example, let's assume Friendly Customer Inc. wants a particular enhancement. A short version of that enhancement request may appear in a list of possible features for the next release. Friendly's use case might be important supporting documentation for the feature write-up. When the CEO demands to know how the company is responding to Friendly, one of the firm's best customer, the enhancement will appear in a slide. And son on.

While you might not want to try tackling every possible use of requirements data in the original application, the natural gravity of product management certainly tugs in that direction. Otherwise, why not just go back to using Microsoft Office, manually re-purposing the same information in new documents for different audiences?

You have to set some boundaries. Still, the borders are pretty wide. Atlassian, for example, has a product strategy that tries to pull all members of a technical teams--developers, QA engineers, product managers, and project managers--into the same suite of integrated tools. They're not requirements tools, in the strictest sense that some people prefer, but certainly the issue tracking part of the Atlassian suite, JIRA, has direct relevance to customer needs that may turn into features. Makes sense, just as much as automated test case generation from a requirements tool like Borland's Caliber DefineIt is a necessary byproduct of what PMs do when writing requirements.

Rather than worrying about how finely you can slice the requirements tools market, the real question might be, How big a collection of functionality should a requirements tool embrace?


re: Requirements, shmequirements

The key requirement :-) for a requirement's management tool is traceability. What people need to know is how the prioritization of the requirements was defined. And, for a product manager, defending why certain efforts are prioritized a certain way are actually more important than the requirements themselves.The worst thing a PM can do is present what appears to be an arbitrary list for development to work on. Even if the PM has done all their homework, if there is no tracability back to customers/partners/competitors/market trends etc, it might as well be just someone's arbitrary opinion.Teams such as sales, marketing etc. need to be able to see the context of the decisions made by the PM, because, if they feel they are not being heard (particularly sales people) by the PM, they can put pressure on the PM to do their bidding. This is particularly true in a sales driven company.But if the PM has the evidence for their decisions, readily available via a requirements management product, the PM can easily defend their work.Saeed

re: Requirements, shmequirements

I believe strongly that there is a need for more prototyping and simulation of requirements because text is not a good way to convey requirements and features.Moving from IT to BT means that you have to move past the old ways of gathering and documenting requirements, and try a new tact to increase innovation and speed to market.While most of iRise's customers are F1000 IT departments, the issues we solve with IT are the same as the issues faced by product managers in software companies.Tom HumbargeriRise - http://www.irise.comiRise blog -