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.

Definitions / Project Management / ROI

Definition of sunk cost

Posted on:

Sunk cost is an expression representing the unrecoverable amount of money that has already been placed into an ongoing investment or project. It is one of the simplest, yet most commonly misused financial measurements of a project. We’ll learn how to avoid the most common mistake in project (financial) management, and how to survive when our boss makes the mistake.

Interaction design / Requirements / Requirements Models / Software development / Software requirements specification / Use Cases / UX

Interaction Design and Structured Requirements

Posted on:

subtitle: Wiegers and Cooper assimilated
Wiegers promotes structured requirements. Cooper touts Interaction Design. Both have great ideas. Both “wave their hands” at parts of the process. In this post, we’ll talk about how to combine the two philosophies to get the best of both worlds.

Interaction design / Prioritization / Software development / Software requirements specification / UX

How To Create Personas for Goal Driven Development

Posted on:

We mentioned the creation of personas in our overview of the interaction design process. In this post we will talk in more detail about how to create them. We will cover identification and prioritization of the personas, defining the corporate and personal goals for the personas, and creating the anecdotal stories that give each persona an identity against which we can make design decisions. Scenarios are also defined for the primary personas, which drive the creation of the functional requirements specification.

Design / Interaction design / Requirements / Requirements gathering / Software development / Software requirements specification / UX

Interaction Design Process Overview

Posted on:

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.

Definitions / ROI

Definition of payback period

Posted on:

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.

Foundation series / Software development / Test Automation / Testing

Software testing series: Pairwise testing

Posted on:

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.