Book Image

Managing Software Requirements the Agile Way

By : Fred Heath
Book Image

Managing Software Requirements the Agile Way

By: Fred Heath

Overview of this book

Difficulty in accurately capturing and managing requirements is the most common cause of software project failure. Learning how to analyze and model requirements and produce specifications that are connected to working code is the single most fundamental step that you can take toward project success. This book focuses on a delineated and structured methodology that will help you analyze requirements and write comprehensive, verifiable specifications. You'll start by learning about the different entities in the requirements domain and how to discover them based on customer input. You’ll then explore tried-and-tested methods such as impact mapping and behavior-driven development (BDD), along with new techniques such as D3 and feature-first development. This book takes you through the process of modeling customer requirements as impact maps and writing them as executable specifications. You’ll also understand how to organize and prioritize project tasks using Agile frameworks, such as Kanban and Scrum, and verify specifications against the delivered code. Finally, you'll see how to start implementing the requirements management methodology in a real-life scenario. By the end of this book, you'll be able to model and manage requirements to create executable specifications that will help you deliver successful software projects.
Table of Contents (12 chapters)

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

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.