Author: Ewan Ashley

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.

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.

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.

I am currently mentoring a number of business analysts and this article is in response to a question one of then asked: What is the difference between a requirements document and the functional requirements document? The mentee had been asked (as part of a student project) to produce a requirements document and a separate functional requirements document — slightly confusing. Further investigation uncovered that what was meant by ‘requirements documents’ was in fact the business requirements.

This article intends to provide some definitions to the many different types of requirements and entities that relate to them and some of their possible sources. It also provides a meta-model that explains the relationships between the requirements and other entities and the traceable ‘golden thread’ from a strategic objective to lower-level requirements. This golden thread becomes particularly important to the business analyst as a tool to provide the business appropriate challenge around scope and benefit of requirements.

In part 1 of this article we will focus on the higher-level requirements, often referred to as the ‘Business Requirements,’ of Objectives, Benefits and Stakeholder/User Requirements and the relationships between them. Part 2 of this article will 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

Objectives and Benefits

There are several types of objectives. These could be described within a company’s Mission, and broken down to be described as a Strategic Objectives and handed down to an Organizational unit’s objectives and be further broken down into a Programme’s objective and still further to a project’s objectives. There may also be strategic programmes or projects that are across organizational units. These are types of requirements. Each of these objectives should have an associated benefit (whether it is articulated or not).

Strategic Objective

Definition:

A Strategic Objective is something that a company focuses its efforts on to attain or realize a strategy that has an associated benefit to the company. Strategic objectives tend to be externally focused and take advantage of an opportunity or address an issue.

Example:

Improve customer service across the organization and increase the Net Promoter Score by 10 points.

Grow annual revenue by 10%.

Possible Source:

Possible sources could be a result of an Enterprise Analysis (such as SWOT and PESTLE analysis), examining a company’s vision and mission or part of a company’s strategy, as a result of market changes. Stakeholders will include the executive, board of directors and trustees.

Relationship to other requirements:

This really is the highest-level objective, and all objectives and requirements should tie back and support a strategic objective in some way.

Organizational Unit Objective

Definition:

This will be much more internally focused than the Strategic Objective. An Organization Unit Objective is something that a part of an organization focuses its efforts on to realize some sort of outcome and benefit, ultimately contributing to a Strategic Objective.

Example:

If the organizational unit is responsible for customer service, an Organizational Objective might be: Reduce our customer call handling times by 20%.

Possible source:

As part of a strategic objective, from the head of the Organizational Unit or a senior manager within the organizational unit itself.

Relationship with other requirements:

These should be linked to a strategic objective and in turn are likely to be linked to programme or project objectives and day-to-day business operations.

Programme Objective

Definition:

A Programme Objective is something that a programme of work is set up to achieve. These often take the form of some sort of change programme that focuses on improving an area within the business such as Customer Billing.

Example:

Merge the billing functions across the organization.

Possible source:

Possible sources could be derived from both strategic and organizational objectives. Stakeholders could include the programme sponsor and senior management associated with the programme, heads of the functions affected by the programme.

Relationship with other requirements:

These could be derived from both strategic and organizational objectives and are likely to be cascaded down to project objectives.

Project Objective

Definition:

A Project Objective is something that a project sets out to achieve with the resources it has. This also allows us to recognize whether the project has been a success or not.

Example:

Improve the resource management of the field force by reducing idle time by 10%.

Possible source:

Project sponsor, senior project stakeholders, programme objectives.

Relationship with other requirements:

Often, but not necessarily, Project Objectives are derived from Programme Objectives; they may also be directly related to a strategic objective.

Figure 1: Objective meta-model

Benefits

All objectives must have an associated benefit. If you are on a programme or project that does not have benefits identified, as a business analyst, you should question this and the value of doing the project in the first place.

Definition:

Something that is good for the business; this could be an improved bottom line as a result of selling more of a particular product, or avoided costs as a result of addressing some sort of regulatory requirement.

Example:

In utilizing our field resource more effectively, we will negate the need to bring in contractors, saving the company £1 million by Q4 2012.

Possible source:

Depending on the level of the objective the benefit is linked to will depend on what and who the possible sources are. For example, a project-level benefit source could be project sponsor, senior project stakeholders and from analyzing the project objectives (should the objective be defined before the benefit).

Relationship with other requirements:

Benefits are related to objectives at all levels; every objective should have at least one benefit.

Requirements and Related Entities

There are several different types of recognized requirements types such as user requirements, functional requirements, non-functional requirements. There are also other types of requirements that may be specific to the domain or the project that the requirements are for such as integration requirement or reporting requirements. This article does not seek to offer an exhaustive list of requirements and instead offers a meta-model of requirements and related entities, such as objectives and business rules, that the reader might find useful.

User Requirements or Stakeholder Requirements

Definition:

A user requirement (or stakeholder requirement) is a requirement that describes a need that a user has, something that has to provide the user with the ability to achieve something — a user capability.

Example:

The user shall be able to record a Sale Lead source.

Possible source:

Some possible sources of these requirements may be Subject Matter Experts, stakeholders on your project, potential users of the end system and previous sets of user requirements that have been used on similar projects.

Relationship with other requirements or entities:

User requirements must tie back to an objective, and in turn a benefit.  User requirements also link to functional requirements, data requirements and business rules among others.

Conclusion

The objectives, benefits and user requirements described above are often referred to as the ‘Business Requirements’ and are sometimes featured in a ‘Business Requirements Document’ (BRD).  I think the important point is that there should be a benefit related to what our objectives are and in turn what our requirements relate to. In business analyst terms, this is important for traceability and traceability is important as it allows the BA to provide the challenge to the business around their requirements and the value of those requirements being realized.

In Part 2…

In part 2 of this article, we go deeper into the Requirements Meta-model tracing the ‘Golden Thread’ from User Requirement to Functional Requirement, Data Requirement, Constraints and Business Rules.

Figure 2: A requirements meta-model

Don’t forget to leave your comments below.