Prioritization / Requirements / Requirements gathering

Vote Early And Often – Getting Value From Brainstorming

Posted on:

Brainstorming can be a simultaneously fun and effective technique for identifying software features or requirements. We’ve written previously about how to facilitate a brainstorming session and how to leverage the results. Timothy Johnson shares another way to use the results effectively. His way is more fun, and maybe just as effective.

Consulting / Process Improvement / Product Management / Project Management / Requirements / Software development

How To Use Timeboxes for Scheduling Software Delivery

Posted on:

Roger had a great suggestion in the comments to our previous two-part post on scheduling requirements changes based on complexity. Roger pointed out that we had not explained what timeboxing is, but implicitly used the principles of timeboxing in our proposed process. In this post, we explain timeboxes and how they are used.

Expert systems / Requirements / Requirements gathering / Software development / Software requirements specification

Expert systems – do what I say, not what I should have said

Posted on:

We’ve studiously avoided talking about requirements for expert systems because it is such a small niche of software development. Please let us know in the comments on this post if this is an area you would like to read more about. This post is both a discussion of the main barrier to success for these systems and an introduction to future posts if you ask for them in the comments on this post. Expert systems, or AI programs can solve some of the hardest problems. Yet AI software has not dominated the software landscape, neither Heinlein’s nor Vinge’s fictions have become real. Why has AI software failed? It isn’t that the hardest problems are too hard to solve, it’s that they often don’t need to be solved at all.

Agile / Interaction design / Requirements / Requirements gathering / Software requirements specification / UX

Interaction design explained by Alan Cooper

Posted on:

There’s a Clash of the Titans joint-interview posted at FTPOnline between Kent Beck and Alan Cooper called Extreme Programming vs. Interaction Design. It’s 10 pages of back and forth. In short, these icons agree on objectives, and disagree on how to achieve them. They also spend some time (mis)characterizing each other’s positions and defining their own. In this post we will look at how Alan Cooper explains Interaction Design. We would say that he defines interaction design more as a requirements than a design activity.