OSS requirements

I have no requirements for a style of architecture.”
Michael Graves

There’s an interesting thing about generating requirements for technical projects – they are rarely requirements. More often than not, they’re written as a solution.

Requirements documents should focus on the business objectives, the outputs, the problems that need to be overcome. Unfortunately they are generally written by technical people and end up specifying technical functions, architectures, solutions, workflows, user interfaces, etc.

If you’re using a requirements document as part of an OSS vendor selection process, then the latter approach may not give you the optimal outcome. Every off-the-shelf OSS has its own look and feel, its own way of getting a task done, which makes direct comparison a challenge.

More importantly, each OSS can be configured in a variety of ways to achieve any given outcome, so as customers we should describe the desired outcomes and let the vendor experts figure out their optimal solution (with input along the way of course) to meet those needs. That way we get to evaluate multiple unique solutions, rather than different responses to a single solution.

Explain the why before the how, as described in this story about RADAR.

If you’ve been tasked with preparing a list of requirements for an upcoming OSS project, you may be interested in reviewing the tools and implementation techniques that we use on OSS projects. If you’d like assistance to prepare your requirements, or guide your organisation through the process, we’d be delighted to help (refer to contact page for details).

Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email

2 thoughts on “OSS requirements

  1. So true. Most of the telcos don’t have defined requirements for OSS. My personal thoughts are that requirements should be driven based on Business processes and Business benefits that needs to be delivered. It is so true that more often during the OSS implementation the requirements are governed by Technical teams who only look after a certain aspect of process and business. If the requirements are derived based on the end to end process it would clearly identify the gap in the process and business benefits that need to be achieved. the process needs to cover all aspects of the Customer Service (customer management layer), products & Services, Networks supporting those products & services and how they map on top of your service fulfillment and service assurance projects. Ideally if someone follows the eTOM or ITIL they could derive the requirements based on it.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.