Education & Professional Development Volume 1, Issue 6
Page 6
Requirements as Part of the Software Development Lifecycle—by Rob Dubois Requirements (Business and Functional) are the binding communications and agreements between all stakeholders on a project. Software requirements for IT solutions are no different than blueprints for a house. The blueprints and architecture renderings tell the client/customer what the house will look like, how it will be organized, and what and where everything will be when completed. This same document(s) is also used to communicate to the sub-contractors (plumbers, electricians, painters, concrete, framers, roofers, cabinet makers...) what is to be done and conveys the concepts of the client into concrete terms. This same document (blueprint or requirements) is also, what will be used to effect changes against, and is used during the project life cycle and at completion for sign-off/acceptance. The software construction industry (if you will) is still in its infancy when compared to other industries and has fought against the adoption for this need of a blueprint or requirements that the construction industry depends upon for its very existence. This resistance is not only expressed by the developers and the customers in some cases, but also expressed by management through their lack of action and or support. There is still today a push to begin working on the architecture or coding components, assuming we already know something of what is to be expected as part of the project. It is as if to say that if the development team is not immediately busy on a project then we are wasting time, money and resources.
1. The Problem Is Two Fold 1.1 Philosophical Value
So what we have is a two fold problem. We must philosophically agree that requirements are of tremendous value and vital to the success of any project. I can find a zillion articles and industry experts and experiences proving this point. This philosophical agreement must be expressed by management and everyone else, not as lip service but expressed in accountable actions. Requirements are not the stick in the mud that slows a project down. They are not something that is overkill or states the obvious. To many times I have seen what was thought of as simply known items that turned out to be problems because what was communicated was interpreted differently, implemented differently, or just a poor assumption. A problem easily solved by requirements definition. We also tend to place value on what we believe are good relationships with our clients/customers. As a result, we become lax or relaxed in how we work with them. The relationship suffers. Because the bottom line is, no matter how good your relationship is, or you believe it is, the client/customer must be consulted and treated in the same manner and ultimately accepts the solution based on their expectations. If the client/customer did not receive what was expected then the fault lies with the software provider. It is the responsibility of the Project Manager and Business Analyst to manage their client to ensure that what is being asked for and eventually provided is understood, agreed to and documented. Anything less than full attention to this responsibility is a recipe for project failure or hardship. The Project Manager and Business Analyst are the two roles with the direct face-to-face meetings and interactions. The rules of engagement must be clear. They are not harsh, condescending or introduce difficulty in execution, but are done as a professional respect for the client/customer, his/her time and his/her money. The acceptance process of the final product or deliverable begins with requirements and not with the final delivery. The acceptance process spans the full lifecycle of the project. Development Team Resistance Developers tend to resist requirements because it does several things that make them un-comfortable. It is perceived that requirements take away some control or ability to code as they see fit. Requirements also hold developers accountable which is also resisted. Finally, requirements tend to indicate that development is not as important a role because you have told me what to do. These issues are all a result of misperception, poor management and communication. Requirements when done correctly communicates to the developer what to do and in a very high level how something has been requested to function, but how that requirement/functionality gets implemented is still up to the developer. Holding developers accountable is not only good for the developer, but also the project. To this point, it helps protect the developer from chaotic changes and provides a stable known work structure. Finally, developers as end users of the requirement information should participate in the review and acceptance of requirements. Of all the artifacts produced, requirements affect the most stakeholders and therefore are an artifact with the most customers or users of that information than any other. As a result it is critical that all stakeholders receive that information in the format that they can use to be successful in their role on the project. It is the responsibility of the analyst to ensure that the requirements contain the information in the format needed by each stakeholder or user of the requirements information. This information and the recognized value is what drives the second problem.