Skip to main content

Part 2: The Golden Thread – A Requirements Meta-Model

Introduction

In part 1 of this article we focussed on the higher-level requirements, often referred to as the business requirements, of objectives, benefits and stakeholder/user requirements and the relationships between them. In part 2 of this article we examine the lower-level requirements, sometimes referred to as the detailed, functional, or system requirements (I prefer the term detailed requirements as I think functional and system requirements have connotations that can be misinterpreted).

Requirements Types – Detailed Requirements

In this section we will explore the definitions and relationships between business rules, user, functional, non-functional, data, reporting, and transition requirements.

The diagram below offers part of the meta-model of these requirements and related entities.

nov15ewan1

Figure 2: A requirements meta-model

Business Rules

Definition:

A business rule is something that an organisation must or has decided it must adhere to.

Example:

A customer must have at least one contract account.

Possible source:

Constraints, user requirements, legislation and SMEs among others. If you are lucky enough, your organisation might have a business rules repository that may contain business rules you can reuse.

Relationship with other requirements:

A business rule could be seen as a type of constraint or a constraint that could generate several business rules. A business rule may also be a part of some user requirements.


Functional requirements

Definition:

A functional requirement is a requirement of a system to be able to do something on behalf of a user.

Example:

The system must be able to set up a monthly direct debit of £10 for customers on the basic contract.

Possible source:

These could be derived from verbs contained in user requirements, use cases, scenarios, and potentially the existing system if it is a brown field project.

Relationship with other requirements:

Functional requirements have an optional relationship with user requirements. They may also be generated from business rules and constraints.

Constraints

Definition:

A constraint is something that may restrict or limit the system in some way.  This may give rise to functional requirements and business rules. A constraint may be the allowable platform on which it can be developed, or a budgetary restriction that limits what is possible for the project to do. There are likely to be organisational reasons for these, but they are always worth questioning.

Example:

The system must be built on a J2EE platform.

Possible source:

Organisational standards such as project methodology.

Relationship with other requirements:

Constraints can influence functional requirements; they may also have a one-to-many relationship with business rules.

Non-functional requirements

Definition:

A non-functional requirement is all about the qualities of the system, sometimes referred to as quality of service. These cover things about the system that are not always apparent in a user interface, such as complying with a security standard or some usability standards. Among other things, non-functional requirements should consider:

  • Legal compliance
  • Security
  • Scalability
  • Performance
  • Recoverability
  • Accessibility
  • Supportability
  • Other company-specific standards
  • Usability.

Example:

The system must comply with WAI accessibility standards to AA level.

Possible source:

Company standards, user requirements, legislation that must be complied with in the countries of use and storage of data.

Relationship with other requirements:

A non-functional requirement may be as a result of a constraint.

Data requirements

Definition:

A data requirement identifies the business entities and their characteristics that the system needs to operate. Simply, this is the information that the business is interested in.

Example:

Entity: Customer
Attribute: Format/Example: Possible values
Title Mr Text values of the following: Mr Mrs Miss Ms Prof Dr
First Name Ewan Text only
Last Name Ashley Text only
Address 1 Thames House Text only
Address 2 10 King Street Text only
Address 3 Calcot Text only
Town Reading Text only
County Berkshire Text only
Postcode RG1 1AA Text only
Country England Possible values include: Scotland Wales Northern Ireland England
Email Address

You may also include relationships between entities and cardinality using a class diagram or an entity relationship model.

Possible source:

Look out for nouns in requirements such as user requirements, which may be articulated in business use cases.

Relationship with other requirements:

There could be a many to many relationship with user requirements or other business requirements.

Reporting requirements

Definition:

Coming from a business systems background for most of the projects I have worked on, there are nearly always reporting requirements. I would define a reporting requirement as something the business wishes to know about regarding a particular state of the business.

Example:

Customer sales by product type within a data range.

Possible source:

User requirements, data requirements (may infer reporting requirements), non-functional requirements may have associated reporting requirements.

Relationship with other requirements:

A reporting requirement may relate to a user requirement. They must relate to at least one data requirement and may have more.

Transition or Implementation requirements

Definition:

These are the transitive requirements that need to happen as part of the project to get the system or change live. These may include requirements such as training to the user or migrating the data from one system to another.

Example:

All new customer data must be migrated onto the Lead Management System every month until launch.

Possible source:

Company constraints such as the project methodology used, the way the IT infrastructure is set up, and company policy.

Relationship with other requirements:

These could come as a result of non-functional requirements, data and functional requirements, and there may also be organisational constraints that govern some transition requirements.

These enable the realisation of other requirements.

Acceptance criteria

An acceptance criterion is an essential part of a requirement and is needed for development, testing and user acceptance testing.

Definition:

Acceptance criteria are the criteria that have to be satisfied for a requirement to be met. Another way of saying this is: What will this requirement look like when it has been realised?

Example:

To provide a meaningful example we need to have the requirement:

Requirement: The system must be able to set up a monthly direct debit of £10 for customers on the basic contract.

Acceptance criteria:

  1. A monthly payment record for a customer exists.
  2. The monthly payment record is for £10.
  3. The customer has a basic contract record.
  4. Payment is taken on the same date as the payment date on the monthly payment record.

Possible source:

SMEs, stakeholders, inferred from the requirement it relates to.

Relationship with other requirements:

All requirements must have at least one acceptance criteria.

nov15ewan2

Figure 3: Requirement with Acceptance Criteria

Conclusion

This article attempted to provide some sort of answer to the original question of: What is the difference between a requirements document and the functional requirements document. Typically for a project you would find a business requirements document or high-level requirements document that includes:

  • Project objectives
  • Benefits;
  • User requirements and their acceptance criteria
  • Constraints.

It might also include:

  • High-level data requirements
  • High-level functional requirements
  • High-level non-functional requirements
  • High-level reporting requirements
  • High-level transition requirements.

You may also find a system requirement document or detailed requirements document or functional requirements document that includes:

  • Functional requirements
  • Non-functional requirements
  • Data requirements
  • Reporting requirements
  • Transition requirements
  • Business rules
  • Acceptance criteria.

Obviously, this is very project-orientated and requirements do exist in the business without being explicitly related to other business entities. The ones we are focused on for a particular project and have discovered this meta-model can apply – provide a golden thread for tracing requirements from a low-level requirement to a project objective. This allows us to validate that the requirement is within scope and contributes to a business benefit and therefore provides business value and, ultimately, is worth doing.

Part 3: The Golden Thread – A Scrum Meta-model…

Don’t forget to leave your comments below.


Ewan Ashley is a Business Analyst at British Gas working within smart homes. He is especially interested in the development of business analysts, the value the role can bring to organisations, requirements reuse and enterprise architecture. Ewan has over ten years of experience in IT/IS projects, having worked as a developer, development manager and business analyst manager.