Requirements

Managing Non-Functional Requirements in SAFe

 Managing Non Functional Requirements in SAFeManaging non-functional requirements (NFR’s) in software development has always been a challenge. These “system capabilities”, such as ‘how fast a page loads’, ‘how many concurrent users the system can sustain’ or ‘how vulnerable to denial-of-server attacks can we be", traditionally have been ascribed as belonging to “quadrant four of the agile testing quadrants” of Brian Marick. That is, these are tests that are technology facing and which critique the product. That said, it has never been clear *why* this is so as this information  can be critical for the business to clearly understand.

In the Scaled Agile Framework (SAFe) NFR’s are represented as a symbol bolted to the bottom of the various backlogs in the system. This indicates that they apply to all of the other stories in the backlog. One of the challenges of managing them lies in at least one aspect of our testing strategies: When do we accept them if they represent a "constant" or "persistent constraint" on all the rest of the requirements?

This paper advances an approach to handling NFR’s in SAFe  which promotes the concept that NFRs are more valuable when considered as first class objects in our business facing testing and dialogs. It suggests that the business would be highly interested in knowing, for example, how many concurrent users the system can sustain on-line.  If you're not sure about this just ask the business people around the healthcare.gov project! One outcome of this approach is that we see a process emerge that reduces or need to treat them as a special class of requirements at all.

If we expose the NFR’s to the business, in a language and manner that would create shared understanding of them, we could avoid surprises while solving a major challenge.

Please consider the following Gherkin example:

Feature: Online performance

In order to ensure a positive customer experience while on our website

I’d like acceptable performance and reliability

So that the site visitor will not lose interest or valuable time

Scenario: Maximum concurrent signed-in user page response times

  • Given there are 1,000 people logged on
  • When they navigate to random pages on the site
  • Then no response should take longer than 4 seconds

Scenario: Maximum concurrent signed-in user error responses

  • Given there are 1,000 people logged on
  • When they navigate to random pages on the site for 15 minutes
  • Then all pages are viewed without any errors

These are pretty straight-forward and easy to understand test scenarios. If they were managed like any other feature in the system the creation, elaboration and implementation of them would serve as a ‘forcing function’  where derived value in the form of shared understanding between the business and the development would be gained. As well these directly executable specifications could be automated such that they could run against every build of the software. This fast feedback is very important to development flow. If we check in a change, perhaps a configuration parameter, or new library, that broke any NFR, we’d know immediately what changed (and where to go look!).  Something that is also very valuable (and often overlooked!) is that each build serves as a critical on-going baseline for comparison of performance and other system capabilities.

Any NFR expressed in this fashion becomes a form of negotiation. It makes visible economic trade-off possibilities that might not otherwise be well understood by the business. For example, if push came to shove, would there still be business value if, under sustained load, page responses were sometimes reduced to 5 seconds in some cases?

Another benefit of writing the test first is that it would increase the dialog about *how* we will implement the NFR scenario helps to ensure, by definition, that a "testable design" emerges.

This approach to requirements/test management is known as "Behavior Driven Development" (BDD) and "Specification By Example". The question of how and when to implement these stories in the flow sequence remains a challenge and the remainder of this article addresses this challenge directly. I’ll address one solution in SAFe.

The recommendation is to Implement the NFR an an executable requirement using natural language tools like Cucumber, SpecFlow (which supports Gherkin) or Fit/FitNesse (which uses natural language and tables) as soon as they are accepted as NFRs in an iteration as part of the architectural flow. Create a Feature in the Program backlog that describes implementation of the actual NFR (load, capacity, security etc.) and treat it like any other feature that point. Have the system team discuss, describe and build the architectural runway to drive the construction of the systems that will support the testing of them. Use the stories as acceptance against the architectural runway, if that is appropriate. If you do not implement the actual test itself right away (not recommended) at least wire it up to result in a “Pending” test failure (not really recommended but I’ll describe that more in a moment). When the Scenarios are running in your continuous integration (CI) environment, the story can be accepted. With regards to your CI, keep in mind that some of these tests, with large data sets or with long up time requirements will take a while to complete so it is very important to separate them from your fast failing unit tests.

The next important step is to make these tests visible to the business and to the development team. To the business, one way to make them visible, along with your other customer facing acceptance tests, is you use a tool like Relish that can publish them, along with markup and images as well as navigation and search.

