Software Requirements Part I
The DNR Project Requirements Group meets for the first time today. The assigment for the first meeting was to read part one of "Software Requirements" by Karl Weigers, a requirements guru. Published by Microsoft Press.
- The metrics should give pause to any developer. The costs of not doing requirements well are staggering. On average, rework consumes 30 - 50 percent of total costs and requirement errors account for 70 to 85 percent of reasons for rework
- The first chapter gives the top reasons for requirements errors. The one that jumped out at me was "CREEP"
- The author suggests using testing to constantly verify requirements. This can be verbal. You have a meeting with the customer and walk through what the software will do. It can also involve a rigorous verification process where a team of people look at your requirements documents and try to find errors.
- After reading this, I know I want to create a project glossary so we can have a reference for all the crazy terms fisheries biologists throw around.
- Establish a baseline document that the customer agrees to. This document serves to connect cost estimates, time estimates, requirements, basis for acceptance of completed project and a jumping off point for change management. The first thing to strive towards is a baseline for each of the following documents:
- Vision and Scope statement "why are we building this?"
- Use Case Document "Customers can make reservations"
- Software Requirements Specification "The system shall send the customer an email verification of the reservation"
- The book suggests creating user interface and technical prototypes, even a preliminary implementation. This seems to fly in the face of all the cautions in the book, "dont start coding until requirements are done" I question this.
- Version control on the requirements documents. Book suggests using a requirements management tool. Our analyst has a home grown one that he has developed over his career and it seems effective.
- hold facilitated elicitation workshops. **Shudder** We have tried several of these. Without the other stuff in place, they didn't bring us to where we needed to be. We didn't create usable requirements documents out of them and to do it again now may bring accusations that we are going over the same ground again.
- Don't use sign off as a weapon. Sign off means the customer has agreed to your estimates and requirements. I guess this means don't wave the requirements in your customer's face and scream, "You already bought it, sucker!!!" Use it instead as a basis for change management
- This section of the book leaves me wondering how estimates of time and money are connected to requirements. It says "Developers are in the best position to estimate costs" and then the next sentence says "many developers are not skilled estimators" so, how do we do it?
- The book has a nice "bill of rights for software customers" followed by a "bill of responsibilities for software customers" "Make timely decisions" is one of these...
- Finally, it has a list of good requirements characteristics. "Avoid lumping requirements into long narrative paragraphs. " bullets, bullets bullets.
8:31:43 AM 
|
|
