Chapter 5: Discovering and Analyzing Requirements

In the previous three chapters, we learned how to create goals, stakeholders, capabilities, and features, how to write these correctly, and how to use them to create a requirements model, represented as an impact map. Still, there is a very important part of the modeling process that we haven't touched upon in much detail: how to draw the requirements out of our stakeholders and extract well-defined requirement entities from these requirements. This is what we intend to examine in this chapter. Specifically, we will cover the following:

• The lost art of requirements elicitation
• Preparing for requirements analysis
• Analyzing requirements
• Having a structured conversation
• Decompose, Derive, Discover (D3)
• Business process mapping

By the end of the chapter, you will know why requirements elicitation is so important yet so casually handled in today's agile world. You will also have learned about a couple of essential artifacts that will help you with requirements elicitation. Finally, you will be aware of three effective techniques for discovering, analyzing, and mapping requirements to an impact map.

The lost art of requirements elicitation

Agile methods have, rightly so, become the standard way of creating and delivering software systems. Most agile frameworks and methodologies do not prescribe any way of capturing requirements and translating them into specifications. To fill this gap, most analysts and developers resort to using user stories as the starting point for the analysis and development process. As alluded to in previous chapters, user stories are usually too wide in scope and context to serve a useful purpose without a huge amount of context-filtering and descoping. This leads to what is known as user-story hell, where our product backlog consists of dozens of different stories, describing everything from non-acting stakeholders' wishes to technical constraints. Such backlogs are extremely difficult to manage or prioritize.

So, when a stakeholder tells us they want something from our system, we have two options.

The first option is that we create a user story, usually in the template of As a <stakeholder>, I want <some functionality>, so that <some benefit>. We then go and have a conversation with the stakeholder about how this functionality should work, write down a narrative, capture some business rules or constraints, and write some acceptance criteria. We then put these stories on the backlog for everyone to read.

Sounds good right? Well, it isn't. Here's why:

• No-one, apart from the story creator, knows where the story came from. No-one knows why this story exists, what business goal it's serving, whether there are other, better ways to achieve that business goal, whether that business goal is a valid one, or even whether this story duplicates or conflicts with another story. All we have is a user story; just a post-it note, sitting there among dozens of other post-it notes.
• To implement the functionality in the story, we first need to make some sense out of it. This often involves splitting the story into smaller stories, perhaps pulling some acceptance criteria out as separate stories. If the story is too big to be delivered as a single unit, we may call it an epic. We sometimes create new user stories to capture technical constraints or business rules. All these are arbitrary and subjective ways of dealing with the chaos of user stories. They leave behind a jumbled mess of multi-level, multi-context stories that are very difficult to work with.

The second option is to analyze the requirement, identify and capture the requirement entities it encapsulates, and model these in a structured, hierarchical, and highly legible impact map.

This approach has some distinct advantages:

• We can identify stakeholder goals and validate the requirement against them.
• We can easily identify conflicting or duplicating functionalities.
• We can trace features (functionalities) to capabilities to stakeholders and goals.
• We can easily see, organize, and prioritize our backlog.

As illustrated in the following figure, a requirements model enables us to easily understand what the requirements are, as well as their scope and context. It also provides visual traceability between the different entities, so that anyone working on even the smallest task to implement a feature can see exactly the overall context (the big picture) of what they are working on:

Fig. 5.1 – Example of a requirements model

Compare the preceding diagram of a structured, contextualized, and hierarchical requirements model to the stack of user stories we would have had if we chose the first option. A thorough analysis of the requirements will result in this informative and manageable model, which will be the basis for our system development effort. In this chapter, we will learn how to analyze requirements and identify and capture the requirement entities they encapsulate. It is the final skill that is needed in order to be able to fulfill the requirements and specifications and do so in a consistent, efficient, and reliable manner.

Preparing for requirements analysis

Before we start eliciting and modeling requirements, it is very important that we do the following:

