Splitting Requirements at Scale

Online Ordering Portal Example

Let‘s start with an example.

A typical online portal solution should allow customers to browse a catalogue of products, to select particular items and add them to a shopping basket, and then to select a payment method and place the order. A parsing of this first problem statement already suggests an initial breakdown of requirements, shown below. In this case the individual requirements correspond to steps in the ordering process.

Let us say now that the solution needs to support different types of product: clothes, fresh food and drinks, for example. The ordering process in each case will have some specialised requirements: selection of clothes will involve specifying size and colour, fresh food may be ordered by weight and/or class, while drinks have particular packaging options (e.g. unit, box, crate). So, we now have requirements for three variations of the ordering process, where some aspects will be shared while others are specific to each variant (shaded below).

Consider now what happens if the solution should in addition support both retail (B2C) and wholesale customers (B2B). Further variations of the ordering process based on customer segment emerge:

If we now combine both product type and customer segment requirements, we may find further special behaviours: when selecting from the product catalogue for product type ‘drinks’ in customer segment ‘wholesale’, for example, the packaging choice may be further restricted to ‘crates’ only. So, considering all combinations over these particular dimensions, we have up to 3 x 2 potential process variants, each having requirements at each process step:

Considering, then, the problem space as a whole, we have identified several dimensions over which the overall goal of an online portal solution can be broken down into smaller parts. It is possible to think of requirements in terms of their coordinates along these dimensions (order step x, product type y, customer segment z), where those coordinates provide a business process context for specific requirements.

I’ll return to this idea of dimensions in the problem domain later when considering strategies for splitting requirements, especially in complex problem domains. First, though, let’s remind ourselves of our general goals in organising a set of requirements.

Bottom Up or Top Down

One way to approach the organisation of requirements is to first gather a large number of individual requirements from stakeholders and then group these under some more manageable number of categories. Though requirements may come in all sizes, such an approach tends to be less about a top-down splitting of requirements and more about bottom-up grouping. A problem that has been observed with this method, however, is that the resulting organisation of requirements tends to follow that of the organisation in which those requirements were gathered^[1][2]: that is, the roles and departmental boundaries of the stakeholders and their existing understanding of systems tend to get reflected in their stated needs.

In contrast to the above, a major theme of modern software development approaches – from use case analysis through agile methods focusing on business value creation - has been to structure requirements around business processes. Here our starting point is an event occurring in the business context (i.e., external to the solution), rather than any reference to the internal structure of the organisation or systems that it employs. From this starting point we can then approach the problem top-down, looking for the most optimised process through the organisation to fulfil the goals, and breaking that process down into its constituent parts. In this latter approach it is evident that requirement splitting plays an important role: end-to-end processes are likely to be too large to be passed directly to development teams and will therefore require further decomposition.

Agile Requirement Splitting

Though the idea of breaking up or decomposing large requirements is not in itself new, of course, the term ‘requirements splitting’ has entered more common usage in the context of agile methods. The idea here is to take a large requirement delivering business value and to successively split it until it is small enough to be implemented by a team within a development iteration; without sufficiently small stories, the wheels of the agile process^[3] will soon stop turning!

In discussions of requirement splitting the agile literature tends to focus on patterns for splitting individual requirements^[4][5], but says less about the overall structure of the set - or hierarchy - of requirements that results from this splitting. This may be because any top-down organisation of requirements hierarchies sounds too upfront or heavyweight in an agile context. As I will try to set out in the remainder of this article, however, some requirements structuring over the whole (and evolving) requirements set will bring important advantages, particularly in complex problem domains. It will, in fact, make your project more agile, not less, I would argue. The trick, as ever, is finding the right principles and using them at the right time!

In any case, the following discussion is not intended to be restricted to any particular software development lifecycle. Rather it is concerned with general structuring principles which may be set out at the start of a project, or may emerge during a product lifecycle as and when the need arises.

Requirements Hierarchies

As we split large requirements into medium-sized requirements, and the medium-sized requirements into smaller ones, we are creating layers in a hierarchy, where each layer represents the requirements at some level of abstraction. Furthermore, if we use consistent criteria for selecting and splitting at each stage in the process, then each layer in the hierarchy should present a consistent view of the problem at some particular level of detail; if, on the other hand, each requirement is split on its own merits and without reference to the hierarchy as a whole, layers in the hierarchy will have no such significance.

Thus, for example, if our top-level requirements represent business processes (place order, query order, return product, restock products, etc.), this level of detail may be sufficient for a management overview of the system under discussion. If we then split by product type or customer segment, we have mid-level requirements (order clothes product, query wholesale order, etc.) that are relevant for business owners responsible for certain product lines. Split again by process step or affected component and we have a view of requirements relevant for IT and the teams responsible for their implementation.

