Quality requirements, also known as non-functional requirements (NFRs), quality of service (QoS) or technical requirements, address issues such as reliability, availability, security, privacy, and many other quality issues. The following diagram, which overviews architectural views and concerns, provides a great source of quality requirement types (the list of concerns). Good sources for quality requirements include your enterprise architects and operations staff, although any stakeholder is a potential source for them.
Figure 1. Architectural views and concerns.
Why Are Quality Requirements Important?
Stakeholders will describe quality requirements at any time, but it’s particularly important to focus on them during your initial scoping efforts during Inception as you can see in the goal diagram below for Explore Initial Scope. Considering quality requirements early in the lifecycle is important because:
Capturing Quality Requirements
Figure 2 depicts the goal diagram for Explore Scope. As you can see, there are several strategies for exploring and potentially capturing quality requirements.
Figure 2. The goal diagram for Explore Scope (click to enlarge).
Let’s explore the three strategies, which can be combined, for capturing quality requirements:
Of course a fourth option would be to not capture quality requirements at all. In theory this would work in very simple situations but it clearly runs a significant risk of the team building a solution that doesn’t meet the operational needs of the stakeholders. This is often a symptom of a teams only working with a small subset of their stakeholder types (e.g. only working with end users but not operations staff, senior managers, and so on).
For teams that are applying agile strategies to Data Warehouse (DW)/Business Intelligence (BI) development is it fairly common for them to take a Disciplined Agile (DA) Approach to DW/BI due to DA’s robustness. A common question that comes up is how do you write user stories for DW/BI solutions? Here are our experiences.
First, user stories should focus on business value. In general, your stories should answer the question “What value is being provided to the user of this solution?” In the case of a DW/BI solution, they should identify what question the DW/BI solution could help someone to answer, or what business decision the solution could support. So “As a Bank Manager I would like the Customer Summary Report” or “Get Customer data from CustDB17 and TradeDB” would both be poorly written user stories because they’re not focused on business value. However, “As a Bank Manager I would like to know what services a given customer currently have with BigBankCo so that I can identify what to upsell them” is. The solution to implement that story may require you to create the Customer Summary Report (or there may be better ways at getting at that information) and it may require you to get data from CustDB17 and TradeDB (and other sources perhaps).
Here are some examples of user stories for a University DW/BI solution:
Second, user stories on their own aren’t sufficient. User stories/epics are only one view into your requirements, albeit an important one. You’ll also want to explore the domain (e.g. do some data modelling), the user interface (e.g. explore what reports should look like), the business process (e.g. what are the overall business process(es) supported by your DW/BI solution), and technical views (e.g. how does the data flow through your solution architecture).
Third, data requirements are best addressed by domain modelling. As you are exploring the requirements for your DW/BI solution you will hear about data-oriented requirements. So capture them in your domain model as those sorts of details emerge over time. Consider reading Agile/Evolutionary Data Modeling: From Domain Modeling to Physical Data Modeling for a detailed discussion of this topic.
Fourth, technology issues are best captured in architecture models. You will also hear about existing legacy data sources and in general you will need to capture the architecture of your DW/BI solution. This sort of information is best captured in architecture models, not in stories.
A few more thoughts:
Like it or not, functional dependencies occur between requirements. This can happen for many reasons, as we discussed in Managing Requirements Dependencies Between Teams, and there are several strategies for resolving such dependencies. In this blog posting we explore what happens when a functional dependency between two requirements exists AND one requirement is implemented by an agile/lean team and another by a traditional/waterfall team.
In our example requirement X depends on requirement Y. Neither requirement has been implemented yet (if requirement Y had already been implemented, and better yet deployed into production, the point would be moot). When we refer to the “agile team” this team may be following any one of the lifecycles supported by DAD (Basic/Agile, Advanced/Lean, Continuous Delivery, or Exploratory/Lean Startup).
Scenario 1: An Agile/Lean Team Depends on a Traditional Team
In this scenario X is being implemented by an agile team and Y is being implemented by a traditional team. From the point of view of the agile team, this is very risky for the following reasons:
There are several strategies the agile team may decide to take:
Scenario 2: A Traditional Team Depends on an Agile/Lean Team
In this scenario X is being implemented by a traditional team and Y by an agile team. From the point of view of the traditional team, this might be seen as risky for the following reasons:
The fact is that scenario 2, a traditional team relying on a disciplined agile team, is very likely an order of magnitude less risky than the opposite (scenario 1). Either scenario will prove to be a learning experience for the two teams, particularly the one that relies on the other team. Going into the situation with an open mind and a respectful strategy will greatly increase the chance that you’ll work together effectively.
Sometimes functional dependencies occur between requirements that are being implemented by different teams. For example, requirement X depends on requirement Y and X is being worked on by team A and Y is being worked on by team B. This generally isn’t a problem when requirement Y is implemented before requirement X, is a bit of an annoyance if they’re being implemented in parallel (the two teams will need to coordinate their work), and an issue if X is being implemented before Y. For the rest of this posting we will assume that X depends on Y, X is just about to be implemented, and Y has not yet been implemented. Previously in Managing Dependencies in Agile Teams we discussed strategies for addressing such dependencies, including reordering the work or mocking out the functionality to be provided by Y. In this posting we explore the implications of managing requirements dependencies between an agile team and a lean team.
Managing requirements dependencies between an agile and lean team is similar to that of managing dependencies between two agile teams, although there are important nuances. These nuances stem from differences in the ways that agile and lean teams manage their work. Figure 1 depicts how agile teams do so, organizing work items (including requirements) as a prioritized stack (called a product backlog in Scrum). Work is pulled off the stack in batches that reflect the amount of work they can do in a single iteration/sprint. With agile teams the entire stack is prioritized using the same strategy, Scrum teams will prioritize by business value but disciplined agile teams are more likely to consider a combination of business value and risk. Figure 2 shows that lean teams manage their work as an options pool, pulling one work item out of the pool at a time. Lean teams will prioritize work items on a just in time (JIT) basis, determining which work is the highest priority at the point in time that they pull the work into their process. As you can see in Figure 2, they will consider a variety of factors when determining what work is the most important right now.
Figure 1. Agile work management strategy.
Figure 2. Lean work management strategy.
When an agile team depends on a lean team challenge is relatively straightforward. Because lean teams take on work in very small batches, one item at a time, it gives them much more granular control over when they implement something. As long as the agile team lets them know in a timely manner that the functionality needs to be implemented it shouldn’t be a problem. For example, if the agile team is disciplined enough to do look-ahead modelling (an aspect of Scrum’s backlog grooming efforts) then they should be able to identify an iteration or two in advance that they have a dependency on the lean team. At that point the product owner of the agile team should talk with the appropriate person(s) on the lean team to let them know about the dependency so that the lean team can prioritize that work appropriately (perhaps treat it as something to be expedited).
When a lean team depends on an agile team it’s a bit harder, but not much, to address. This time the challenge is with the batch sizes of the work that the teams take in. The lean team is taking in work in a very granular manner, one at a time, whereas the agile team is taking in work in small batches (perhaps two weeks worth of work at a time). From a lean point of view this injects wait time into their process, even though it may just be two weeks, but this wait time is still considered to be waste (muda). Once again the solution would be for the lean team to identify the dependency ahead of time via look-ahead modelling and negotiate with the agile team.
To summarize, requirements dependencies do in fact occur. There are strategies to minimize their impact, in particular implementing and better yet deploying the functionality that is being depended upon before the dependent functionality is implemented, but sometimes it just doesn’t work out that way. So your team will need to be prepared to manage the requirements dependencies that it has on other teams, and similarly be prepared to support other teams with dependencies on them. In this series of blog postings we’ve seen how Agile<=>Agile and Agile<=>Lean dependencies can be managed, next up is Agile/Lean<=>Traditional.
Although we strive to avoid functional dependencies between requirements, the fact is that they occur in practice. They certainly occur between requirements that are being addressed by a single team and they will even occur between requirements being addressed by different development teams. This is particularly true between the subteams within a program (a large development team organized into a “team of teams”).
The following diagram depicts a simple situation where there is an agile program organized into five subteams (A thru E). The way you read the diagram is that the arrows between requirements represent functional dependencies. In this case the requirement fourth from the top on A’s backlog (A4) depends on the one that is second from the top (A2) and on B3 (the requirement third from the top on team B’s backlog). B3 in turn depends on C7, which depends on D3. D3 depends on E4, which depends on D10, which depends on C12, which depends on D14. There could very well be dependencies between other requirements, but for this example we’re only worried about the dependencies originating from A4.
Figure 1: Example of functional dependencies between requirements.
Where Do Functional Dependencies Come From?
Functional dependencies occur between requirements for several reasons:
Of the three reasons for why functional dependencies exist, the first two are clearly within the purview of a Product Owner (PO). The third one, technology driven dependencies, can be trickier because many POs will not be familiar with the underlying technologies. This is one reason why Disciplined Agile Delivery (DAD)’s Architecture Owner (AO) role is so important. The AO and the PO on a disciplined agile team work very closely together. AOs will help POs to better understand the implications of the technologies being used as well as to understand potential implications of the technologies (including technology-driven functional dependencies). These sorts of discussions will occur throughout the lifecycle, although they are particularly important during initial release planning during Inception and during iteration planning and look-ahead planning throughout Construction.
How do You Resolve Functional Dependencies?
Functional dependencies are addressed via three basic strategies:
Within an agile environment, functional dependencies are managed by Product Owners. When the dependencies are between requirements, or more accurately work items, that are being addressed by a single agile team this is fairly straightforward because it’s within the purview of the single product owner.
Now let’s consider how a Product Owner team would manage requirements dependencies within a program, as in the diagram above. In this case let’s assume that each team has it’s own product owner (PO) whom we’ll refer to as PO-A, PO-B, and so on. There are three scenarios to consider when managing requirements dependencies:
How would the entire requirements dependency map for A4, as depicted in the diagram above, be resolved? It depends on what the product owner team decides. At the present moment the overall requirements dependency chain is to be implemented during iterations N through N+3. This may in fact be acceptable and the product owners will decide to live with the impact of mocking out functionality until it is available. Or they may decide to reprioritize the functionality so that it is implemented in a more effective order (perhaps during iteration N+1). The point is that the product owners will engage in negotiation amongst themselves to determine the best order in which the sub teams will implement the functionality.
How do You Manage Functional Dependencies?
Functional dependencies are managed by the Product Owner, or in the case of a program, the Product Owner team. The goal is to do just enough work to maintain the dependencies and no more. When you do not sufficiently maintain the dependencies, perhaps you forget to record that a sub-requirement was created as the result of decomposing a larger parent requirement, then it becomes difficult to ensure that a requirement is properly implemented. When you invest too much effort into maintaining functional dependencies any extra effort beyond the point of sufficiency is a waste. In short, your dependency map should be just barely good enough (JBGE) for the situation you find yourself in.
There are several options available to you for maintaining a functional dependencies:
Figure 2. Example of a simple story map.
Which approach should you take? Our advice is always to keep it simple and use physical tools if your situation permits. Having said that, there are advantages and disadvantages to each strategy:
Earlier we said that the diagram represents a “simple” situation. It is simple in that all five teams are following the same sort of lifecycle, in this case the basic/agile DAD lifecycle. Furthermore the velocities of the teams are roughly the same, which we did for the convenience of the example. Usually the team velocities are very different, due to a combination of different team sizes and different levels of productivity. In a future blog posting we’ll discuss the challenges that arrive when the subteams are following different lifecycles (for example a lean or continuous delivery lifecycle or even a waterfall lifecycle).
Several of the strategies described in the blog posting were first identified in Complex Requirements on an Agile Project (Dr. Dobbs Journal, October 2008).