• Understand who uses and/or influences our system, that is, the stakeholders. It is absolutely crucial that we know who will be interacting with our system before we try to understand what they want to achieve by using our system.
• Ensure that we use a common language with our stakeholders. The usage of different semantics and ambiguous terms can be catastrophic when eliciting requirements. I once got through the best part of a 1-hour meeting before realizing that three of us in the room were using the term session in totally different ways: my colleague – a network engineer – meant a TCP session, I was talking about an HTTP (browser) session, while our client – a stockbroker – was referring to a trading session! Ridiculous as it may sound, such mix-ups and ambiguities are all too common when people from different knowledge domains come together.

To accomplish these pre-requisites, we need to create two artifacts: a stakeholder model and a glossary. Let's examine them in the subsequent sections.

Stakeholder model

In Chapter 1, The Requirements Domain, we discussed how to identify stakeholders and categorize actors. Knowing which stakeholders are involved in our system is essential if we want to discover and correctly model requirements. Let's imagine that we are building a university college learning management system. A complete stakeholder model would look something like this:

Fig. 5.2 – The stakeholder model

What the stakeholder model achieves is the following:

• Identification of the primary actors, secondary actors, and non-acting stakeholders: This helps us to understand who triggers our system behavior and how they affect the system. If we receive any requirements from a stakeholder who is not modeled here, we need to ask ourselves (and others) whether that stakeholder has a good reason to want to influence our system. If the answer is yes, we add the stakeholder to our model and examine their requirements. The model allows us to know who influences our system and how, at a single glance.
• Allows us to generalize actors: Generalizing actors allows us to capture system behavior that may vary under different conditions. For instance, we are expecting our students to interact with our system. But these interactions will be slightly different depending on whether the student is an undergraduate or graduate student. Our supervisor and teaching director expect certain functionalities allowed to them by the system and certain system behaviors. But, sometimes, either of these actors may need to act like an examiner. In this case, they would expect different functionalities and system behaviors.
• It describes stakeholders' roles and responsibilities. A good model will have annotations or comments for most stakeholders. For instance, the annotation for the supervisor will be something like A teaching staff member who is responsible for maintaining the academic progress and well-being of specific students.
• It depicts the organizational affiliations of the stakeholders. This can be very useful. For example, knowing that the system administrator will be a member of your team will make a considerable difference to how and when you elicit their requirements.

Another thing of note is that our actors are not always human ones. Any external system or API we need to interact with is itself an actor. For example, our college system will need to get and send data to the university's student database. The student database system is an actor because it will influence our system's behavior by interacting with it.

Tip

Avoid using vague and generic actors. Specifically, avoid using the user actor. It is a catch-all term that only creates confusion and ambiguity and will hinder your requirements elicitation process.

The stakeholder model is a constantly evolving artifact. It starts small and then it grows as our understanding increases. Once we've created our stakeholder model, we need to strive to have conversations with each actor representative, which is someone who has the role and responsibilities of the actor in question and can answer our questions.

Discovering stakeholders

Anyone who will be interacting with our system or influencing its behavior in any other way is a stakeholder. Looking at the email distribution list for project meetings is a sure-fire way of discovering stakeholders. We may also discover stakeholders by asking the following questions:

• Who (or what) needs information from the system?
• Who (or what) does the system need information from?
• Who maintains the system?
• Who is going to be affected if the system is not delivered?

Another way to discover stakeholders is to look at our client's business process diagrams. We'll talk more about this technique further on in this chapter.

Glossary

Glossary is a Greek-derived word that literally means a book of language. This is very apt, as this is exactly what we want to have while talking to our stakeholders. A glossary is just a table with two columns. The first column is the term, word, or phrase we are defining, and the second column displays its disambiguated meaning. There are two concepts to consider when clarifying meaning:

• Polysemy occurs when the same word has different meanings in different contexts. The previously mentioned session means different things in the web development world, the networking and infrastructure world, and the stock-brokering world. The word mole means different things depending on whether you're talking about your garden or your face. The phrase drawing a gun means something different to a graphics designer than to a bank robber.
• Synonymizing is the usage of different words to convey the same meaning based on different contexts. Within the same knowledge domain, we may have the same action represented by different words or phrases depending on the system actor or the system state.

