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.
Product Management / Requirements / Software requirements specification
Posted on:
Writing Consistent Requirements
One of the ten big rules of writing a good MRD is writing consistent requirements. Consistency within an MRD has two dimensions that are important to requirements – logical consistency and grammatical consistency. There is also the element of writing an MRD that is consistent with other documentation – external consistency.
Product Management / Requirements / Software requirements specification
Posted on:
Writing Complete Requirements
One of the ten big rules of writing a good MRD is writing complete requirements. We identify problems and opportunities in the market. We determine that one of these problems is valuable enough and practical to implement. Then we have to write the requirements, and make sure that the requirements will completely solve the targeted problem.
Product Management / Requirements / ROI
Posted on:
Writing Attainable Requirements
One of the ten big rules of writing a good MRD is writing attainable, or realistic requirements. These are requirements that can be practically implemented, by our team, according to our schedule. Practicality is a function of the skills of our team members, the costs that we face to implement a particular requirement, and the circumstances in which we are developing. Agile proponents use the phrases ‘people trump process’ and ‘politics trumps people.’ To write attainable requirements, we have to think about our people and our political situation.
Austin TX / Presentation / Product Management / Requirements / Requirements gathering
Posted on:
Intro to Requirements Gathering – St. Edward’s University
Welcome Dr. Franke’s students in Analysis, Modeling and Design MCIS6310! Thanks again for inviting me to present to your class on requirements gathering and requirements management. The presentation is available for download. You can get both the slides and the notes pages. The notes pages include additional content and links […]
Product Management / Requirements
Posted on:
Prioritizing Software Requirements With Kano Analysis – Article Published
Pragmatic Marketing has published an article on Kano Analysis. The article was written by Scott Sehlhorst and represents a merging of two of the posts (1 2) at Tyner Blain that focus on Kano Analysis.
Design / Product Management / Requirements / Software development / Software requirements specification / Writing
Posted on:
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 Big Rule of Avoiding Design-Agnosticism […]
Product Management / Requirements / Software requirements specification
Posted on:
Writing Concise Requirements
One of the ten big rules of writing a good MRD is writing concise requirements. We have to minimize the amount we write to avoid information overload. We also need to make sure we write enough to get the message across. How do we strike the balance?
Interaction design / Product Management / Requirements / UX
Posted on:
Writing Valuable Requirements
One of the ten big rules of writing a good MRD is writing valuable requirements. How do we determine what requirements are valuable? To whom are they valuable? When a requirement represents a continuum how much is enough? What is too fast, what is too scalable? To whom must the requirement be valuable?