Requirements Gathering: A Step By Step Approach For A Better User Experience (Part 1)

A great user experience is all about enabling users achieve their objective when using your artifact – be it a website, a software system or anything that you create. Now take a step back. Trying to understand how to make it easy for users to achieve their goals would be pointless if you don’t place it within the context of what you know about your users. The more you understand your users, their work and the context of their work, the more you can support them in achieving their goals – and hence, the more usable your system will be! So, you inevitably ask the question “how would I know what my users’ needs are?” This article is about requirements gathering … and it answers this question.

What are Requirements?

A requirement is a statement about an intended product that specifies what it should do or how to do it. For requirements to be effectively implemented and measured, they must be specific, unambiguous and clear. For example, a requirement may be that a specific button must enable printing of the contents of the current screen.

Diagrammatic representation of the different types of requirements (Source: SatheesPractice)

Since this article focuses on requirements gathering of systems, we will focus on the two types of System Requirements:

1. Functional Requirements

Functional requirements specify the software functionality that the developers must build into the product to enable users to accomplish their tasks,thereby satisfying the business requirements. In simpler words, functional requirements state what the system must do. In fact, functional requirements are usually stated by using the “shall” statement. For example, “the website shall notify the administrator via email when a user registers with it”

  • Business rules
  • Transaction corrections, adjustments
  • Administrative functions
  • Authentication
  • Audit tracking
  • External interfaces
  • Certification requirements
  • Reporting requirements
  • Historical data
  • Legal / Regulatory requirements

2. Non-Functional Requirements

Constraints or standards that the system must have or comply with. Non-functional requirements define the system’s quality characteristics. As a rule of thumb, non-functional requirements generally end with “ity”, although not all of them do.

  • Scalability
  • Capacity
  • Availability
  • Reliability
  • Recoverability
  • Maintainability
  • Serviceability
  • Security
  • Regulatory
  • Manageability
  • Environmental
  • Data Integrity
  • Usability
  • Interoperability
  • Performance
This diagrammatic representation of non-functional requirements shows how they are related (Source: Robinsce)

The Iterative Nature of Requirements Gathering

In an ideal world, one would simply gather data related to user needs, analyse it and then elicit the user requirements. However, this is a very simplistic view. In the real world, user requirement gathering is an iterative process whereby each of the above steps influences the other. For example, when trying to set a particular user requirement, you realise that it is not very clear if the user really wants what you think they want. Therefore, you may opt to gather more data as a means to clarify this ambiguity. In addition to this, you will realise that the requirements themselves evolve as stakeholders interact with the prototypes that you develop based on your initial requirements gathering. What follows is a practical 3-step approach on how to gather data from your users and convert this data into system requirements.

Step 1: Gather Data From The Users

At this early stage, do not restrict your definition of users to the actual users of your system. Instead, widen it to include a sample that represents each stakeholder.

The famous cartoon entitled “Project Cartoon” captures the sad reality behind bad requirements gathering (Source: ProjectCartoon)

Very often you will find that actual users will help you formulate functional requirements. However, the non-functional requirement will usually come from other stakeholder groups such as the people who are providing the funding of the system. For example, financial controllers would be interested in the scalability of the system since if the system is scalable, then adding more functionalities to it will not involve throwing away the current system.

According to Jenny Preece and Helen Sharp, in their book Interaction Design: Beyond Human-Computer Interaction , data gathering can be done using the following conventional techniques:

  • Interviews: Interviews are good for getting people to explore issues. Semi-structured or unstructured interviews are often used early on to elicit scenarios. In the context of establishing requirements, it is equally important for development team members to meet stakeholders and for users to feel involved. This on its own may be sufficient motivation to arrange interviews.
  • Focus Groups: Focus groups are ideal for establishing a consensus view and highlighting areas of conflict and disagreement during the requirements activity. On a social level it also helps for stakeholders to meet designers and each other, and to express their views in public. It is not uncommon for one set of stakeholders to be unaware that their understanding of an issue or a process is different from another’s even though they are in the same organization.
  • Questionnaires: Questionnaires may be used for getting initial responses that can then be analyzed to choose people to interview or to get a wider perspective on particular issues that have arisen elsewhere. Or the questionnaire might be used to get opinions and views about specific suggestions for the kind of help that would be most appreciated.
  • Direct Observation: Observation of participants in their natural setting is used to understand the nature of the tasks and the context in which they are performed. Sometimes the observation is carried out by trained observers who record their findings and report them back to the design team, and sometimes the observation is carried out by or with a member of the design team.
  • Indirect Observation: Diaries and interaction logging are used less often within the requirements activity. Interaction logging on an existing system may be used to provide some data about how a task is performed currently, but the information is too tightly coupled with details of the existing computer support to be particularly helpful if a completely new system is planned.
  • Studying Documentation: Manuals and other documentation are a good source of data about the steps involved in an activity and any regulations governing a task. Such documentation should not be used as the only source, however, as everyday practices may augment them and may have been devised by those concerned to make the procedures work in a practical setting. Taking a user-centred view of development means that we are interested in the everyday practices rather than an idealized account.
  • Researching Similar Products: By observing and analyzing similar products, it is very easy to establish the requirements of your own product

So, which data-gathering technique should you choose? There is no right or wrong answer here. The above techniques have their own pros and cons. For example, interviews are ideal in order to gather data from smaller groups while questionnaires are ideal to gather data from a geographically spread user base. Other forces that come into play are the nature of the task, the participants, the analyst, the resources that are available and a multitude of other factors. Thus, you may find yourself combining more than one of the above techniques in order to be able to interpret data that is unclear.

End of Part 1

This brings us to the end of Part 1 of this article. In Part 2, we will see Steps 2 and 3 which discuss how the user data that has been gathered in Step 1 can be analyzed in order to understand user needs. In Step 3, this analysis is used to elicit the set of requirements that the system must have – thus completing the requirements gathering process.

  • Darcy Voutt

    Very good article. Really looking forward to the other parts to this series!

  • Durgaprasad Nakka

    Very Useful Article Great Job

  • Pingback: Requirements Gathering For Better User Experience Pt2 - Usability Geek()

  • mohamed khan

    Very useful information Justin..keep it coming mate, Good job.

  • Terry McCann

    Great article. Could you look to add a better print css to the site.

    When you print this page a lot of guff is included.


    • Justin Mifsud

      Hi Terry,

      Thanks for the nice comments. If you click on the last button in the sharing tool bar (where there is written ‘Share the knowledge’, it will load a printable version of the page. You can then click on the different sections (and images) in it to remove the parts that you don’t need. Hope this helps!

      • Terry McCann

        Ahhh! Sorry I missed that! Thank you that is great!!

        • Justin Mifsud

          It’s ok. Unfortunately it is not that immediately visible and there doesn’t seem to be a setting that makes those icons visible all the time. Will need to research a bit into it. But until then, glad that you found the feature useful.

  • Amanda

    Great article! Thanks so much for putting this together!

  • Mabweh Isaac

    Thanks for this :).. I am a Developer.. I would like to know an example of Functional Requirements if I am to design a Bluetooth Ear Piece device?

    • nat

      The device shall interface with the all blue tooth supported Android OS devices.

  • Adam Gorbahn

    Great article and great key points on requirements.

  • sonnieblogs

    Thanks, very clear and concise write-up on the subject of requirements gathering.