For instance, in our everyday life, we usually say that we upload a document to a website. However, I have worked on a publishing system where its users did not upload documents to the website, but submitted documents instead. In addition, submitted was only used when it was the students who uploaded the document. A reviewer could then review and annotate the document before uploading it to a different system for final review, and that upload was called processing because it was done by the reviewer and it meant the document was now ready for publication. Finally, an editor would upload the document to yet another publishing system. That upload was called publishing. So, here we have this common, singular action that you and I would call uploading being called submitting, processing, or publishing depending on who was doing it and the state of the document at that point. Using the wrong term at the wrong time or for the wrong actor will cause confusion.

A glossary will look something like this:

Fig. 5.3 – A glossary example

As you can see, the glossary includes domain terms, such as session and Q&A, but also technical terms and acronyms, such as UI and API. We must never assume that all our stakeholders have got the same level of technical knowledge as us. We should also define any other process or methodology terms that may be unfamiliar to stakeholders. A very common occurrence is referring to the agile term sprint (from the Scrum framework). You'd be surprised by how many stakeholders think of a sprint as something that involves the development team running very quickly!

Important Note

Some processes and methodologies refer to the glossary as ubiquitous language or common vocabulary. Although the names may be different, the concept is the same.

Just like the stakeholder model, the glossary is a constantly evolving artifact. It keeps growing as our understanding increases. Having a rich glossary that is distributed to all stakeholders can save us many hours of unnecessary frustration and confusion. When we use domain terms in communication with our stakeholders, we must ensure that we are using them as defined in the glossary. The glossary also needs to be made available to all our stakeholders. Attaching it to a Specifications document and/or having it on the company Wiki will help towards that.

Once we have a first pass of our stakeholders model and a glossary that clarifies any critical domain terms, we can get on with eliciting and analyzing requirements.

Analyzing requirements

In Chapter 1, The Requirements Domain, we talked about the concept of the requirements funnel. This is a mental model that illustrates how requirements keep coming at us from many directions and in many forms and shapes. We need to filter these requirements and convert them to quantifiable and knowable entities so that we can process them. These items are our requirement domain entities (goals, stakeholders, capabilities, and features). If you've done chemistry at school, you may have used a separating funnel. These funnels are used to separate mixed liquids, such as oil and water. To convert requirements to requirement domain entities, we must use a mental separating funnel, which will filter the mixture of incoming requirements and then identify and create the relevant domain entities. Once we've done that, we can model those entities as an impact map, that is, our requirements model.

Our funnel will consist of distinct filtering techniques. These can be used separately, sequentially, or concurrently:

• A structured conversation
• D3
• Business process mapping

In the next few sections, we will explore these techniques in greater detail. We will begin by looking at having a structured conversation.

Having a structured conversation

Let's face it: having conversations is difficult. People tend to drift, topics are digressed from, and a myriad of other distractions may occur. A structured conversation is about focusing on specific aims and having a game plan when discussing requirements.

When should you use structured conversation? When having synchronous, interactive communication with the stakeholders, such as face-to-face, telephone, or internet meetings.

To have a fruitful conversation with the stakeholders and to be able to discern and capture their requirements, we need to structure our conversation with them in a very specific way:

1. Identify the type of stakeholder you are conversing with. If they are a business sponsor – in other words, a non-acting stakeholder – then their goals will be accomplished through the interaction of some actors with our system. For instance, a security officer will aim to preserve system security. Her goals will be achieved by affecting the interactions of other actors, such as the ones uploading files, doing audits, and so on. Make sure you identify those actors.
2. Identify the business or domain goals the stakeholder has, in the context of our system. The key questions here are How do you think our system will benefit you in your role? and What would happen if our system was never delivered?  When you've identified the goals, make sure you validate them as explained in Chapter 1, The Requirements Domain, specifically the Identifying goals section. Good business goals have strategic value and result in a material outcome. If this isn't plain from our conversation, we need to press the issue until we define a valid and useful business goal. If the goal is a domain goal, make sure that it aligns with a valid business goal. Make sure you note any potential vanity or pet goals.
3. Ask the question, What do you want to be able to do with our system that will help you achieve your goals? Here, we're aiming to identify capabilities. Sometimes the stakeholder will start elaborating on their perceived way of achieving this capability, such as the functionality or system behavior or the features they want. At that point, we need to steer the conversation back toward how they want to achieve their goal through our system, not what our system will do. The what will be discussed later, when we are creating our system's features. Refer to Chapter 2, Impact Mapping and Behavior-Driven Development, for further guidance on identifying capabilities.
4. Once you have identified a capability, ask Who else would benefit from this capability? This is an opportunity to discover new stakeholders, who you might never have thought about otherwise. Let's say, for instance, that a lecturer needs the ability to search through loads of coursework, based on a topic or keyword, so that they can find and mark assessments quicker. The same capability may also be very useful to a student actor, who wants to review or correct their essays.
5. Once you have identified a capability, ask the stakeholder What would you like the system to do in order to provide you this capability? Then, go back to the development or product team and ask What can we do / what are we technically able to do / what are we willing to do in order to provide this capability. The intersection of the answer sets for these two questions is a good start for identifying our features.

