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.
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
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.
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
- 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.
Want to learn more?
If you’d like to improve your skills in User Research, then consider to take the online course User Research – Methods and Best Practices. Alternatively, there is an entire course on Usability Testing which includes templates you can use in your own projects. Lastly, if you want to brush up on the basics of UX and Usability, you might take the online course on User Experience. Good luck on your learning journey!
(Lead image: Depositphotos)
