Lists / Product Management / Requirements / Software requirements specification / Writing

Writing Good Requirements – The Big Ten Rules

Posted on:

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.

Process Improvement / Requirements / Software development / Testing

Non-Functional Requirements Equal Rights Amendment

Posted on:

We know how to deal with functional requirements. We know they are important – we can walk the dependency chain from goals to use cases to functional requirements. But how do we get to the non-functional requirements? Leathej1 points out the elephant in the room – non-functional requirements don’t get enough attention when it comes to testing. Let’s look into it some more…

Communication / Consulting / Interaction design / Product Management / Requirements / Requirements gathering / UX

Requirements Gathering – Interviewing the Right People

Posted on:

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.”

Communication / Product Management / Requirements / Software requirements specification / Writing

Requirements Documents – One Man’s Trash

Posted on:

…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.