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 […]
Top five presentation tips
From Start to End has a great post, Some tips on presentations. Very little we can add here – check it out. Our top five presentation tips (our first four picks are from the list behind the link) Know your audience. A key preparation – you have to have a […]
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).
Software testing series: A case study
This post is a test automation case study, but at a higher level.
We’ll talk about it in terms of defining the problem, and then discuss the objective (what we proposed to do to solve the problem), the strategy (how we went about doing it) and the tactics (how we executed the strategy). Since this happened in the real world, we’ll also identify the constraints within which we had to operate.
Requirements Document Proliferation
Too many companies don’t document their requirements.
Worse still, too many companies over-document their requirements.
Foundation Series: Unit Testing of Software
Testing software is more than just manually banging around (also called monkey testing) and trying to break different parts of the software application. Unit testing is testing a subset of the functionality of a piece of software. A unit test is different from a system test in that it provides information only about a particular subset of the software. In our previous Foundation series post on black box and white box testing, we used the inspections that come bundled with an oil change as examples of unit tests.
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 […]