“I have no requirements for a style of architecture.”
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