Requirements Gathering

Overarching Principles & Conditions

Requirements can be thought of as:

Wish Lists:

What is it that the business wants? This is often informed by industry best practice with regard to tools or functionalities that have been seen at other (similar) firms which could benefit the organisation. Even though all of the items on the business’s wish-list may not be financially practical or technically feasible, some of them can prove to be valuable and implementable. Such items are always worth capturing and noting.

Enhancements (Technical):

These are actual issues with internal systems that need to be fixed or enhanced, not only to improve user experience, but also to ensure that the quality of output is of a higher or better quality. As a result, technical enhancements, which are often primarily tool or system related, are critical for the business analyst to note and capture.

Capabilities (Technical):

Business or technical capabilities refer to what the existing tools are capable of delivering. On occasion, these capabilities can and do fail. Most times though, it is often within the scope of a BAU process to fix these issues. However, these fixes can also be brought into the domain of a project. The reason is often budgetary or because of alignment with the overall objective of an in-flight programme. This usually means that a more thorough-going job can be done and rigorous testing can be conducted, than if the fix were quickly implemented, e.g. as part of a BAU process. Often, temporary or tactical work-arounds are carried out pending the delivery of a strategic or long term solution.

MoSCoW can be used to prioritise all variations of requirements. MoSCoW stands for:

i.“Must Have” : These are requirements that must be fulfilled on the project. Usually, they are linked to deliverables on the critical path and are essential to the business. De minimis for the delivery to be successful.

ii.“Should Have” : These are ideal requirements that can benefit the business. They are often next in priority after “Must Have” requirements have been delivered. They are done if time permits resolution of more business needs.

iii.“Could Have” : These are optional requirements that do not necessarily have to be delivered but have some elements or components that could be potentially useful to the business, e.g. they may enhance user experience.

iv.”Would Have” : These are wish-list items that have no significant/material benefit, or are at best superficially useful, to the core objectives of the project. This last one is rarely used.

Requirements can either be functional or non-functional.

Functional requirements are, as the name suggests, functionality related, i.e. the type of component changes that have been made or are due to be made in a system. They also cover data inclusion or correction, script writing and code creation or changes in systems and databases, as well as system configuration definition or amendments.

Non-functional requirements are performance and quality related. They are softer requirements that have to do with timing (e.g. of batch jobs), security, user-experience, GUI enhancements of business systems etc.

10 Principles & Characteristics of (Good) Requirements

Every requirement should be:

1. Cohesive:

This means that the requirement should be sequential and specific. A cohesive requirement defines a single aspect of the desired business process or system.

2. Complete:

The individual requirement should not miss necessary or relevant information.  Additionally, the entire set of requirements should cover all complementary sub-requirements needed to fulfil the high level needs of the business (i.e. parent-child relationships).

3 .Consistent:

Each requirement should not contradict another requirement. The risk of not satisfying the consistency condition is that the development team could end up being asked to produce divergent or contrasting deliverables. This could lead to delays, costly mistakes, business complaints and dissatisfaction. In order to address this risk, it is important to link or cross-reference requirements and continuously sense-check them to ensure that they complement, rather than contradict, each other.

4. Modifiable:

Similar requirements should be grouped together to allow bulk modifications and an easy maintenance of alignment.

5 . Ownership:

Every requirement must have an owner. Often the originator is the owner and biggest beneficiary, but sometimes requirements can be relayed by 3rd parties. If possible, it’s always best to speak to the originator.

6. Correct:

The requirement should meet an actual business or system need. The only way to be sure of this is to first understand the context of the need, then the problematic business process, data or tool. This requires personal research and close engagement with a relevant domain expert. Finally, it is useful to ensure that their agreement with an outline of the issue/s is received e.g. by email. Note that incorrect requirements can still be implemented, but could result in a process or system that does not (or hardly ever) meets business needs.

7. Observable:

The requirement should define an aspect of the system that can be noticed or observed by a user e.g. system feature via its implementation architecture or its physical design. These aspects of a system should be defined separately as constraints.

8. Feasible:

A requirement should not be abstract and should be attributable to specific system components or features. The requirement can be implemented within the constraints of the project including the agreed upon system architecture or other implementation decisions.

9. Unambiguous:

The requirement should be written objectively such that there is only a single interpretation of its meaning by multiple and independent reviewers or audiences.

10. Verifiable:

It can be shown that the requirement has been satisfied or met by the final solution e.g. via inspection, demonstration, test or rigorous analysis by a user or independent party, e.g. internal audit.

Elicitation Methods I (Basic Workshop Principles)

Workshops are large-scale sessions with multiple stakeholders.

They are often run using brainstorming, PowerPoint or Excel presentations and many other methods of collecting knowledge from key business stakeholders or SMEs. This method can be highly efficient in terms of getting multiple inputs in one go or session. A disadvantage is that it can also be constraining for less vocal (and often less powerful) business or technology team members.

Therefore, it is best supplemented with one-to-one interviews, in order to ensure that every participant’s opinion is heard.

Elicitation Methods II (Basic Interview Principles)

Interviewing is a small-scale session (often one-to-one or at most one-to-two) with key knowledge holders within an organisation.

The essence of this is to mine their business expertise, then consider and reference it when presenting current and future state documentation. This can also reveal more about the solution that is meant to be designed or applied in order to solve specific business problems.

Elicitation Methods III (Basic Use Case Principles)

Developing use cases: A use case indicates how the user of a solution intends to interact with it post-delivery. It assumes a particular user-experience. A  use-case definition process often provides a scenario or context for the solution functionalities being developed or built.

The user or beneficiary of the requirement can either be internal (e.g. business team, senior management) or external (customers/clients, regulator etc.)

Documentation Methods & Principles