The glossing over of the requirements phase of a software project will cause substantial problems throughout the life of the project. Some of these problems include: unclear direction, poor communication with customer concerning requirements, never ending coding phase, and failed testing efforts. By not taking the time, in the requirements phase, you are trying to build a house or any large structure without a foundation. From this requirements foundation, everything going forward is based on the requirements you have laid out.
Customer Expectations and Coding
Requirements should be described as a contract between yourself and the customer. Contracts are very important because they protect both parties as they attempt to exchange value for value. The requirements describe the customer’s expectations for the delivered software project. They are instrumental to creating the offer, we will deliver this and it will cost this much and take this long. The reason for this is it creates a definitive starting and stopping point. For example, the moment you sign this contract, coding starts and all functionality will be delivered ending on this day. The take away for coding via good requirements is knowing when you can lay your pencils down.
Poor Foundation Leads to Poor Testing
When system level acceptance testing takes place, the lack of proper requirements will cause many failures and misunderstood behavior. A symptom of bad requirements is when software developers can legitimately say that they don’t have requirements for software behavior discovered in the testing lab. Test plans are created to requirements, test procedures are laid out per the requirements, and the test is executed with the idea of meeting the customer’s expectation. When the customer’s expectations are not outlined in the requirements, testing will be incomplete and not about verifying the software’s functionality.
Monday, June 13, 2011
Subscribe to:
Comments (Atom)