- 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
Special Upgrade Offer
If you purchased this ebook directly from oreilly.com, you have the following benefits:
DRM-free ebooks—use your ebooks across devices without restrictions or limitations
Multiple formats—use on your laptop, tablet, or phone
Lifetime access, with free updates
Dropbox syncing—your files, anywhere
If you purchased this ebook from another retailer, you can upgrade your ebook to take advantage of all these benefits for just $4.99. Click here to access your ebook upgrade.
Please note that upgrade offers are not available from sample content.
-
No Comment
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.