- Dedication
- Special Upgrade Offer
- A Note Regarding Supplemental Files
- Introduction
- Acknowledgments
- I. Software requirements: What, why, and who
- 1. The essential software requirement
- 2. Requirements from the customer’s perspective
- The expectation gap
- Who is the customer?
- The customer-development partnership
- Requirements Bill of Rights for Software Customers
- Right #1: To expect BAs to speak your language
- Right #2: To expect BAs to learn about your business and your objectives
- Right #3: To expect BAs to record requirements in an appropriate form
- Right #4: To receive explanations of requirements practices and deliverables
- Right #5: To change your requirements
- Right #6: To expect an environment of mutual respect
- Right #7: To hear ideas and alternatives for your requirements and for their solution
- Right #8: To describe characteristics that will make the product easy to use
- Right #9: To hear about ways to adjust requirements to accelerate development through reuse
- Right #10: To receive a system that meets your functional needs and quality expectations
- Requirements Bill of Responsibilities for Software Customers
- Responsibility #1: To educate BAs and developers about your business
- Responsibility #2: To dedicate the time that it takes to provide and clarify requirements
- Responsibility #3: To be specific and precise when providing input about requirements
- Responsibility #4: To make timely decisions about requirements when asked
- Responsibility #5: To respect a developer’s assessment of the cost and feasibility of requirements
- Responsibility #6: To set realistic requirement priorities in collaboration with developers
- Responsibility #7: To review requirements and evaluate prototypes
- Responsibility #8: To establish acceptance criteria
- Responsibility #9: To promptly communicate changes to the requirements
- Responsibility #10: To respect the requirements development process
- Requirements Bill of Rights for Software Customers
- Creating a culture that respects requirements
- Identifying decision makers
- Reaching agreement on requirements
- 3. Good practices for requirements engineering
- A requirements development process framework
- Good practices: Requirements elicitation
- Good practices: Requirements analysis
- Good practices: Requirements specification
- Good practices: Requirements validation
- Good practices: Requirements management
- Good practices: Knowledge
- Good practices: Project management
- Getting started with new practices
- 4. The business analyst
- II. Requirements development
- 5. Establishing the business requirements
- 6. Finding the voice of the user
- 7. Requirements elicitation
- Requirements elicitation techniques
- Planning elicitation on your project
- Preparing for elicitation
- Performing elicitation activities
- Following up after elicitation
- Classifying customer input
- How do you know when you’re done?
- Some cautions about elicitation
- Assumed and implied requirements
- Finding missing requirements
- 8. Understanding user requirements
- 9. Playing by the rules
- 10. Documenting the requirements
- The software requirements specification
- A software requirements specification template
- Requirements specification on agile projects
- 11. Writing excellent requirements
- 12. A picture is worth 1024 words
- Modeling the requirements
- From voice of the customer to analysis models
- Selecting the right representations
- Data flow diagram
- Swimlane diagram
- State-transition diagram and state table
- Dialog map
- Decision tables and decision trees
- Event-response tables
- A few words about UML diagrams
- Modeling on agile projects
- A final reminder
- 13. Specifying data requirements
- 14. Beyond functionality
- 15. Risk reduction through prototyping
- 16. First things first: Setting requirement priorities
- 17. Validating the requirements
- 18. Requirements reuse
- 19. Beyond requirements development
- III. Requirements for specific project classes
- 20. Agile projects
- 21. Enhancement and replacement projects
- 22. Packaged solution projects
- 23. Outsourced projects
- 24. Business process automation projects
- 25. Business analytics projects
- 26. Embedded and other real-time systems projects
- IV. Requirements management
- 27. Requirements management practices
- 28. Change happens
- 29. Links in the requirements chain
- 30. Tools for requirements engineering
- V. Implementing requirements engineering
- 31. Improving your requirements processes
- How requirements relate to other project processes
- Requirements and various stakeholder groups
- Gaining commitment to change
- Fundamentals of software process improvement
- Root cause analysis
- The process improvement cycle
- Requirements engineering process assets
- Are we there yet?
- Creating a requirements process improvement road map
- 32. Software requirements and risk management
- 31. Improving your requirements processes
- A. Epilogue
- B. Current requirements practice self-assessment
- C. Requirements troubleshooting guide
- D. Sample requirements documents
- Vision and Scope Document
- Use Cases
- Software Requirements Specification
- Business Rules
- E. Glossary
- F.
- G. About the authors
- Index
- About the Authors
- Special Upgrade Offer
- Copyright