Ten Requirements Traps(Wiegers)1. Confusion over “requirements”2. Inadequate customer involvement3. Vague and ambiguous requirements4. Unprioritized requirements5. Building functionality no one uses6. Analysis paralysis7. Scope creep8. Inadequate change process9. Insufficient change impact analysis10. Inadequate version controlConfusion over “requirements”• customer provided reqts often are reallysolution ideas• reqts discussions focus exclusively onfunctionality– A real project needs other stuff:• business reqts - high level business objectives• user reqts - interactions between users and system• functional reqts - specific behavior derived from usecasesHow do you develop softwarerequirements?SystemRequirementsVision and Scope DocumentUserRequirementsUse-Case DocumentFunctionalRequirementsSoftware RequirementsSpecificationQualityAttributesConstraintsNon-functionalRequirementsBusinessRequirementsInadequate CustomerInvolvement• Often users aren’t all that involved• Need to– identify user classes• gain direct info from each class– make use of a “product champion”Vague and AmbiguousRequirements• Ambiguity - several possible meanings– worst: multiple interpretations go undetected– can’t build simple black box test cases– developers (designers) have to ask questions• Solutions– avoid subjective and ambiguous language!– write test cases early– formal document inspection with various perspectives– prototype and build alternative modelsUprioritized Requirements• Or all (most) of “very high” priority– problems during the “descoping phase” later :-)• Prioritize on user’s needs– or frequency of use– favored user class– core business process– legal/regulatory constraints• Use at least 3 priority levelsBuilding Functionality No OneUses• beware of developer “chrome” GUI if ignoringactual useful system behavior– functionality should be clearly related to known usertasks or business goals• solution:– traceability of requirements to origins• use case, rule, person, standard– have customer rate value of each feature (and thepenalty if it is not implemented)– risk/benefit for features is good during crunch timeAnalysis Paralysis• Documents and process need not be perfect– the “best” can be the enemy of the “good”• Acceptable risk is not zero risk• Process is there to support product– and product can’t be produced without processInadequate Change Process• For later consideration - though it’shappened already :-)• You can get very bogged down without adefined change processInsufficient Change ImpactAnalysis• Costs and benefits of changes analyzedInadequate Version Control• Critical now– versioning system to distinguish drafts frombaselined documentsKeys to Excellent Reqts1. Educate developers, mngrs, customers about reqts and appl.domain2. Establish collaborative cust-devel partnership3. Categorize customer input into appropriate reqt category4. Take iterative and incremental approach to reqts devel5. Use std templates to customize for V&S, Use Case and SRS docs6. Hold formal and informal reviews of reqts docs7. Write test cases against reqts8. Prioritize reqts in an analytical fashion9. Basic discipline and “good enough” attitude to handling reqts