A second characteristic of requirements hierarchies is that for every requirement in the lower layers it should be possible to trace back its role in fulfilling some higher-level requirement, and ultimately in delivering the business process addressed by the top level requirement. This will be the case as long as child-parent relationships can be traced. Parent stories, therefore, provide context for lower-level requirements, and allow information that is relevant to the business process as a whole – for example the value creation associated with that process - to be captured just once and not repeated in each sub-requirement of that process.

Requirements within Hierarchies

The characteristics of the hierarchy itself will in turn influence the way that requirements are expressed depending on their placement within that hierarchy.
At the top of the hierarchy we have already stated that we want to capture external behaviours of the solution: that is, processes that will run in response to business events in the system context (for a more thorough discussion of this topic see ^[6]). An appropriate form of requirement here is the user story, often conforming to the template:

• as a < user > I want a < behaviour > so that < purpose >

An interesting variation, as suggested for example by ^[6], is:

• as a < beneficiary > I can have the < benefit >

In both cases, there is an emphasis on not only what is required, but for whom and for what purpose. This is not only to increase our general understanding of the requirement; it also allows room for more creative solutions to the problem. We are more likely to suggest an alternative solution if we understand its general purpose than if we have already stated ‘the system shall do x’.

As we move down the hierarchy, however, then according to the second characteristic of hierarchies discussed in the previous section (traceability), the beneficiary and purpose are often already clear and may not need to be repeatedⁱ. Here a simple verb object will often suffice:

• Add Product to Basket
• Select Payment Method

Dependencies among Requirements

At the bottom of the hierarchy, it is not just the form of the requirement but its size that plays a key role: as stated earlier, to consider requirements ready for development they should be small enough to be implemented by a team within a single iteration. Size alone, though, is not the only factor that will allow requirements to pass smoothly through a development iteration – equally important is the extent to which implementation of one requirement is dependent on others.

Now it is at around about this point in the conversation that in the Agile literature you will typically come across INVEST criteria:

• “I” ndependent
• “N” egotiable
• “V” aluable
• “E” stimable
• “S” mall
• “T” estable

Somewhat controversially (INVEST being acknowledged as great wisdom in the matter of agile requirements!), I am going to suggest that this list may not have answered all our questions just yet. Take the term ‘independent’, in particular: no question here that a lack of dependencies simplifies the implementation. How, though, do we in fact achieve independent requirements where dependencies are not unfortunate accidents, but rather inherent to the nature of complex problems?

If, for example, we have broken a process down into its steps, then those steps are clearly dependent on one another in sequentially carrying out that process. If we have broken the process down into variants by product type or customer segment, on the other hand, dependencies will almost certainly exist among the respective requirements where common process steps are involved, or in sharing a common data model or interface.

Our goal here, I would argue, is not in fact to create independent requirements, but rather to create requirements for which the dependencies are made as clear as possible. And the best way of doing this is to make those dependencies explicit in the structure of our hierarchy, rather than hidden within the requirement itself. This is what will best support the prioritisation and management of those requirements.

Dependencies in the Hierarchy

Thus, in Figure 8, we do not claim that requirement 1.1.2 is independent of 1.1.1 or 1.1.3 – on the contrary, it has clear dependencies on the preceding and subsequent steps in the process. These dependencies can be clearly seen if we understand that the layer in the hierarchy in which those requirements appear represents the process split into its steps.

Similarly, the requirement does not deliver end-to-end business value in its own right; but its value in supporting its parent requirements 1.1 and 1 can be clearly seen by its position within the hierarchy.

Our goal, then, is to create hierarchies with meaningful layers that represent the problem at different levels of abstraction and help us to understand, and make explicit, dependencies inherent to the domain. The role of each individual requirement in delivering business value, and its likely dependencies on other requirements in doing so, are thus made as transparent as possible.

Splitting Requirements

Having discussed then the characteristics of requirements hierarchies as a whole, let’s return to the original question of how to split requirements in order to build such hierarchies.

In Figure 9 (taken from ^[7]), we represent two dimensions of the problem shown as horizontal and vertical lines.

Horizontal lines represent process slices, where we retain the idea of an end-to-end business process but increase the specificity by, for example, segmenting the dataset on which it is based or by narrowing down the set of business rules that it should follow. Product type and customer segment are examples of specific datasets forming horizontal process slices in our online retail example.

Examples of business rules that create narrower slices might be ‘pay by credit card only’ or ‘delivery to UK addresses only’.

Vertical linesⁱⁱ, on the other hand, represent sub-divisions based on the internal structure of the solution or organisation. Thus, the process steps in our ordering example might be vertical lines here; divisions by department or existing systems within the architecture are other examples.