The preceding steps are part of an interactive and incremental process. It is very rare that we'll nail down all the required capabilities in the context of the right stakeholders and business goals in one go. More often than not, our first conversation with the stakeholders will give us a rough idea of what's involved, while following conversations will help refine and increase our knowledge. The thing is, framing the conversation in terms of What do you want to do with the system and why do you want to do it? helps the stakeholders question their own assumptions and crystalize their expectations. It's a closed-loop feedback process. We break the loop only when both we and the stakeholder are satisfied that we accurately captured the whos, hows, and whys.

Once we have a reasonably well-defined view of business goals, stakeholders, capabilities, and some feature outlines, we can be satisfied that we have a good requirements model. We can then turn our attention toward creating our specifications, that is, toward refining our features, as we have already described in Chapter 3, Writing Fantastic Features with the Gherkin Language.

Decompose, Derive, Discover (D3)

Another technique for analyzing and discovering requirements is what I call D3 for short. D3 is about parsing the communications we receive so that we can capture the appropriate requirements domain entities and create our impact map.

When should you use D3? When we have asynchronous communication with the stakeholders (for example, email) or when we have written requirements (formal documents, business rules, examples, narratives, and so on). We can also apply D3 to visual requirements, such as screenshots or storyboards. We just have to create a written narrative based on those visualizations.

Decomposition

Decomposition is simply the process of breaking down a piece of text into its constituent parts. Decomposing a textual requirement helps us identify the requirements domain entities it is referring to. Before we learn how to decompose requirement text into its constituent domain entities, let's take a quick trip down memory lane and reminisce about our grammar classes at primary school.

In the English language, sentences are composed of clauses. A clause, at its minimum, is a group of words with a subject and a verb. A sentence will have at least one clause – for example, Mark is looking at me. However, most of the time the clause will have a subject, verb, object, and some object qualifiers – for example, Jenny runs the meeting, or The cat sleeps on the purple mat.

With this quick grammar lesson out of the way, let's find out how to detect entities in our written requirements.

Detecting actors

In a requirement description, the clause subject usually indicates an actor. For instance, in The reviewer will be able to see the document's download speed, the reviewer is our actor. Often, the subject is implied. For example, when we say, The purchased items are listed on the orders page, the implied subject is the system; it is the system that lists the items on the page. Our system is not an actor, as we have previously discussed in Chapter 1, The Requirements Domain, specifically the Identifying stakeholders section.

Tip

When the subject turns out to be the system, then in order to discover the actor, we need to find out who or what is affected or benefits by the action the system takes. So, if our requirement states "the system will log all file download details", our actor is likely to be the system administrator or whoever else benefits from that system activity.

Another important thing to consider when analyzing clauses is whether it involves an active or passive verb. When the verb is active, the subject of the verb is applying the action – for example, Jack ate the pie. When the verb is passive, the action is applied to the subject – for example, The pie was eaten by Jack. In Jack ate the pie, the subject is Jack. In The pie was eaten by Jack, the subject is the pie. So, here we have two clauses with the same meaning but different subjects. Here's the thing: actors are usually the subject of active verb clauses. To avoid confusion, it is good practice to convert passive clauses to active wherever possible. So, if you see a requirement that states message is received, translate this to X receives message. X is the subject, that is, our actor. You can then start asking questions about who or what exactly X is.