Another recommendation in this approach would be to build a “quality” dashboard using the testing quadrants as described earlier. That is, each quadrant would report a pass/fail/pending status that could be used for governance and management of the system. When all quadrants are green, you can release. You can get quite creative with this approach and use external data sources, such as Sonar and Cast (coverage and code quality tools, respectively) and even integrate with Q3 exploratory testing results, for example. There is work to be done in this area. Hopefully someone will write a Jenkins plugin or add this to a process management tool.

Using this approach you will always know what the status of your NFR’s are and get the information you need in a timely fashion, when there is still time to react. This approach would help to eliminate surprises and remove the need for a major (unknown cost) effort at the end of your development cycle. In the case above, even if these tests had been marked “Pending” you’d have the knowledge that the status of these NFR’s were unknown, which would increase trust and share the responsibility across the entire value stream.

Learn more about the Scaled Agile Framework: download SAFe Foundations.

Learn more about our Scaled Agile Framework Training and Certification Classes.

Use Case 2.0 – Slices and Relationships: Extension

Since the introduction of Use-Case 2.0 we have received a number of questions about use-case slices and in particular how they relate to the concepts on include, extend and generalization. In this blog we will look at the impact of the extend relationship on use-case slicing.

What’s the Problem?

An extend relationship can be used to factor out optional behaviour from a use-case narrative. It is particularly useful in the following situations:

  1. Where the optional behaviour will be part of a separately purchased extension
  2. Where different customers require different variations of the same behaviour
  3. Where already implemented use cases need to be extended
  4. Where additions need to be made to previously frozen or signed off use cases

Consider a hotel management system with which customers can make online room reservations. As shown in figure 1, the primary use cases would be “Reserve Room”, “Check In Customer” and “Check Out Customer”.

Use Case 2.0 – Slices and Relationships: Extension

Figure 1 – Hotel Management System Use Cases

Now let’s consider what happens if the hotel management system being built is to be a modular commercial product with an optional waiting list feature. This feature allows a customer to be put on a waiting list in the case where the room they like is already booked. The customer will then be informed when the room becomes available or can have the room reserved automatically within a given timeframe. This feature could easily be captured within use case “Reserve Room” but since it is an optional feature, it is factored out into an extension use case.

Use Case 2.0 – Slices and Relationships: Extension

Figure 2 – The re-factored Reserve Room Use Case

Now, to provide a little more context, let’s first have a look at the use-case narrative of the original Reserve Room use-case.

Use Case 2.0 – Slices and Relationships: Extension

Figure 3 – Reserve Room use-case narrative

Without the extending use case we would have had only one use case to slice up - Reserve Room.  Consider the following example Reserve Room use-case slices.

Use Case 2.0 – Slices and Relationships: Extension

Figure 4 - Use-case slices for the Reserve Room use case

The question now is what will happen to these slices when we make use of extension:

  • Does an extending use case have its own use-case slices?
  • Does using extend change the number of use-case slices?
  • Does using extend have an impact on any existing use-case slices?

Does an extending use case have its own use-case slices?
The answer is yes. Using extend means that we move behaviour from one use case to another; we start by literally cutting and pasting text between the two use-case narratives. More specifically we take out one or more alternative flows and place them in a use case of their own. In this case the Alternative Flows AF16, 17, 18 and 19, which are all about the waiting list, would be moved to the new Handle Waiting List use case.

We could have left all the behaviour related to handling a waiting list in the Reserve Room use case. By using extend we have made optional behaviour explicit. In the case of extension the extending use case is performed in the context of the original use case but without the original use case’s knowledge. This means that any use-case slice that requires behaviour of the extension use case must belong to the extension use case. So, extension use cases do have their own use-case slices

Does extension change the number of use-case slices?
Before refactoring we had one use case with its set of use-case slices. The question is what will happen to this set when we factor out the optional behaviour using the extension. Most likely the total number of use-case slices will remain the same because any alternative flow significant enough to get moved to an extension use-case would probably have got its own slice or slices.

Does extension have an impact on the use-case slices?
Yes and no. Yes, because in the use-case slices we must refer to the right flows of the right use cases;   the original use case or the extension use case. No, because the stories and test conditions remain the same independent of the use case they belong to.

Some Examples

Let’s first have a look at the refined narrative of the Reserve Room use case and the narrative of the Handle Waiting List use case

Use Case 2.0 – Slices and Relationships: Extension

Figure 5 – Updated use-case narrative

And below you will find use-case slices from the extending Handle Waiting List use case

Use Case 2.0 – Slices and Relationships: Extension

Figure 6 - Use-case slices of the Handle Waiting List use case

