Lists / Prioritization / Project Management / Requirements / Software requirements specification

Prioritizing requirements – three techniques

Posted on:

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.

Communication / Consulting / Lists / Presentation / Process Improvement / Requirements / Requirements gathering / Software requirements specification

Brainstorming – Making Something Out of Everything

Posted on:

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 […]

Communication / Consulting / Requirements / Requirements gathering / Software requirements specification

How To Interview When Gathering Requirements

Posted on:

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.

Polls / Requirements / Software development / Test Automation / Testing

Software Testing Series: Black Box vs White Box Testing

Posted on:

Should I use black box testing or white box testing for my software?

You will hear three answers to this question – black, white, and gray. We recently published a foundation series post on black box and white box testing – which serves as a good background document. We also mention greybox (or gray box) testing as a layered approach to combining both disciplines.

Given those definitions, let’s look at the pros and cons of each style of testing.

Foundation series / Polls / Process Improvement / Software development / Test Automation / Testing

Foundation Series: Black Box and White Box Software Testing

Posted on:

Blackbox tests and whitebox tests.
These terms get thrown about quite a bit. In a previous post, we referenced Marc Clifton’s advanced unit testing series. If you were already familiar with the domain, his article could immediately build on that background knowledge and extend it.

Software testing can be most simply described as “for a given set of inputs into a software application, evaluate a set of outputs.” Software testing is a cause-and-effect analysis.