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 […]
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 […]
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.
MRD Writing Tips – Ten from Michael Shrivathsan
Michael has posted five (plus five) tips on writing a market requirements document (MRD). Michael has written a good set of tips with detailed explanations and anecdotes. We have re-organized these tips into three general areas of guidance and provide our thoughts.
Requirements Gathering – Interviewing the Right People
How do we find out what someone wants when they don’t know what they want or what they can have? One of the best techniques for gathering requirements is to interview users. But which users?
Imagine aliens came to the planet and offered to solve our gasoline problem. How could we tell them what we wanted? We might say we wanted cars that run on clean renewable energy. The aliens might leave thinking “Oh well, I guess they didn’t want faster-than-light travel.”
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.
Communicate Relevant Quality Metrics
Most teams think about testing in terms of code coverage – what % of the lines of code are covered? What matters to our stakeholders is how well the software works. More precisely, how well does the software let the users work? We should be targeting our quality message in terms of use cases, because that matches their perspective and context.
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.
Maine Mangles Medicaid – Charges CIO
Allan Holmes, for CIO Magazine just posted a scathing and detailed autopsy of the disastrous Medicaid Claims System project run by CSNI and launched in January of 2005. Requirements elicitation failures combined with incompetent vendor selection and project mismanagement lead to a $30,000,000 oops for the state of Maine, jeopardizing its credit rating. The system failed to process 300,000 claims in the first 3 months of operations, causing many health care providers to close their doors – and presumably causing citizens of Maine to go without needed services. Maine is the only state in the union (as of April 2005) not complying with federal HIPAA regulations.