Marketing / Requirements / Software development

We must sell the software first

Posted on:

We write a lot about value-driven prioritization of software requirements. It’s easy (when defining requirements) to forget that we have to sell the product before anyone gets any value from it. With internal use software for large companies (like enterprise software, intranets, erp systems), “sell it” means “get high user adoption rates.” High user rates are key to getting ROI when process-improvement is one of the targets of the software.

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.

Communication / Requirements / Software development / Software requirements specification

Software Requirements – Process and Roles

Posted on:

Our previous post, Requirements vs design – which is which and why, describes our position on which parts of the software development process are requirements-activities, and which parts are design activities. The debate among professionals about these distinctions is ongoing, and continues in the comments on that post. The length of the debate, combined with the skills of those debating demonstrates that it isn’t a black and white issue.

In this post, we will try and explore the reasons why this debate is ongoing. We will do that by exploring the symbolism of the terms involved, as well as the roles of different members of the software development team.