When choosing between the two dimensions in this framing of the problem, we (the authors of the IREB RE@Agile handbook^[7]) state that we prefer horizontal slices. Nothing very controversial here: this is essentially the same argument that we used for our choice of business processes as our top-level requirements i.e., that we can drive the analysis and prioritise the implementation around slices of functionality that deliver end-to-end business value.

Digging deeper, though, and faced with scenarios such as described above where we see not one vertical axis but multiple dimensions in the problem domain, the question becomes not which single splitting strategy to use, but rather: how, and in what order, can we apply multiple splitting strategies?

Order of Splitting

The sequence of splitting decisions taken will determine which topics are addressed as large, mostly self-contained requirements at the top of the hierarchy, and which by smaller, more fragmented requirements lower down the hierarchy. In general, it will be easier to optimise the implementation around high-level requirements than it will be for collections of interdependent, lower-level requirements.

To illustrate this, in our Online Retail example consider what happens if our first splitting decision is based on customer segment:

If the business decision is now to try to go to market with the B2B solution first, we have no problem in identifying the requirements we need to prioritise (requirement 1 and its children).

If we had instead chosen to first split by product type, our hierarchy would look something like:

Rather than a single B2B requirement we now have a collection (1.2, 2.2, 3.2). That is, the structure we have chosen for organising requirements no longer supports as easily discussions around the prioritisation and implementation of this topic. So, assuming we have a good understanding of business priorities at the outset, then the alignment of these priorities with our approach to splitting requirements is an important guideline.

Looking again at Figure 10, consider requirements 1.1 and 2.1 (Clothes Order requirements in B2C and B2B cases respectively). Assuming that both requirements ultimately belong within a single product, there is likely to be some commonality here: the product catalogues used in each case are likely to overlap, and functional requirement, for example relating to selecting size and colour when placing the order, will be similar if not identical. Overlap in the requirements is, in turn, very likely to mean dependencies during the implementation: for example, a shared data model and/or common UI logic or components.

For reasons both of efficiency of description and in order to avoid potential dependencies, we aim to minimise any unnecessary overlap among requirements. Now there are several strategies for achieving this – factoring out data models or UI patterns into common documents is another – but the way we build the hierarchy in the first place plays a key role. If, for example, we know that the B2C and B2B portals are likely to be entirely separate solutions - perhaps implemented on different platforms altogether - then we might prefer the hierarchy from Figure 10 in the knowledge that there will be relatively few dependencies between 1.1 and 2.1.

So when splitting requirements we are guided on the one hand by a top-down alignment of high-level business process requirements and business priorities, while on the other a more bottom-up approach, taking into consideration areas of commonality over the full set of requirements, will also influence our approach. Might these two views of the problem conflict? Yes, very possibly! Finding the right strategy is therefore a balancing act, requiring all our skill and experience as BA’s. Getting it right, though, will play a major role in ensuring not only that business priorities can be effectively managed, but also in placing flag posts in the ground that lead to a high quality solution design.

Putting it all together

To finish let‘s look at a more complex example in which we put several of these ideas together. The context here is a high speed (gigabit) internet connection product based on optical fibre (fibre-to-the-home, or FTTH) technology.

Let us say that in a particular telecommunications operator, MyTelco, similar internet connectivity products - based on other technologies such as DSL or cable - are already available in the system landscape. The scope of this project is therefore to introduce specialised processes for FTTH technology built on top of existing order processes.

Our primary goal can be stated as:

• As a potential customer of MyTelco I want gigabit internet at an address that is, or will be, part of the FTTH network

Though a number of processes are involved in supporting such a product, we will focus here on the new customer order process. Here, then, our top-level story is:

• As a new customer I can place an order for a gigabit tariff at an address that is, or will be, part of the FTTH network

As the business wants to offer this product over three sales channels (online, by phone to Customer Services or via an Agent in a High Street store), a first splitting criterion immediately suggests itself:

Early analysis of the problem domain soon reveals two significant variations in the process, according to whether the basic infrastructure already exists (i.e., the optical fibre network already extends to the premises), or whether further network construction is still required. These two process variants are termed the “connected” and “not connected” processes.

If we also wish to split requirements according to this criterion, we are faced with our first choice in organising the hierarchy. Early discussions with business heads showed a clear desire to prioritise the connected process and an intention to launch commercially on all sales channels at the same time. Using these priorities in our splitting strategy (i.e., first splitting in line with business priorities) we then have:

Click for detailed view of Figure 13

In the continued search for finer business slices, analysis revealed that the ordering process can be streamlined if (in the connected case) an identifier on the fibre socket, known as the home-id, could be provided by the customer when placing the order. In the not connected case, on the other hand, it is significant whether or not the customer is the owner of the property, as the property owner‘s permission must be sought before construction can begin. In Figure 14, further business slices based on these cases are introduced in the hierarchy, once again above the level of sales channel:

