Chapter 1: The Requirements Domain
Now that we know what this book is about, we can begin our exploration of the requirements domain. A domain is an area of knowledge within which we can operate. As software professionals, we move between different domains daily: the coding domain, the testing domain, as well as client-specific domains such as banking, engineering, education, and so on. In every domain, we deal with specific domain entities that represent items of knowledge or interactions within the domain. In the coding domain, for instance, we deal with entities such as data structures, algorithms, functions, and so on. These entities reflect how we capture and utilize domain knowledge. The aim of this chapter is to introduce you to the requirements domain and its entities.
We will start by explaining the meaning of requirements and specifications, and discussing the requirement life cycle. We will then define the role of stakeholders and actors and talk about the goals they have in relation to our system. Lastly, we will consider the importance of bridging the gap between requirements and specifications and how this book will be approaching this problem. The main sections herein are as follows:
- The requirements domain
- Identifying stakeholders
- Identifying goals
- Goals, requirements, and specifications: a traveling analogy
- Crossing from requirements to specifications
By the end of the chapter, you will know the difference between and the importance of requirements and specifications, as well as the stages requirements move through during a project's life cycle. You will also be able to create and validate stakeholder goals, understanding the importance of writing specifications, the pitfalls with current approaches, and how this book will be tackling this subject.
The nature of requirements and specifications
Requirements can arrive at any time in the project life cycle and from a variety of people: directors, CEOs, business owners, business analysts, project managers, product owners, and end users will all at some point require or expect something of the system we are building. Our job as system builders is to analyze, validate, scope, and classify these requirements. We start this process by mapping requirements into a requirements domain model. A domain model is a representation of all the important entities and their relationships within a specific domain.
So, for instance, in the pizza-making domain (one of my favorites), we would expect to find entities such as base, toppings, restaurant, oven, and delivery person, as well as the relationships between them. Knowing what these entities are and how they are connected allows us to create and deliver pizzas. Similarly, in the requirements domain, we'd expect to find entities and relationships that help us define, conceptualize, and deliver requirements. We'll be exploring requirements domain entities and activities throughout this book.
As with every business domain, it is imperative to ensure that the domain entities and terms used herein are clearly defined and understood. After all, ambiguity ruins productivity and one of the goals of this book is to actualize a productive requirements management methodology, so let's start at the beginning…
What is a requirement?
Simply put, a requirement is a stakeholder's expression of a need, wish, or desire with regard to the system being built. Requirements come in different shapes, forms, and sizes, and from various sources. They may be provided verbally, on paper, or as computer files. Requirements may be provided as follows:
- Formal statements (for example, the system must provide a document searching facility)
- Business rules (for example, accounts with monthly deposits larger than $1,000 receive 2% higher interest)
- Examples (for example, Joe didn't have to pay for his coffee because it was his eleventh one in that store)
- User stories (for example, as a loyalty card holder)
- Business processes, that is, sets of tasks and activities that are executed in tandem in order to accomplish an organizational goal
- Screen mock-ups or wireframes
- Narratives or storyboards
- Flow-charts, activity charts, or some other type of diagram
Requirements, on their own, are not really useful. In order to be able to implement and deliver requirements, we must give them context and scope and fit them within a user workflow. In other words, we need to turn them into specifications.
What are specifications?
A specification is a description of the system behavior required in order to fulfil or realize a requirement. So, if our requirement states that The system shall provide a document searching facility, a specification should tell us what the system will do to allow the user to search for documents. A specification is just a way of defining how we're going to realize a requirement. Nothing more, nothing less.
Requirements without specifications are pretty useless when it comes to delivering a working system. Unless we analyze and define the impacts (that is, expected behaviors) the requirements have on our system, we stand little chance of building a system that does what its intended users want it to do. Our coding prowess, software engineering skills, and technical expertise stand for nothing unless we can build the right system. To paraphrase an old adage, Most developers know how to build the system correctly. Not many know to build the correct system.
Having specifications is a great start towards building the correct system. Being able to analyze and map the requirements into proper specifications is a major step towards ensuring we will be building the system that our stakeholders need and want.
The requirements life cycle
Requirements management, like many other software engineering disciplines, consists of distinct stages, as illustrated in the following diagram:
Fig. 1.1 – Requirements life cycle stages
Let's take a closer look at what each stage involves:
- Elicitation: The collection of requirements, which can be done in many different ways.
- Validation: Ensuring that the requirements fulfill a realistic and useful business need.
- Modeling: Having a structured and consistent way to describe and store requirements.
- Specification: This is where we translate the requirements into concrete and clear system behaviors.
- Documentation: It should go without saying that requirements must be well described, detailed, and documented.
- Tracing: Knowing which requirements affect system behaviors and which behaviors are necessitated by specific requirements.
- Classification: Requirements can be classified according to the area of the system they affect, their complexity level, their risk level, and many other factors.
- Prioritization: This is usually done according to impact and precedence.
- Verification: Ensuring that our system functions in a way that fulfills the requirements.
- Change Management: Dealing with changes to requirements.
Any and all of these stages may and do occur repeatedly throughout a software project's life cycle.
This book provides methods and techniques to address all of these stages. However, before we get into them, let's define and understand our requirement domain entities, starting with stakeholders.
Identifying stakeholders
A stakeholder is someone, or something, that derives value, benefits from, or influences our system. There is a stakeholder sub-set we call Actors. These are stakeholders who interact with our system, either directly or indirectly.
All actors are stakeholders, but a stakeholder is not necessarily an actor. This is because there is another sub-set of stakeholders we call non-acting stakeholders. These would usually be people like directors, business owners, enterprise architects, or senior managers. These usually are our business sponsors. They have a stake in the system, and they will probably make decisions that influence the system, but don't expect to see them sitting down in front of a screen and using the system any time soon. The following diagram illustrates the relationship between actors and non-acting stakeholders:
Fig. 1.2 – Stakeholders
Actors may be further divided into two categories:
- Primary actors interact with the system directly through a UI or API in order to achieve a specific goal.
- Secondary actors are actors that the system needs to be assisted by. This makes it possible to achieve the primary actor's goal.
Secondary actors may or may not have goals that they need to reach by using the system. Primary actors always have a goal that they expect to reach by using the system. Let's take the example of an online loan system. The credit consumer using the system expects to get a loan. The system will provide the loan only if it receives a positive response from a credit reference agency, such as Experian or Equifax. The credit consumer is a primary actor as they interact directly with the system in order to accomplish a specific goal. The credit reference agency is a secondary actor as the system relies on it in order to achieve the primary actor's goal.
Important note
System developers are not actors. Developers are an intrinsic part of the system; they act as system proxies. Actors are always external to the system.
We will be talking more about discovering and defining actors in Chapter 5, Discovering Requirements.
Identifying goals
Our stakeholders will have their own goals and objectives for using or sponsoring the system we are building. Understanding these goals is critical to the successful elicitation, analysis, and modeling of requirements. Stakeholder goals usually fall within two categories, depending on whether the stakeholder is a non-acting stakeholder or an actor. Actors have goals related to the domain in which they operate, for e...