Detecting capabilities and features

The verbs and associated objects in a clause usually indicate an activity. So, in The reviewer will be able to see the document's download speed, the activity is seeing download speed. In The purchased items are listed on the orders page, the activity is listing purchased items.

Activities drive the discovery of features and capabilities. We can apply the criteria described in Chapter 2, Impact Mapping and Behavior-Driven Development, specifically the Identifying capabilities and features section, to determine that Listing purchased items and Seeing download speed are indeed features.

Sentences often consist of more than one clause, such as a main clause and some dependent clauses. A dependent clause is a clause that doesn't express a complete thought, so it can't stand alone but is used to qualify a main clause. For instance, when we say, I will meet you at 9, unless the traffic is bad, the unless the traffic is bad part is a dependent clause. Dependent clauses that begin with a subordinating conjunction (because, although, when, unless, until, before, if, and so on) tend to indicate feature scenarios. In The customer can keep adding money to the bet until they reach their credit limit, the main clause is the customer can keep adding money to the bet and the dependent clause is until they reach their credit limit. From the main clause, we can discern that we have a Customer actor and an Add money to the bet feature. The dependent clause tells us that we need to add a Credit limit is reached scenario to our feature.

Detecting goals

Occasionally, dependent clauses beginning with because or so will suggest an actor's goal. For instance, the requirement The manager can see all transactions for the last year, so they can check if any transaction was unauthorized reveals that the manager's goal is to check unauthorized transactions, that is, to prevent fraud. When you detect a goal, make sure to validate it with the stakeholders and also internally, as described in Chapter 1, The Requirements Domain.

Examples

Back in Chapter 1, The Requirements Domain, specifically the The nature of requirements and specifications section, we looked at some examples of different forms of requirements. Let's revisit some of these examples and analyze them with our new-found knowledge:

1. Example 1: Requirement as a formal statement – the system must provide a document searching facility.

   Analysis: The activity in this clause is searching for documents. This is a high-level, coarsely granular, and not directly actionable activity, which suggests that this is a capability.

   The subject in this clause is the system. However, the system can never be an actor to itself. So, we need to find out who the real actors are. Let's say that, in this example, it will be the authors who want to be able to search the documents,

   Detected entities:

   • Document search (capability)
   • Author (actor)
2. Example 2: Requirement as an example – Joe didn't have to pay for his coffee because it was his 11th one in that store.

   Analysis: The subject here is Joe and he is our actor. Obviously, Joe isn't a good name for an actor, so we will have to chat to our stakeholders to understand the role that Joe is playing in this example. We could then call our actor something like Loyalty-card holder or Returning customer.

   The activity Joe is undertaking is paying for his coffee. This is quite specific and directly actionable, so we put it down as a feature. The dependent conjunctive clause because it was his 11th one in that store suggests a scenario where Joe gets a free coffee after having bought 10 coffees.

   Detected entities:

   • Paying for coffee (feature)
   • 11th coffee in a row (feature scenario)
   • Loyalty-card holder (actor)
3. Example 3: Requirement as a business rule – accounts with monthly deposits larger than $1,000 are applied with a 2% higher interest by the system.

   Analysis: Since this is a passive-verb clause, let's re-write it in an active form:

   The system will apply 2% higher interest to accounts with balances greater than $1,000.

   The subject here is the system, so we can't use that as an actor. After talking with our stakeholders, we find out that the person affected by the system's activity (and therefore our actor) is the account holder.

   The activity here is applying interest. This is likely to be a feature, as it is quite specific, atomic, and directly actionable; that is, we can give this to our developers, alongside an interest rate and an initial amount, and they can implement this without too many questions. Since we now know that the actor involved in this feature is the account holder, we could call the feature Account holder receives interest.

   The requirement also has a dependent conjunctive clause, as it's the same as saying that the interest will be applied if the balance is greater than $1,000. This suggests a scenario for our applying interest feature.

   Detected entities:

   • Account holder (actor)
   • Receive interest (feature)
   • Balance greater than $1,000 (feature scenario)