Notice that in the example use-case slice above:

  1. The basic flow of the Reserve Room is always required because the Handle Waiting List (extension) use case cannot be performed without it.
  2. Alternative Flow 16 of the original Reserve Room use case has become the basic flow of the  Handle Waiting List (extension) use case.
  3. Alternative Flow 17, 18 and 19 of the original Reserve Room use case have become Alternative Flow 1, 2 and 3 respectively of the Handle Waiting List (extension) use case.

Final words

So, as you can see use-case slices are as effective for use cases and use-case models that use the extension mechanism as those that don’t.  In the next blog in this series we will examine the effect of the generalize relationship on the slicing of the use cases.

This post was co-authored with Ian Spence.

Useful links:

Use Case 2.0 Training Classes

Use Case 2.0 – Slices and Relationships: Inclusion

Since the introduction of Use-Case 2.0 we have received a number of questions about use-case slices and in particular how they relate to the concepts of include, extend and generalization.

In this blog we will look at the impact of the include relationship on use-case slicing.

What’s the Problem?

An include relationship is used when two or more use cases share common behaviour. This is then factored out into a separate use case.

Consider the case where we have two separate use cases Register Birth and Register Change of Address. Even though both use cases are concerned with registration these are separate use cases because  the flow of events and the business rules are quite different. They share however common behaviour. Both include a description of all the ways a case worker can find a citizen when registering births and address changes. As shown in Figure 1, the common behaviour can be re-factored  into a single Find Citizen Use Case that is included in both of the original use cases.

Use Case 2.0   Slices and Relationships: Inclusion

Figure 1 – The re-factored use-cases

Before the re-factoring it was very easy to slice up the original two use cases. The question now is what will happen to the use-case slices when we make use of inclusion:

  • Does an inclusion use case have its own use-case slices?
  • Does inclusion change the number of use-case slices?
  • Does inclusion have an impact on any existing use-case slices?

Does an inclusion use case have its own use-case slices?
Inclusion means that we move behaviour from one use case to another; we literally cut and paste text between the two use-case narratives. However, this does not mean that we move compete stories or use-case slices. This is because an inclusion use case is never performed on its own. In the above example the Register Birth or the Register Change of Address use cases are in control of when the Find Citizen use case is performed. Because an included use case is never performed independently of its including use case it does not have its own slices. This means that all the slices remain in the original use-cases, and that the included use-case does not have use-case slices of its own.

Does inclusion change the number of use-case slices?
Before refactoring we had two use cases and each use case has its own set of use-case slices. So what will happen when we factor out the common behaviour using the inclusion mechanism? Because an included use-case does not have use-case slices of its own, the total number of use-case slices remains the same. Each of the original use-cases keeps its original number of use-case slices.

Does inclusion have an impact on the use-case slices?
The use-case slices of the original use-cases are indeed impacted. Before refactoring the original use-case slices referred to flows contained within one use case. After refactoring the use-case slices of the base use-case refer to flows in two use cases: 1) the original use-case and 2) the included use-case.

Note: if new flows are added to the included use cases then new slices will be needed in all of the original use cases.

Some Examples

Use Case 2.0   Slices and Relationships: Inclusion

Figure 2 – Example Basic Flow use-case slices

Before inclusion all required behaviour for slice #1 of the use case Register Birth and slice #1 of the use case Register Moving House was contained in their respective basic flows.  After inclusion these slices reference the basic flow of their original use case and the basic flow of the Find Citizen use case. This is indicated in the slice by stating the name of the use case in front of the flow, in this case Find Citizen.BF.

Use Case 2.0   Slices and Relationships: Inclusion

Figure 3 – Example Alternative Flow use-case slices

Before inclusion all required behaviour for slice #2 of use case Register Birth and slice 2# of use case Register Change of Address was contained in their respective basic and alternative flows. The goal of the alternative flows is to handle finding citizens that are residents of different municipalities. After inclusion these slices required require the basic flow of their original use case, the basic flow of the Find Citizen use case and alternative flow 1 of the Find Citizen use case.

If it doesn’t affect the number of slices why both with includes?
The benefits of re-factoring a use-case model to use includes are not changed by the use of use-case slices. They can still make the model easier to understand and maintain, and provide clues to the developers that the included behaviour will be re-used in different circumstances.

Final words
So as you can see use-case slices are as effective for use cases and use-case models that use the inclusion mechanism as those that don’t.  In the next blog in this series we will examine the effect of the extends relationship on the slicing of the use cases.

This post was co-authored with Ian Spence.

Next Stop Agile: All Change?

“Before we become agile, do we really need to change everything?”

I was recently asked this question by a client who is just starting on their agile journey.

