FURPS is an acronym representing a model for classifying software quality attributes (functional & non-functional requirements):

• Functionality - Feature set, Capabilities, Generality, Security
• Usability - Human factors, Aesthetics, Consistency, Documentation
• Reliability - Frequency/severity of failure, Recoverability, Predictability, Accuracy, Mean time to failure
• Performance - Speed, Efficiency, Resource consumption, Throughput, Response time
• Supportability - Testability, Extensibility, Adaptability, Maintainability, Compatibility, Configurability, Serviceability, Installability, Localizability, Portability

1. Assume your visual modeling tool will generate great code for you, and hire a bunch of junior college students to handle coding.
   
2. Ignore the analysis and design models you have produced, write the code, and reverse-engineer all the code you've written into an as-built object mdoel.
   
3. Take a team of 20 or so VB programmers, hand them a C++ compiler and visual modeling tool, and leave them to their own devices.
   
4. Implement the easy parts of your system first. Leave the critical items for the end, near the deadline.
   
5. Keep you design model completely segrated from your use case model; we all know use cases don't affect code.
   
6. Don't bother to review any of your analysis or design models.
   
7. Keep most of your senior designers busy writing use cases; have your junior people work on sequence disgrams.
   
8. Don't do unit testing ...

1. There should be at least one test case in place to verify each requirement.
   
2. The detailed design, as reflected in your sequence diagrams, should be defended against the use case text as part of design review.
   
3. The text of each use case "contract" must appear on a sequence diagram so that the development team is constantly reminded of the "contractual requirements" they are working against as they design.
   
4. The team should trace the allocation of requirements to use cases and domain classes as part of the requirement review.
   
5. The use case model shall serve as a collection of mini-contracts between developers and the sponsors of the the new system. Each use case shall serve as both input to the development process and as a user-acceptance test case.
   
6. The project team should demostrate connection of at least one class directly with each requirement during ...