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?
Lists / Product Management / Requirements / Software requirements specification / Writing
Posted on:
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.
Communication / Product Management / Requirements / Software requirements specification / Writing
Posted on:
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.
Requirements / Software requirements specification
Posted on:
Joel Spolsky Speaks Specs
It seems that specs are like flossing: everybody knows they should be writing them, but nobody does.
Another for the wish I had said that list. Joel Sposky wrote a four part series on writing functional specifications in Oct 2000. Joel’s opening position is that all projects lasting more than a week, or with more than one developer, will be completed faster with specs than without them. He presents three giant reasons to use a requirements document as part of developing software
Three Giant Reasons
Product Management / Requirements / Requirements gathering / Use Cases
Posted on:
Challenging Requirements
The hardest long term challenge in eliciting requirements is improving our ability to do it. The hardest short term challenge in gathering requirements is getting all of them. We have a lot of techniques for gathering requirements, from interviewing to brainstorming to researching. How do we know we defined all of the requirements? Everyone who manages requirements knows the value of validating requirements. But validation leaves a blind spot as it looks backwards instead of forwards. We propose to do exactly the opposite.
Process Improvement / Project Management / Software development / Use Cases
Posted on:
Where Did You Get That Estimate?
How good are our estimates? We can use PERT to estimate the time it will take to implement each requirement. We can use timeboxes to schedule the requirements within each release. If we don’t know how good our estimates are, its an exercise in futility. Scheduling is about more than predicting the future, its about knowing how much faith to have in our predictions.
Communication / Consulting / Product Management / Requirements / Software development / Testing / Use Cases
Posted on:
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.
Agile / Interaction design / Process Improvement / Product Management / Requirements / Requirements management software / Software development / Use Cases / UX
Posted on:
Gartner research on Agile Requirements Definition and Management (RDM)
Gartner has a research report available for $95, titled Agile Requirements Definition and Management Will Benefit Application Development (report #G00126310 Apr 2005). The report is 7 pages long and makes an interesting read. Gartner makes a set of predictions for 2009 about requirements definition and management (RDM) systems, and the software created with RDM tools. Gartner misattributes several benefits of good process to RDM tools. We give them a 3.5/7 for their analysis – check out the details here.
Agile / Communication / Consulting / Process Improvement / Project Management / Requirements / Software development / Use Cases
Posted on:
Scheduling requirements changes – part 1
Software product success requires timely delivery. There are many factors that influence our ability to properly scope, schedule, and deliver software. When we propose changes in requirements we introduce risk to the schedule. We can set reasonable expectations for our stakeholders while maintaining a realistic work environment and schedule. In part 1 of this post we detail a requirements triage process that organizes requirements by complexity and allows us to set and meet expectations of delivery.