Learn from an early mistake of mine At a previous employer, the first time I played the role of requirements manager (technically, program manager – with responsibility for the functional spec), I made a bunch of mistakes – this post is about one of them. The setup We were engaged […]
From MRD to PRD: The key to defining a spec
They key to writing a great spec is knowing how to specify software that mets our customers’ needs. It can be a daunting task. First, we have to define what our customer needs. High level requirements are just requirements that are too vague or high-level to be directly actionable. “We […]
Where Bugs Come From
In the Foundation series article on software processes we introduce a definition of software process as three steps – (decide, develop, deliver). That article will provide some contextfor this discussion, which dives more deeply into the three steps (decide, develop, deliver).
Requirements Document Proliferation
Too many companies don’t document their requirements.
Worse still, too many companies over-document their requirements.
Prioritizing requirements – three techniques
Now that we’ve gathered all these requirements, how do we determine which ones to do first?
The less we know about our client’s business, the more the requirements appear to be equivalent. We’ll talk about three different approaches to prioritizing requirements.
1. Classical. Let stakeholders assign priority to the requirements.
2. Exhaustive. Explore every nuance of prioritization and its application to requirements.
3. Value-based. Let ROI drive the decisions. (hint: this is the best one – scroll down if you’re in a real hurry)
4. [bonus]. A look at how 37signals prioritizes features for their products.
Brainstorming – Making Something Out of Everything
Previously, we talked about brainstorming as one of the best elicitation techniques for gathering requirements. Here are some details about how to facilitate a general brainstorming session with a group of people in 5 easy steps (and then another 5 easy steps). Seven to ten people is a good number […]
How To Interview When Gathering Requirements
We previously stressed the importance of understanding why something is a requirement. Unfortunately, we can’t just ask “why why why?!” until we reach the end of the chain. This won’t be any more effective for us now than it was when we were in kindergarden. Eventually, our listeners will get frustrated, or worse, defensive.
Top Five Requirements Gathering Tips
Interviewing, Brainstorming, Documenting Use Cases, Prototyping, and Analyzing Documents are our top-five tips. Read more for details
Are people reading your requirements? A blogversation.
Tony just put up a post at Seilevel’s blog on making sure your spec is reviewed. Kent Newsome recently posted about starting cross-blog conversations here, possibly inspired by Amy Gahran’s post about it here. Tony’s post is a great topic to cross-blog about. Three easy steps to blogversation Post your […]