requirements – In Search Of

Information Driven Projects

Posted on February 10, 20152 Comments

When you look at software development or corporate change projects, you often see some creative fiction. There is fiction in the plans, fiction in the designs and fiction in the requirements. This fiction is created by the notion that “Before we can start, we have to know everything required to get to done.”

Intuitively, we all know that this is not really true. We all know that information will “emerge” from our activities that will change how we get to done. We learn from our mistakes. We try things that don’t produce as good a result as we want. We clarify our understanding of the problem as we demonstrate portions of the solution.Continue Reading

Feats Instead of Processes

Posted on May 13, 2014Leave a comment

In my last post on Software Capabilities and Feats I said that feats are better [to model in a software capability] than processes, because processes are merely organized, consistent, managed ways to accomplish the feat.

A process is one way to accomplish a feat. The feat is the result you want.

Process is constrained by capabilities. So when I am modeling new capabilities, I should not be constrained by existing capabilities. When I introduce the new capability into the wild, the process will need to “re-form” around the new capability.

A process has steps. If we build software capabilities to support a process, we treat the steps of the process like “feats”. I can model a capability to make that step faster or more effective. That assumes that the step is necessary. In order to decide whether a process step is “necessary” I need to understand how it contributes to the valuable result. I need to understand why I do the step.Continue Reading

Software Capabilities and Feats

Posted on May 6, 2014Leave a comment

In some recent conversations, I find that it is hard to explain the notion of a capability. People want to talk in terms of software features or project requirements.

Software capabilities define value in the following ways:

enabling the user to accomplish a “feat” in less time than they otherwise would.
enabling the user to accomplish a “feat” at a greater scale than they otherwise would.
enabling the user (or a group of users) to accomplish a “feat” more effectively than that they otherwise would.
enabling the user to accomplish a “feat” that he could otherwise not accomplish at all.
enabling the user to accomplish a “feat” better than he otherwise could.
enabling the user to focus on “feats” that require decisions, rather than repetitive steps.

Every other benefit of software can be composed from these.

To define value, a software capability must contemplate (model) the “feat” that the user wants to accomplish.Continue Reading

System Replacement Assumptions

Posted on April 15, 2014Leave a comment

I am in the middle of my umpteenth system replacement project. There are some universal assumptions that are endemic to the user community in every system replacement project. They are born of hope and frustration. They are almost universal.

1) The new system will do everything the old one does, only better.
2) The new system will support all of my existing processes and procedures without significant change.
3) The new system will be faster that the old system.
4) The new system will have better data quality than the old system.
5) The new system will address ALL of the shortcomings of the old system.

If you have ever done one of these projects, you know. They are assumptions that you must actively work against. They require a constant stream of communication to dispel. I offer you my rationale for why they are never, ever, true.Continue Reading

Smaller Bets (Story Elaboration Pushback)

Posted on April 1, 2014Leave a comment

It is always better to spend the least amount of (time, effort, money) to get what you want, right? If I can get a tasty meal for $10 why

McD's Dollar Menu Combo - Buffalo Ranch McChicken + McDouble with Coke = $3.64 — McD’s Dollar Menu Combo – Buffalo Ranch McChicken + McDouble with Coke = $3.64

would I pay $30 or $200 – for the experience of eating – that isn’t about taste. That is a different thing, isn’t it. We have different priorities for eating – being full, healthy, tasty, being served, fast service, being able to relax, a pleasant experience, being able to brag about my meal/experience. Each of these is a different reason for selecting a dining experience. Each of them is valuable to some people some times, but not all people all the time. The way we choose to spend our money to eat is not that different than the way we choose to spend our money on software capabilities; there are different reasons why we prefer one capability or a means of delivering a capability over others.

These are the principles that I use to guide my story elaboration – and thus my ability to challenge those who would ask me to do more than the minimum…Continue Reading

Packing The Box

Posted on March 25, 2014Leave a comment

Do you remember the last time you moved? Do you remember packing some boxes so full, that they were too heavy to lift after you were done? It happens. Especially books and vinyl records. When you are packing “regularly shaped” high density items, the volume of the box may be too large to contain the weight of the items. Or it may be that the lifters (I mean you) may not have enough momentary work capacity (strength) to carry the box.Continue Reading

Better User Stories

Posted on March 4, 2014Leave a comment

While I will not claim to be an expert at writing user stories, I am experienced. It is not always enough to simply follow the pattern. Like any analysis pattern, there are some things that one can do to improve their stories. Continue Reading

The Appeal of User Stories

Posted on February 25, 2014Leave a comment

I have been “doing” user stories for a while, years now. I have been doing them mechanically without thinking about what makes them “good”. Not that I haven’t been working to make them better with each release on every project. My user stories have consistently grown better following the INVEST pattern. What I haven’t been thinking about is “why” user stories and the process through which we create them is good.Continue Reading

Connecting the Boxes

Posted on January 7, 2014Leave a comment

2013 was the year that I finally decided to replace my ancient two channel sound system with a 5.1 channel home theater capable system. My old setup was very simple. A pair of ADS speakers that I had bought when I was in college (1981) and a Nakamichi receiver that I had bought shortly after I was married (1989 or so). I had other components, but most had been replaced with a cheap Blu-ray player that I “won” at a silent auction a few years back that played most of my CD’s. I still have a B&O turntable that is serviceable, but I rarely play my vinyl these days.Continue Reading

Progressive Requirements Elaboration

Posted on October 16, 2012Leave a comment

In my former post about progressive elaboration, I promised some “examples” from different domains of software development. This is the first of these. As I said before, progressive elaboration is about acknowledging that we can’t know everything we need to get to done before we start.

One of the difficulties of requirements elicitation is to maintain a consistent level of detail, both in documentation and in our conversation with practitioners, subject matter experts, and individual contributors. Another typical difficulty is understanding whether requirements are sufficient to begin some subsequent activity like design or coding.

While some methodologies have made recommendations, most merely call out the need. This leaves it up to the requirements analyst to build their own practice. In fact, most analysts do not subscribe to any specific methodology that they practice. I have often used these interview questions for analysts that I expect to elicit and organize requirements for software applications.Continue Reading