Click for detailed view of Figure 14

As in our earlier examples, the steps in the ordering process represent another dimension of the problem domain. The list below shows some of the most significant FTTH- related steps in the ordering process^iv.

1. As a Customer ordering a tariff with FTTH I can choose the right Building Part for the connection
2. As a Customer ordering a tariff with FTTH I can indicate whether or not the fibre socket is available
3. As a Customer ordering a tariff with FTTH I can provide my home-id when placing the order
4. As a Customer ordering a tariff with FTTH I can order a compatible router
5. As a Customer ordering a tariff with FTTH I can order an ONT device
6. As a Customer ordering a tariff with FTTH I can provide my home-id after placing the order via Selfcare
7. As a Customer ordering a tariff with FTTH I can provide the Property Owner's permission for construction after placing the order via SelfCare

Where, then should process steps be placed within the hierarchy? If we follow our guideline of splitting according to end-to-end, business value generating process slices, then process steps would be our bottom layer. As many process steps will be shared among our multiple process variants, however, there would be a high degree of overlap among the bottom-level requirements.

One suggestion is shown in Figure 15 below. Here we have organised the hierarchy itself over two dimensions such that each lower-level requirement now has two parents – a business slice and a process step.

Click for detailed view of Figure 15

An ‘X’ in the table indicates that there is a requirement at the intersection of that particular process slice and the process step (and conversely an empty cell means that the particular process step does not apply in certain cases). Each of the lower-level requirements now has two parents: thus, if the row and column headings are our epics, say, the cells containing X’s might form a set of features, each of which of course should be written and analysed (and potentially further split) in its own right. As we formulate these features, though, we have the advantage that common business rules, applying to either the process slice or the process step, have been factored out into one of the two parent epics. We only have to concern ourselves with what is particular to that cell in the table, rather than repeating the same rules across many requirements.

What I hope this example shows is that when organising a requirements hierarchy it is not so much the particular geometry of the tree structure that is the key, but rather identifying the important dimensions in the problem domain (remember Figure 5) and working creatively with these to find the right structure.

Conclusion

In this article we have tried to look beyond the splitting of individual requirements to consider the effects of splitting decisions on the set of product requirements as a whole. We have looked at the organisation of requirements in hierarchies and discussed the benefits when those hierarchies have consistent layers representing the problem at certain levels of abstraction. Furthermore, we have considered how such hierarchies can be constructed using splitting strategies that are based on key dimensions identified within the problem space. In the final section we have looked at an example which expands on the tree structure as a basis for the requirements hierarchy, but that nevertheless maintains the principles of clear abstraction levels and requirements traceability.

As a closing remark I would like to emphasise again that the approaches discussed above do not imply a full, upfront knowledge of the requirements set, gathered, for example, after a lengthy analysis phase. The structures and abstractions that we use to manage requirements hierarchies may emerge as the project progresses and the need to manage complexity increases. It is important, though, I would argue, that as business analysts we give full and early consideration to the problem space as a whole and in doing so seek out these key abstractions, as it is this that will give us the tools we need to split requirements consistently and strategically.

References

• [1] en.wikipedia.org/wiki/Conway%27s_law
• [2] Hruschka, Business Analysis and Requirements Engineering, 3rd edition, Hanser 2023. Ch. 3.
• [3] Diagram from instituteprojectmanagement.com/blog/agile-methodologies/
• [4]Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
• [5] humanizingwork.com/the-humanizing-work-guide-to-splitting-user-stories
• [6] Robertson & Robertson, Business Analysis Agility, Addison-Wesley 2019. p. 95.
• [7] Hruschka, Lauenroth, Meuten, Rogers, Gärtner, Steffe, Advanced Level RE@Agile Handbook, 2022. Ch. 3.

Footnotes

• i As my IREB colleague Peter Hruschka pointed out, there are also exceptions where the beneficiary does in fact change in sub-ordinate requirements. For example, under the requirement ‘place order’ (beneficiary: customer) we may have requirements such as ‘validate credit card’ or ‘perform credit check’ with other beneficiaries (i.e., finance/fraud departments).
• ii Note that some authors reverse these dimensions, with horizontal layers representing an architectural stack and vertical lines the end-to-end processes. The argument, though, remains the same!
• iii In Figure 11 a similar argument could be made for requirements 1.1, 2.1 & 3.1: here the commonality will come from the desire to have a consistent user experience for the B2C solution across different product types.
• iv Note that as the solution builds on preexisting processes, other more basic steps – select product, show prices, place order, etc. - are not included here