Requirements: Knowledge and Understanding

Posted on:

[photo by Henkster] Writing good requirements is more than just about following a set of rules. You can capture knowledge about your goals and your product with a set of well crafted requirements. But to truly write good requirements, you have to gain a level of understanding that surpasses knowledge. […]

Use Case Driven Documentation

Posted on:

Yesterday we wrote about focusing our documentation on what our users are trying to accomplish. With a structured requirements approach, or with an interaction-design driven approach, we’ve already solved half the problem – determining what to document.

The Impact of Change and Use Cases

Posted on:

Market requirements change. These changes impact the use cases that support the changing requirements. Functional requirements change. These changes impact the use cases that they support. How can we leverage use cases to manage these changes? And how can we manage changes to use cases?

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…

Non-Functional Requirements List

Posted on:

Marcus is building a great reference on non-functional requirements at From Start to End. He’s created a series of articles, and keeps adding more. Each post focuses on a single type of non-functional requirement. He just put up an index page for all of his posts, and he’ll be keeping that page updated as he adds more content.

Communicate Relevant Quality Metrics

Posted on:

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.