Interaction design, as described by Alan Cooper in The Inmates are Running the Asylum, is a process for designing software by focusing on the most important users. Unlike traditional requirements gathering and solution design processes, interaction design focuses on the goals of a specific class of users, represented as a persona. Those goals are considered when defining scenarios that represent how the primary persona will use the software. The combination of goals and scenarios leads to design artifacts and a functional specification. We will explore these steps in more detail in this post.
Software design and specification and making movies
Alan Cooper presents the analogy that software development is like making movies in his book, The Inmates are Running the Asylum. Cooper is presenting the analogy in the context of validating the business case for investing in interaction design, but it holds true for requirements as well.
Definition of payback period
We’ve talked previously about using ROI to determine which projects to fund. This isn’t the only way to make those decisions, as Ski points out with the concept of flush. Payback period is the measure of how quickly an investment returns the invested amount, or the break-even point in the investment.
Software testing series: Pairwise testing
Very large and complex systems can be very difficult and expensive to test. Often, we inherit legacy systems with multiple man-years of development effort already in place, in the field and of unknown quality. With these systems, there are frequently huge gaps in the requirements documentation. Pairwise testing provides a way to test these large, existing systems. And on many projects, we’re called in because there is a quality problem.
Organizing a software migration project
In an earlier post on requirements for migration projects, we defined a continuum of migration projects, ranging from completely new business processes to identical processes. In this post we will look at why companies approve identical-process migration, or duplication projects, and provide some tips on how to organize these projects.
We must sell the software first
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.
Managing scope creep is not a zero-sum game
We’ve never had a project where we didn’t have to address scope creep. As a supplier, we prioritize loyalty and relationships above incremental profitability. Project management techniques for addressing scope creep do us a disservice by starting with the presumption that resources have to be managed in a zero-sum game (every new feature must displace an existing feature). In this post we will talk about the opportunity to strengthen the relationship with our customer as part of addressing scope creep. It is not a zero-sum game.
What CMMI level should we use?
The CMMI (Capability Maturity Model Integration) of a software development process is the measure of that process’s capability. The goal of the measurement is to provide an assessment of the capability of a process with respect to creating software. Our foundation series post on CMMI provides background information, while this post focuses on the danger of misusing CMMI ratings.