Search icon CANCEL
Subscription
0
Cart icon
Cart
Close icon
You have no products in your basket yet
Save more on your purchases!
Savings automatically calculated. No voucher code required
Arrow left icon
All Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletters
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Managing Software Requirements the Agile Way

You're reading from  Managing Software Requirements the Agile Way

Product type Book
Published in Aug 2020
Publisher Packt
ISBN-13 9781800206465
Pages 214 pages
Edition 1st Edition
Languages
Concepts
Author (1):
Fred Heath Fred Heath
Profile icon Fred Heath
Toc

Table of Contents (12) Chapters close

Preface 1. Chapter 1: The Requirements Domain 2. Chapter 2: Impact Mapping and Behavior-Driven Development 3. Chapter 3: Writing Fantastic Features with the Gherkin Language 4. Chapter 4: Crafting Features Using Principles and Patterns 5. Chapter 5: Discovering and Analyzing Requirements 6. Chapter 6: Organizing Requirements 7. Chapter 7: Feature-First Development 8. Chapter 8: Creating Automated Verification Code 9. Chapter 9: The Requirements Life Cycle 10. Chapter 10: Use Case: The Camford University Paper Publishing System 11. Other Books You May Enjoy

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.

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $15.99/month. Cancel anytime