Software requirements
Without formal, verifiable software requirements-and an effective system for managing them-the programs that developers think they've agreed to build often will not be the same products their customers are expecting. In SOFTWARE REQUIREMENTS, Second Edition, requirements engineering authority K...
| Autor principal: | |
|---|---|
| Formato: | Libro electrónico |
| Idioma: | Inglés |
| Publicado: |
Sebastopol :
Microsoft Press
2009.
|
| Edición: | 2nd ed |
| Colección: | Pro-Best Practices
|
| Materias: | |
| Ver en Biblioteca Universitat Ramon Llull: | https://discovery.url.edu/permalink/34CSUC_URL/1im36ta/alma991009627958506719 |
Tabla de Contenidos:
- Software Requirements, Second Edition; Who Should Read This Book; Looking Ahead; Case Studies; From Principles to Practice; Acknowledgments; I. Software Requirements: What, Why, and Who; Levels of Requirements; What Requirements Are Not; Requirements Development and Management; Requirements Management; Every Project Has Requirements; When Bad Requirements Happen to Nice People; Creeping User Requirements; Ambiguous Requirements; Gold Plating; Minimal Specification; Overlooked User Classes; Inaccurate Planning; Benefits from a High-Quality Requirements Process
- Characteristics of Excellent RequirementsCorrect; Feasible; Necessary; Prioritized; Unambiguous; Verifiable; Requirements Specification Characteristics; Consistent; Modifiable; Traceable; 2. Requirements from the Customer's Perspective; The Customer-Development Partnership; Right #2: To Have Analysts Learn About Your Business and Objectives; Right #3: To Expect Analysts to Write a Software Requirements Specification; Right #4: To Receive Explanations of Requirements Work Products; Right #5: To Expect Analysts and Developers to Treat You with Respect
- Right #6: To Hear Ideas and Alternatives for Requirements and Their ImplementationRight #7: To Describe Characteristics That Make the Product Easy to Use; Right #8: To Be Given Opportunities to Adjust Requirements to Permit Reuse; Right #9: To Receive Good-Faith Estimates of the Costs of Changes; Right #10: To Receive a System That Meets Your Functional and Quality Needs; Requirements Bill of Responsibilities for Software Customers; Responsibility #2: To Spend the Time to Provide and Clarify Requirements; Responsibility #3: To Be Specific and Precise About Requirements
- Responsibility #4: To Make Timely DecisionsResponsibility #5: To Respect a Developer's Assessment of Cost and Feasibility; Responsibility #6: To Set Requirement Priorities; Responsibility #7: To Review Requirements Documents and Evaluate Prototypes; Responsibility #8: To Promptly Communicate Changes to the Requirements; Responsibility #9: To Follow the Development Organization's Change Process; Responsibility #10: To Respect the Requirements Engineering Processes the Analysts Use; What About Sign-Off?; 3. Good Practices for Requirements Engineering; Requirements Elicitation
- Requirements AnalysisRequirements Specification; Requirements Validation; Requirements Management; Project Management; Getting Started with New Practices; A Requirements Development Process; 4. The Requirements Analyst; Essential Analyst Skills; Essential Analyst Knowledge; The Making of an Analyst; The Former Developer; The Subject Matter Expert; Creating a Collaborative Environment; II. Software Requirements Development; Business Requirements and Use Cases; Vision and Scope Document; 1.2. Business Opportunity; 1.3. Business Objectives and Success Criteria; 1.4. Customer or Market Needs
- 1.5. Business Risks
