Recently, I retweeted an item from Neil Killick and I was surprised to see a response from Tom Gilb, legendary software methodologist. The tweets can be viewed in the picture below (read from bottom up).

Two tweets, my retweet and Tom Gilb's reply

Talking to Tom

Apart from the honor of getting some of his attention, I was a bit concerned with the response. I seemed simplistic and categorical to me. Quite frankly, it sounded like something out of a schoolbook in software engineering from the 80s. I find myself in disagreement with it. To disagree with Tom Gilb is scary so I needed to write down why.

To me, one (wo)man’s “what” is another (wo)man’s “how”. To me, they’re two sides of the same coin. At least in software.

Let me explain.

Our job as software developers is to identify deep needs from users and other stakeholders and, in an iterative process, design and deliver solutions that satisfy those needs. This has been increasingly clear over the last decades with the Agile movement, the User Experience (UX) school, Lean Startup, focus on effectiveness over efficiency, developing the right thing beats developing the thing right, etc. The basic “what” here does not concern features in software but this:

What are our users trying to accomplish?

Software is one way of satisfying that need and there are an infinite number of ways to do it in software. The basic “how” here is this:

“How can we help them reach their goals using software?”.

An infinite number of solutions, no “best way” – only more or less useful, a need for an iterative process are all tell-tale signs that we are in design land. Hence, creating and iteratively adapting a software solution is, at its basic level, a design activity.

Well, what about features then? The most important design decisions concern whether a feature should be included or not. These decisions form the base of the user experience (but only the base). Including, refining and removing features are, or should be, easy to do in software. Being malleable is software’s main characteristic. That’s why it’s called software. One could call this form of design Functional Scope Design and Steve Jobs was the uncrowned king of it.

This breaks with traditional thinking and especially the views of many in the requirements community. I find the mental model of “managing requirements” quite damaging. Very few things in software are truly required. In most projects, there are none. Horrid language expressions like “a should-requirement” is a giveaway that the model doesn’t quite fit. I now believe the whole requirements movement was a step in the wrong direction. The word “requirement” is wrong almost all the time and the typical methods employed are not suitable to the problem.

I don’t know about you, but personally I find it more useful to focus on designing the right solutions for users in their context instead of worrying about what is “required”. Try it! It’s a liberating thought.

That is what I mean when I say that there are no real requirements, just unfulfilled needs and unwritten software for them.

Functional Scope Design: Why requirements must go and design for use should take its place

7 thoughts on “Functional Scope Design: Why requirements must go and design for use should take its place

  1. This was a very refreshing read and fits well with how the ISO defines usability; “The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use.”. Software is the product and we need methods to learn about users goals and their context and collaborate on designing it.

  2. I have long been wondering why requirements should be the base for test design. If I do a great visual test design – hat actually clarifies what is needed and shuld therefore replace the originl usually badly written text. Because requirement people seem to really fond of their textual descriptions.

    Now here is the new idea that this post inspired me to clarify. Creating the visual models of what should be build or is needed should be a collaborative work done by users/ domain exoerts, testers, architects, UX people and developers (or whatever you called the people you work with). That would be taking the specification by example idea one step further.

    We should talk about cross conferencing with all of the current roles we think should be collaborating on these ideas!

    • Glad to hear you were inspired, Tobbe!

      Yes, why not? I think some things we need to agree on for a feature across the team are inherently rule-based => executable specifications. Other things are more visual/interactive in nature => wireframes, clickable prototypes (and similar). The beauty of cross-functional teams is that you have all these experts at hand, willing to work with each other for the best result.

  3. Excellent post that talks to the very heart of design, use of software and solutions to challenges within a business context.
    In my work as an architect I use domain concepts with behaviour to express a more functional aspect of a domain and many different kinds of models to illustrate various ways of interacting.

    If a team comes up with a software based solution we take the same approach: understanding a domain by expressing it in some comprehensive style, we ask questions and make observations about behavior and interaction. Then we design iteratively and make use of many best practises. So we try not to talk about and/or work with requirements but more around a solution or many solutions. The analysis part is the same but more as an activity in design.

  4. Pingback: Shifting conventional thinking to the right

Comments are closed.