The potential of agile to change everything often leads people to think that they have to change everything before they can become agile. Instead of seeing opportunities and potential they see obstacles and barriers, to the extent that they’re sometimes too scared to even dip their toes in the agile waters.

The introduction of agile values, and in particular agile practices such as iterative planning and backlog-driven development, will lead to changes in the quality and timeliness of the software produced. This in turn will provide you with lots of opportunities to improve other things such as organizational structures, communication channels, and funding procedures.

To get started there are a few things that definitely need to be changed. These will be focussed in three key areas:

  • Resourcing teams – the agile and iterative approach requires cross-functional teams. Testers for example will now be needed through-out the project, as will test environments;
  • Reporting progress – the regular iterative assessments can be used to replace monthly or other reports. There will be a switch towards concrete measures and away from “pseudo-measures” such as earned value;
  • Planning projects – projects will now be iterative and incremental rather than waterfall. The number and nature of the milestones will change, although you may choose to start your initial agile projects with a “requirements” phase and end with and “acceptance testing” phase. Note: the development will still be done iteratively with testing done every iteration - there will just be some priming of the pump before the iterations start, and some additional acceptance testing once the development is complete.

Once the teams have developed the capability to produce high quality software quickly and effectively, the door opens for even more improvements – in particular:

  • Just in time and just enough requirements – affecting the product owners, product managers and the business
  • Progressive funding models – affecting how you fund your projects
  • Agile contracts with suppliers – affecting your supplier relationships and contracts
  • Improved team cohesion and longevity – affecting line management and resourcing
  • Agile business change – affecting business projects and business programmes
  • Tools and infrastructure – affecting licensing and environments

And finally, opportunities are opened up for an agile organization, with further improvements to:

  • Line management
  • HR
  • Governance
  • Organizational Structures
  • Company Culture

It is always a good idea to brief all the management and business people involved in the projects and teams as they will be affected by the initial round of change, and will benefit from seeing the opportunities that an improved, agile, software development approach will provide.

The good thing is you don’t need to change everything at once, or even at all in many cases. Personally I would always bed in the first round of changes before worrying about the second and third lists of things. This approach values individuals and interactions over processes and tools, as it enables the development teams to improve without dictating to the other parties involved in the business. Once they see the opportunities opened up by agile development practices they will also want to embrace agility and improve their own ways of working.

Stimulating a discussion: Getting to needs

Stimulating a discussion: Getting to needsOne of the frequent questions we are asked is "how can I get the time to explore needs when the business says that it is already done - "it's in the business case", even when it is obviously not complete?  This is actually a pretty common occurrence - nobody wants to take time to understand needs because they think it has already been done. Read More

What is an Iteration?

What is an Iteration?

Iteration: A self-contained mini-project, with a well-defined outcome: a stable, integrated, and tested “release”. Let’s look at the three aspects of this definition in more detail.

A software development project produces a new release of a software product by transforming a set of users’ requirements into a new or changed software product. With an iterative and incremental approach, this process is completed little by little, step by step, by splitting the overall project into several mini-projects, each of which is called an iteration.

From the perspective of the development team, each iteration can be considered to be a self-contained
project. This approach is very powerful because it enables the development team members to focus on meeting their immediate objectives and ensures that the results generated are frequently and objectively measured. The management team needs to ensure that the iteration objectives form
a credible part of the larger overall project.

The management team needs to reinforce this way of working by ensuring that each iteration has the following:

Read More

Giving requirements a bad name by Ivar Jacobson

A while back I was giving a presentation on requirements errors and someone made the observation that they thought the term "requirement" was, in itself, misleading. The  gist of his argument is that the very term implies something that is "required", that it has to be done.  In reality, most "requirements", at least as initially stated, are somewhat vague statements of things that could be done, but they often need quite a bit of work to determine what is really needed.  It would be better to call them, at least initially, "wishes".

 

Unfortunately we are probably stuck with the term "requirement", but it can help to realize that as initially identified "requirements" tend to be vague, filled with incorrect assumptions about what the real problems and solutions look like.  Some organizations call these sort of things "stakeholder requests", which gives them a way to capture them without anyone inadvertently assuming that these are the actual requirements.  They then go through an investigation and refinement process before discovering the actual "requirements".  Along the way, various other kinds of things may be discovered: needs, goals or objectives, desired outcomes, as well as terms (such as would be found in a glossary), among other things.

 

The important thing is not how you categorize (this can get out of hand as well), but that you recognize that even when someone tells you something is a requirement you should not just accept their statement at face value - you need to make sure you understand the real need, and especially what they need to achieve. Only by doing so will you know whether the thing they are asking for is really "required".