3. Requirements and specification

3.01 Introduction

Requirements vary depending on the target audience. While an average person may require around 2000 Calories per day, a competitive power lifter may require substantially more. When thinking about requirements, we need to consider the broad spectrum of possibilities.

In the case of systems, we generally describe actions in the form of use cases. We assume a user wants to achieve something with our product and consider the steps necessary to achieve that goal. We also think about which steps or tasks are more important than other, which can be deferred or cancelled.

We need to consider all these details in order to provoke further considerations. One way to define requirements is as a need or desired outcome for or from a system.

If we’re designing a payment system, it may be required to process transactions or accept certain payment methods. Requirements can be specified using formal documentation with a discernible outcome.

In order to write these, we must first a good formal understanding of what we’re trying to achieve, only then can we specify requirements in a measurable manner.

The process that underpins this is referred to as Specification. One way to create specification is through modelling techniques such as UML, or Unified Modelling Language.

UML offers several benefits for specifying systems. For example, we get a visual representation of the relationships between entities or objects within our system, for example something like this:

UML has several types of diagrams, for example Use Case Diagrams and Class Diagrams, which are the most commonly used.

3.02 Why do we gather requirements?

Gathering requirements helps us understand the scope of the project. Moreover, requirements help us with:

• specifying things that can be measured and tracked
• keeping all stakeholders in the loop
• formalising contracts and legal obligations
• defining complex relationships and systems in a meaningful way

In terms of specifications, there are two main categories:

• Functional – concerned with the ability to perform certain actions
• Technical – concerned with the manifestation of a system to achieve said outcomes

Both types of specifications describe a set of actions, intentions, systems and outcomes. But functional is more about what our stakeholders want, and technical is more about exactly how that is achieved. eg:

Functional – I need to get from A to B
Technical – we need to define a route, mode of transport, etc

3.03 Modelling requirements

The Unified Modelling Language (UML) uses a set of standards by which we can model (or define) a system in terms of interactions, inputs, outputs, users etc.

UML encompasses a wide variety of techniques and diagram types.

The two most common UML diagrams we may see are:

• use cases – which describe the way a user engages with a system
• class diagrams – which describes the overall architecture

3.03.1 Use Cases

These define a set of actions included to achieve a goal or intention.

The goal is a main success scenario. A user wants to achieve something and follows a series of steps.

You can describe this with a diagram, or just list the steps.

3.03.2 Class Diagrams

These describe classes or objects, defining their attributes and/or operations.

They are good for defining relationship between objects in a system, and some explicit structure.

They can describe more complex relationships like dependencies and abstraction.

Attributes describe features or characteristics. eg your hair colour or height.

Operations describe more functional aspects. eg writing code, reading a textbook.

Some of these might be unique to you, some might be shared with other people.

Monday 25 October 2021, 518 views

Next post: 4. User-Centred Design
Previous post: 2. Tracking progress