Decomposition outcome

Decomposition allows us to identify requirements entities within raw text and create the basis for our model. For example, in our last example, the requirement was The system will apply 2% higher interest to accounts with balances greater than $1,000.

We decomposed it into its appropriate requirement entities, and we can now visualize it as an impact map:

Fig. 5.4 – Requirement decomposition

Our feature will look something like this:

Feature: Account holder receives interest

Scenario: Balance less than $1,000

  …Scenario: Balance greater than $1,000  

  …

At this stage, our model looks pretty bare. Remember, though, this is just the beginning of our analysis. Let's move onto the second phase.

Derivation

During decomposition, we identified a number of requirements entities, such as actors, capabilities, and features. If we put these entities on an impact map, chances are it will turn out to be an incomplete map, lacking the required hierarchical associations between our entities.

Our requirement entities do not exist in a bubble. Features are associated with capabilities. Capabilities serve some actor's goal. Derivation is simply the process of filling in the gaps in our impact map; in other words, this is where we derive our associated entities. To achieve that, we look at our impact map from right to left. Any features that we have identified must have a related capability. If they don't, then we need to either infer one or ideally go back to our stakeholders so that they can help us identify one.

Looking at the impact map for our example requirement from the previous section, we see that the right-most element is a feature. This Receives interest feature is a piece of functionality that is not associated with any greater impact the actor needs to have on our system, that is, a capability. This is where we go back to the actor or other stakeholders and try to understand which overarching system capability we're trying to deliver by implementing this feature. We cannot properly identify the capability until we understand the goal the actor is trying to accomplish.

Derivation outcome

A reasonable outcome of our derivation phase is that we derive the capability that our feature supports as the ability to have financial incentives for opening an account with the bank. This would help realize the bank's goal of trying to attract more customers by incentivizing the opening of new accounts. Our model now looks like this:

Fig. 5.5 – Requirement derivation

Although this is a much more complete model, we haven't finished yet. We'll be expanding our model during the discovery phase.

Discovery

In the decomposition phase, we got analytical. In the derivation phase, we got methodical. The discovery phase is where we get creative. This is where we discover new capabilities and features, based on the ones we have already detected and derived. In the derivation phase, we established the Financial Incentives capability, which will be delivered by implementing the Receive Interest feature. In the discovery phase, we ask the question, Are there any other ways we can help deliver this capability? That is, are there any other features that will help offer financial incentives to our account holder? After some thought (and consultation with our stakeholders), we decide that we could be offering cash-back to the account holders on selected purchases on their accounts. That's one more feature for our model.

Let's also consider our goal. Are there any other ways we can appeal to account holders, other than financial incentives? Why, yes there are. Turns out that our account holders would be motivated to open accounts with our bank if we also offered other services as part of our account package. We can identify two more features (travel insurance and fraud prevention) that can help deliver this capability.

Discovery outcome

After discovering our new entities, this is what our impact map model looks like:

Fig. 5.6 – Requirement discovery

We started with a simple textual requirement and we ended up with a multi-level impact map with two capabilities and four features. We put our requirement through the requirements funnel, we applied the D3 filter, and we ended up with a structured, traceable, and clear representation of the requirement, which will form the basis of our specification and – ultimately – our delivered system.

We could actually go further with the discovery phase. We could easily discover other capabilities the account holder might need, even other actors who may benefit from these capabilities. It's like dominos (the game, not the pizza chain). Once the first few cards fall, then the whole stack goes. The discovery phase is an exciting and beautiful thing!

Tip

Wireframes and screen mock-ups can also be analyzed using D3. We first have to create a narrative based on the screens. Every button or checkbox we see will be pressed on certain conditions. Every text box will be filled with some meaningful text. Every link will lead us to another set of functionalities. Once we write all that down, we see that wireframes and mock-ups are just another set of statements, business rules, and examples. We can then start decomposing, deriving, and discovering domain entities based on that narrative.

One more technique for analyzing requirements is business process mapping. Let's look at it next.

Business process mapping

