“The most difficult part of requirements gathering is not the act of recording what the user wants, it is the exploratory development activity of helping users figure out what they want.”
When starting out on a requirement gathering exercise, The Radar Analogy always seems to spring to mind because it carries such a powerful, but simple requirement gathering message. In a nutshell, identify your fundamental objectives (defence against hostile aircraft) rather than your perceived solution (acoustic mirrors).
What are the simplified, high-level objectives that you need your OSS to deliver upon, the ones that will make a profound impact on your organisation?
Once you have those objectives in mind, look to specify your requirements in terms of high-level use-cases. Then hand over responsibility to the vendors and let them show you how their products can deliver upon your use cases and objectives within the constraints of their product capabilities.
This approach is significantly different from the way that most organisations with talented Telco and/or OSS engineers (OctopOSS tamers) handle the vendor selection process. The customer’s side will tend to prove their capabilities by requesting specific technical / functional solutions.
I feel the better way is to allow the market to innovate using your objectives as a base and let them dazzle you with a solution you never even imagined (hopefully).
The other benefit of preparing a set of use cases is they can have multiple uses for consistency throughout your project life-cycle including:
- Capturing requirements
- Initial vendor presentations
- Proof of Concept (PoC) presentations by the vendors
- The starting point for process development
- Vendor product benchmarking (ie efficiency analysis between vendors)
- User Acceptance Testing (UAT)
eTOM may provide a useful starting point if you’re developing your OSS use-cases from scratch.