September 08, 2019

Requirements Gathering. What you need and how do you know you need it?



This picture exemplifies the need for requirements gathering and understanding the tasks involved in avoiding a weather related catastrophe. My wife and I decided on an after dinner drive where we ignorantly thought the sunset and storm were quite striking and distant. We took a detour to explore.

  1. We are city-folk and did not know the regional weather conditions.
  2. We did not know the local radio station to check for weather conditions.
  3. We did not know we would eventually drive perilously close to a tornado.

What does this have to do with requirements gathering?


  1. The users (my wife and I) did not understand how to read the sky interface
  2. The users did not understand the necessity of weather reports.
  3. The users did not comprehend the severity of Summer high desert weather conditions.

What should the users have done?

  1. Perform an internet search on local weather conditions.
  2. Speak with established residents about the weather.
  3. Listen to the local radio station for emergency weather alerts.
  4. Pay attention to sudden changes in the wind and barometric pressure (you can feel this).
  5. Notice the roadside livestock. They know when to seek shelter and are never out when there is the potential for bad weather.
  6. Respect and fear nature.

This seems to miss the point. What about software development? That is what I care about.

Software development or product development necessitates information that is not obvious to those implementing the request.

Albert Einstein once said: "You can't solve a problem with the same thinking that created it."

  1. A developer will impart her biases on the project if no guidelines are established.
  2. These guidelines need to be effective and not avoided.

Alan Cooper's The Inmates are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity, provides some guidance:

Directed Goal Design:

Cooper discusses a mnemonic technique to anthropomorphizing the user's requirements in what we refers to as a persona. From his book:

  • Persona are not real people, but they represent them throughout the design process. They are hypothetical archetypes of actual users.
  • This requires the requirements gatherer to develop a precise description of our user and what he wishes to accomplish.
  • Ideally one should design for just one person.
    • This is specious as that one person needs to represent a large enough subgroup for a viable product.
    • A mass produced car that was sole designed for Lewis Hamilton might not be appropriate for 99.999 percent of the driving population.
  • This design philosophy has merit since Every time you extend the functionality to include another constituency, you put another speed bump of features and controls across every other user's road.
  • Trying to please too many different points of view can kill an otherwise good product.
  • Having people love your product, even if it is only a minority, is how you succeed.
  • Success is ensuring 100% of the subgroup you target is happy.
  • It might seem counterintuitive, but designing for a single user is the most effective way to satisfy a broad population. Provided that user falls within a viable group.

 The roll-aboard Suitcase:

The Roll aboard Suitcase demonstrates how designing for a specific user can lead to success:

Per the FAA:   There are more than 44,000 flights per day.  If the average flight crew is at least 3 persons we have a minimum of 132,000 customers which is a good target user audience.

By narrowing your focus, you can generate fanatical customer loyalty in your target market.

But which is better. Selling 1 million widgets at $10 or 100,000 widgets at $100? 1 million fanatics might prove to be more fickle than 100,000.

The elastic user:

The elastic user must bend and stretch and adapt to the needs of the moment.

Software should be able to bend and stretch to the user's needs

Designing for the elastic user gives the developer license to code as he pleases while paying lip-service to "the user."
Real users are not elastic.

personas lose elasticity as they become specific

Personas are articulated with detail and precision.

A persona without a name is simply not useful.

Without a name a persona will never be a concrete individual in anyone's mind.

Stereotypical personas are more effective if the stereotyping lends more credence to the persona.

If my persona is a nurse, I will use a woman rather than a man, not because there are no male nurses, but because the overwhelming majority of nurses are female.

Believability can be a  better objective than diversity in some cases.

Until the user is precisely defined, the programmer can always imagine that he is the user. In the Rollaboard example, wheels would never be a component of a travel bag I designed since I prefer to carry my luggage.

a well-defined user persona is  an effective tool for interaction design.

The temptation to attribute specific capabilities to all users because one very real human exhibits them is strong, but must be avoided.

it is more important that a persona be precise than accurate.
That is, it is more important to define the persona in great and specific detail than that the persona be the precisely correct one.

It matters more that the persona is expressed with sufficient precision that it cannot wiggle under the pressure of development than it does that it be the right one.

Programming is defined by cases at the edge of the paradigm, design is defined at the center.

Averages have to be ruled out since  an average user is never actually average. No parent has 2.3 children. Specificity must be applied to the hypothetical user. e.g. Sam and Karen have 3 children

Personas should be unique for each project.

Oversimplified models of markets don't help with design problems.

Personas End Feature Debates.

Developers prefer to speak of the "user" rather than a named persona.

Programmer: "But someone might want to print it."
Interaction Designer: "But we are designing for Rosemary, not for 'someone.'"

Programmers become enlightened when they begin to refer to the needs of the personas.

Rejection of specificity i.e. not referring to the specific persona can lead to failure.

A frequent mistake is to design for someone close to the product, but who is not the actual user.

The negative persona. exists to helps us to understand whom we are we are not designing for.

Primary Personas

The primary persona is the individual who is the main focus of the design who must be satisfied, but who cannot be satisfied with an interface designed for any other persona.

Each primary persona requires a separate and unique interface.

The problem set is too large if we find more than 3 primary personas.

The cast of characters is not just a convenient phrase, but it becomes a physical— as well as logical—design tool.

Create 3 to 7 useful personas with on a single sheet of paper containing their names, pictures, job descriptions, goals, and often a telltale quote.


Karen Holtzblatt's comments on Contextual Design from The Human-Computer Interaction Handbook:

Contextual Design:

Contextual Design (CD) is a user-centered design process that takes a cross-functional team from collecting data about users in the field, through interpretation and consolidation of that data, to the design of product concepts and a tested product

It is a more user centered processes

CD is a step-by-step process for helping a team collect field data and use it for the purpose of defining and designing products, systems, websites, mobile devices, consumer electronics, and so on.

Using that consolidated data, CD helps the team to interact with the data to produce a high-level product or solution concept.

One cornerstone of CD is that it acts as a framework or scaffolding for putting structure into a part of the engineering process that is typically unclear: how to get to the most important requirements to drive the next version of a product or system.

In order to design a product that meets users’ real needs,
designers must understand the users and their practices.*

Designers may lack familiarity

Product design is fundamentally about the redesign of work or life practice, given technological possibility.

Contextual inquiry

field gathering techniques






A task model for purchasing an automobile: