My Requirements are Better than your Requirements

A important element in the software development process is the clear and concise set of requirements that are used to build a product. As stated in Wikipedia, “Requirements anlaysis is critical to the success of a development project” (https://en.wikipedia.org/wiki/Requirements_analysis). Requirements for software projects ensure that users and developers communicate in a common language; allowing users to detail the needs and wants of the software solution and developers to explain how the system will function. In this blog post, I will argue (in the limited space I have) that open source software projects are better suited at creating quality requirements that meet user demand.

Requirements gathering is a complex process that is well studied in university research (see https://en.wikipedia.org/wiki/Software_Requirements_Specification to start your education) and ultimately comes down to this basic fact – do the user and developer understand each other? It is essential that the developer and user agree to a fixed requirement to ensure the final deliverable will meet needs of each. In open source, a natural communication channel is built between the users and developers as the entire methdology is based on their interaction. Users running an open source product are given a variety of tools (mailing lists, forums, IRC channels) to report software problems as well as discuss feature requests with the developers of the project. This constant interaction provides developers with a clear understanding of how their product is used and why certain features are needed and in what manner. As an example, in the Xen.org community that I manage, we provide mailing lists and IRC channels for users to provide feedback to the developers. Our mailing lists average over 3,000 emails a month with a high percentage of those being users reporting back to the community issues they find with the software as well as new ideas for future product changes. This constant exchange ensures that developers stay focused on the customer and not just their own technical fancy.

In most (of course there are expections to this rule but they are less common in closed-source) closed-source software development projects, there is no direct link between the developer and the user. A product manager or requirements engineer is placed between the user and developer so the developer can focus on the software without the distraction of customer interaction. Instead, the developer is presented with a document from an intermediary who has themselves taken all available customer feedback and processed it with their own viewpoint. This separation of user and developer is a critical flaw in the closed-source model as developers are not given the chance to understand the how and why from a user perspective.

I hope this week’s blog post is less controversial than last week, unless you are a closed source product manager in which case I am more than happy to hear how you as an intermediary makes things better. In fact, this subject always reminds me of this famous scene from Office Space…