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.