One of the ten big rules of writing a good MRD is writing unambiguous requirements. Ambiguity is a function of communication. The writing can be generically ambiguous, or ambiguous to the writer. A requirement could be precise in intent, but ambiguous in interpretation by the reader. Understanding our audience is as important as precision in language. We write unambiguous requirements because misinterpretation of requirements is the source of 40% of all bugs in delivered software.
Category Archives: Writing
Posted in Outsourcing, Product Management, Requirements, Software requirements specification, Writing
Tagged ambiguous requirements, business requirements documentation, clear requirements, good requirements, managing data, product requirements, requirements documentation, software requirements, unambiguous requirements, vague requirements, writing business requirements, writing requirements
5 Comments
Writing Design-Free Requirements
topsyWidgetPreload({ “url”: “http%3A%2F%2Ftynerblain.com%2Fblog%2F2006%2F06%2F02%2Fwriting-design-free-requirements%2F”, “style”: “big”, “title”: “Writing Design-Free Requirements” }); One of the ten big rules of writing a good MRD is writing requirements that do not specify design. How do we specify enough detail to be actionable without constraining the engineering team? How do we trust our developers to do the right thing? The [...]
Posted in Design, Product Management, Requirements, Software development, Software requirements specification, Writing
Tagged business requirements documentation, design-free requirements, good requirements, managing data, product requirements, requirements documentation, requirements vs design, software requirements, writing business requirements, writing requirements
2 Comments
Writing Good Requirements – The Big Ten Rules
Pragmatic Marketing has a training seminar called Requirements That Work. In support of that, they provide a list of 8 characteristics of good requirements. We change one and add two more to round it out to The Big Ten Rules. Combine this with Michael’s ten tips for writing MRDs, and we’ve got a good handle on how to create a great MRD.
Posted in Lists, Product Management, Requirements, Software requirements specification, Writing
Tagged business requirements documentation, good requirements, managing data, product requirements, requirements documentation, requirements specification, software requirements, writing business requirements, writing requirements
35 Comments
Requirements Documents – One Man’s Trash
…Is another man’s treasure. There are many different ways to document requirements when developing software. And there is a proliferation of requirements documents – MRD, PRD, SRS, FRS and design documents. Everyone has a perspective on what each document represents, and each person on the team has a unique perspective on what questions the document answers.
Posted in Communication, Product Management, Requirements, Software requirements specification, Writing
Tagged FRS, functional requirements specification, managing data, market requirements document, MRD, MRD PRD, PRD, product requirements document, requirements documentation, requirements documents, software requirements specification, SRS
8 Comments
Targeted Communication – Status Reporting
We’ve posted tips about targeted communication – tailoring the message for the audience. Anthony Mersino has an excellent post from January of this year about how to write a good status report. He provides seven excellent guidelines for status reporting, and all of them around providing the message our audience cares about, as effectively as possible.
Targeted Communication – Three Tips
Most guides to writing an executive summary miss the key point: The job of the executive summary is to sell, not to describe.
This from Guy Kawasaki’s recent post, The Art of the Executive Summary. Guy’s article is structured towards pitching an idea to a potential investor. We’re going to apply the same rationale to the communication that is key to successful product development – communication from the team, to stakeholders and sponsors.We also communicate with people outside of our team. We communicate to set expectations with customers, users, and clients.We communicate with sponsors, customers, and others who fund our software development. Without these channels of strategic communication, we won’t have a project, or worse, won’t have a customer when we’re done. External communication is strategic communication.
Jargon gone amuck!
topsyWidgetPreload({ “url”: “http%3A%2F%2Ftynerblain.com%2Fblog%2F2006%2F02%2F15%2Fjargon-gone-amuck%2F”, “shorturl”: “http://bit.ly/cIeV7E”, “style”: “big”, “title”: “Jargon gone amuck!” }); This video showing the abuse of jargon (2 minutes) is absolutely hysterical, and should be watched for humor alone. However, it also drives the point home about the effects of using jargon when writing requirements. When we write a PRD or SRS if [...]
Writing Requirements Unambiguously
Writing requirements without ambiguity
This is one of the harder parts of writing good requirements. Marcus tells us to avoid it with a good example here. Jerry Aubin at Seilevel has written an outstanding post on the subject, The art and science of disambiguation. Jerry starts his post with a gripping example from Weinberg and Gause:
Writing Functional Requirements to Support Use Cases
Background:
In our previous post, Sample use case examples, we created two informal use cases. The use cases were written to support product requirements defined as part of a project to reduce test suite maintenace costs. In this post, we will define functional requirements that support these use cases. This process is an example of using structured requirements, applied to a small real world project.
Posted in Requirements, Requirements Models, Software development, Software requirements specification, Use Cases, Writing
Tagged functional spec, managing data, software cost estimate, software development process, software product requirements, software requirements management, structure requirements, supporting use cases, use cases, writing functional requirements
2 Comments
Latest Articles
Comments on all Articles
