“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.”
Steve McConnell.
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:
eTOM may provide a useful starting point if you’re developing your OSS use-cases from scratch.
Earlier this week, I was lucky enough to be introduced to a talented RAN automation expert. He’s one of Australia’s foremost, hands-on, experts on SON
I was listening to a group of telco experts on a podcast the other day. As they were talking, I kept picturing the image of
Earlier in the year, we wrote a series of articles about the chasm that exists between OSS/BSS buyers and sellers (pt1, pt2, pt3, pt4, pt5, pt6). “The chasm” is
Actually, maybe a few related questions. As you’ve seen from recent articles such as this, I’m increasingly interested in the cross-over worlds of comms and
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