A business process is a sequence of related, structured activities or tasks by people or equipment that, when applied successfully, serves a particular business goal. Business processes, visualized as graphs, can be an extremely helpful tool in our analysis toolbelt. Business process diagrams are usually written using UML or BPMN notation, but simple flowcharts are also common.

Tip

When starting to elicit requirements, ask your client stakeholders whether they have already captured the business processes that they want our system to realize. If not, ask them whether any of their domain experts can possibly produce such diagrams. As well as helping you elicit requirements, this will also make them consider and evaluate their requirements much more carefully.

Let's take a look at a diagram for an order approval business process flowchart (courtesy of https://commons.wikimedia.org/wiki/File:Approvals.svg):

Fig. 5.7 – Business process for order approvals

Here we have five vertical lanes and a set of interconnected tasks, states, and decision points. This simple diagram can give us a lot of valuable information on our requirements analysis journey. There are some rules of thumb we can apply to map this business process to our standard requirement domain entities.

Here are those business process mapping guidelines:

• Business processes tend to represent high-level, transactional activities that help accomplish a business goal. If this sounds familiar, it's because we use similar terms to describe capabilities. That's right: often – but not always – business processes indicate capabilities. In our example, it would be reasonable to infer that we are dealing with an order approval capability. However, it's possible that we are dealing with a broader order management capability. The business process diagram gives the springboard needed so that we can have these conversations with the stakeholders.
• Lanes commonly represent an organizational role, that is, a stakeholder. Be wary, though, as lanes are sometimes used for other purposes too, such as to represent project phases. In our example, we can easily identify the following stakeholders: customer, sales rep, contracts agent, and attorney. We need to determine which of these will be interacting with our system in order to perform their responsibilities. These will be our actors.
• Tasks are usually equivalent to features or scenarios. Sometimes, tasks are so granular and simple that they are equivalent to a single step in a feature scenario. The Agent approves order task in our example business process appears to be nothing more than a scenario step. Contract Agent review order, however, looks more like a complete feature. Again, further conversations with the stakeholders will help us define the nature of these tasks.
• Decision points indicate the presence of divergent behavior, which points to different scenarios. For instance, the Standard terms? decision point in the business process diagram dictates two different scenarios for our Contract Agent reviews order feature: one where the order is written with standard terms and one where it isn't.
• Goals can be determined by considering the business process's goal, which is usually the final state of the process. In our example, this would be Order is shipped. So, the reason we go through the approval process is so that we can ship the order. It is obvious from examining the diagram that the order cannot be shipped without approval.

There are a couple of things to remember when applying these guidelines:

• These are heuristics, not absolute rules. They will apply to many situations and will help guide you in the right direction for many others. However, there will be some business processes where one or more of these guidelines will not apply. As always, use your common sense and ability to infer to spot these.
• Like every other technique or process described in this book, mapping business processes is an iterative and incremental procedure. Often, an understanding of a particular part of the business process will reveal itself only after we have clarified a different part of the process.

  Tip

  An important aspect of business process mapping is defining the scope of our system within the business process. A good way to accomplish this is to ask our client stakeholders to visually mark the diagram's lanes, tasks, and any decision points expected to be performed by our system. It's a quick and visible way of clarifying the scope and responsibilities of our system.

So, we are coming to the end of this chapter. Let's summarize what we have learned!

Summary

In this chapter, we discussed the importance of requirements elicitation and its current state in the agile world. We then learned how to create two important artifacts: the stakeholder model and the glossary. These artifacts give us the context and clarity of communication needed when communicating with stakeholders. Finally, we examined how to gather requirements from our stakeholders and analyze them in order to identify requirement entities. We learned a number of elicitation and analysis techniques, such as structured conversation, D3, and business process mapping. These techniques greatly facilitate the gathering and analysis requirements and allow their successful modeling in a requirements model.

This chapter also concludes the first part of the book. You now have enough knowledge to elicit, validate, model, and specify your system's requirements. However, requirements management doesn't stop here. In the next section of this book, we'll learn how to organize our requirement domain entities and work with them within agile processes and frameworks in order to deliver a system that works exactly as our stakeholders expect. Keep reading!