Software Requirements “Bills of Rights”

Welcome to Practical Analyst, a site specializing in practical insight for business analysts and project professionals. If you're new here, you may want to subscribe to my RSS feed or follow me on Twitter. Thanks for stopping by!

Karl Wiegers’ Requirements Bills of Rights and Responsibilities of Software Customers are great in helping business stakeholders that are new to the requirements gathering process understand what the requirements analyst needs from them, and what they, as the customer should expect of the analyst. I’ve listed the bills of rights below:

Requirements Bill of Rights for Software Customers

As the customer, you have the right to:

1. Expect analysts to speak your language.
2. Expect analysts to learn about your business and your objectives for the system.
3. Expect analysts to structure the information you present during requirements elicitation into a written software requirements specification.
4. Have analysts explain all work products created from the requirements process.
5. Expect analysts and developers to treat you with respect and to maintain a collaborative and professional attitude throughout your interactions.
6. Have analysts and developers provide ideas and alternatives both for your requirements and for implementation of the product.
7. Describe characteristics of the product that will make it easy and enjoyable to use.
8. Be given opportunities to adjust your requirements to permit reuse of existing software components.
9. Receive good-faith estimates of the costs, impacts, and trade-offs when you request a change in the requirements.
10. Receive a system that meets your functional and quality needs, to the extent that those needs have been communicated to the developers and agreed upon.

Requirements Bill of Responsibilities for Software Customers

As the customer, you have the responsibility to:

1. Educate analysts and developers about your business and define business jargon.
2. Spend the time that it takes to provide requirements, clarify them, and iteratively flesh them out.
3. Be specific and precise when providing input about the system’s requirements.
4. Make timely decisions about requirements when requested to do so.
5. Respect a developer’s assessment of the cost and feasibility of requirements.
6. In collaboration with the developers, set priorities for functional requirements, system features, or use cases.
7. Review requirements documents and evaluate prototypes.
8. Communicate changes to the requirements as soon as you know about them.
9. Follow the development organization’s process for requesting requirements changes.
10. Respect the process the analysts use for requirements engineering.

Reference: Wiegers, Karl E, Software Requirements, Second Edition, 2003, Microsoft Press, page 32.

If you found the bills of rights helpful, I’d certainly recommend grabbing a copy and perusing the rest of the book. He just does a good job of defining and breaking down process.

There are lots of other more theoretical and “heavier reads” available on requirements engineering – and I probably have most of them. They all have their value, and their place. I typically refer to the Wiegers book, though, for quick reference and practical, intuitive breakdowns of the steps of the requirements engineering process.

While I’m stuck on Wiegers, you may also want to check out his Website, Process Impact, where he provides lots of software process tips and tricks, including some free “goodies” as he refers to them.

Related posts:

1. How Can a Business Analyst Help You?
2. Great Software Engineering Proverbs
3. Is “Requirements Engineering” a Misnomer?
4. What do software developers and drug dealers have in common?
5. McDonald’s Burgers and High-Quality Business Analysts