Requirement definition, in my experience at least, is the most difficult part of OSS Software projects. Requirements are often general, vague and lack clarity, and occasionally don’t even exist! The end result is typically a misunderstanding of scope across all the parties involved in the project delivery, significant differences in expectation and ultimately a perception or reality of project failure in end user communities.
So why does this keep happening? Firstly, there is a contradiction in the purpose of requirements. Business stakeholders want to write requirements that are independent of the solution but can still tell them what they are getting, designers want to know what to design, developers want to know what to configure and code, and testers want to know what to test.
Second, project timeline and budgetary pressures also add to the challenge by pushing design and implementation to start prior to completion of thorough requirement definition.
Third, various requirement and use case models have been promoted and frequently quoted in software projects, but good requirement methodologies on paper seem to be rarely followed in practice.
My opinion? Whilst I agree design should be kept out of requirements, when a vendor product is involved there is often a case for writing detailed requirements in terms of that product – or at least in terms of its functional capabilities. This helps align expectations, provide enough detail for testing, design and implementation. To achieve this needs the requirement author to have a clear understanding of not only the business use cases driving the solution but equally of the capabilities of the target product and an understanding of what it means to do the implementation and testing work.
The more focus that can be placed on having a structured set of requirements, in particular clear, detailed functional requirements in terms of the target solution and products, the more likely the success of the project. On a positive note, it has been pleasing to see on a recent OSS project a good understanding and implementation of a requirement framework. If you have a good requirements process and business analysis team, buy them a beer as they have already won you half the battle.