Requirement Hierarchy - Alibaba DevOps Practice Guide Part 4

This article is from Alibaba DevOps Practice Guide written by Alibaba Cloud Yunxiao Team

The first step to solving delivery problems is finding what needs to be delivered. If the object to be delivered is vague, it may be hard for us to define a clear process, let alone ensure efficiency.

Therefore, we need to find which object needs to be delivered, including where it comes from, what it serves, what kind of hierarchy it contains, and the value implied by each layer.

Typical Requirement Hierarchy

Typical Relationships between Requirement Sources and Requirement Hierarchy

The figure above shows a typical requirement hierarchy. It contains three layers: business requirements, product requirements, and technical tasks.

Business Requirements

Requirement collaboration and delivery ultimately serve the business, which refers to delivering business value and ensuring business success. Business requirements may be originated or transformed from original user requirements, initial business ideas, or product ideas. The original requirements are converted into formal business requirements through filtering, classification, and analysis.

Organizations with different characteristics may have a way of naming business requirements. For example, requirements mainly driven by users may be called user requirements, and those sold externally in the form of products may be called solutions or product features. Regardless of their names, they all serve the business goals and eventually become product features. This article calls them business requirements, emphasizing the business attributes.

Business requirements carry business values. A business requirement is a basic unit for system acceptance and operations and release. It can be released and operated independently when needed. Generally, it is collected, created, and maintained by business personnel, such as business operation personnel or business analysts.

Product Requirements

Product requirements can be divided into two categories. The first category is split from business requirements, which serve today's business. Generally, it is split by business owners or product managers based on business requirements. The second category comes from product planning. Requirements of this category do not serve the current business, they but are implemented to make basic and advanced preparations for future business. They typically include basic product functions, advanced technical layout, and technical restructuring. They are usually created and maintained by product managers and technical teams.

Product requirements are specific functions of products. They are the basic units for product integration, testing, and system deployment. When a business requirement involves multiple product features, it is split between multiple products as product requirements. For example, one business requirement is to support pre-locked inventory in the supply chain. If you want to implement this requirement, functions of multiple products, such as supply chain planning, inventory management, order fulfillment service, and financial settlement, need to be changed, and multiple product requirements are created.

Technical Tasks

Technical tasks refer to specific implementation tasks. It is a basic unit for work assignment and implementation. Technical tasks are broken down from product requirements, which include the tasks of different functions, such as frontend, backend, and algorithm. The Technical Team usually splits the technical tasks.

Hierarchy Variants in Different Contexts

Businesses and products have different levels of complexity and hierarchies. The following figure shows three different variants, which apply to simple, typical, and complex businesses and products from left to right, respectively.

Requirement Hierarchy Adjustment Based on Different Business and Product Complexity

The first pattern in the figure applies to simple businesses. Businesses and products correspond to each other. Business requirements and product requirements are merged into one layer. In this pattern, original requirements are transformed into product requirements, and the product requirements are broken into technical tasks. This pattern is suitable for simple Internet businesses, enterprise applications or tool products, and businesses at the start-up stage.

The requirement may be too large for complex products and businesses if there is only one layer of the product requirement. At this time, the requirement can be broken into two layers, product characteristics and product requirements, which corresponds to the third pattern in the figure. It applies to telecommunication products, basic technology products, complex enterprise applications, and other complex businesses. However, the second one with three layers can cover most of the scenarios in reality.

Define Clear Meanings and Purposes for Each Layer

In different methodology systems, requirement hierarchy is defined differently. For example, Epic, Story, and Task are commonly used in Scrum to describe the hierarchy of requirements. The division of this hierarchy is based on the required size. Among them, Story (user story) is the description of requirements from the perspective of users, which needs to be completed in one iteration. Epic (epic) is a giant story or story set that needs to be divided into stories. Task is a further splitting of stories, and its daily progress needs to be tracked and updated. Usually, it can be completed by one person, and the workload does not exceed 20 hours.

Different Naming Methods for Requirement Types

As a general method, Scrum pursues universality, and its recommended requirement hierarchy deliberately avoids business attributes. However, while improving universality, it blurs the business meaning during the collaboration process, making it impossible to define precise and effective collaboration processes.

We believe we can only define a meaningful collaboration process and the responsibilities and activities of related personnel by defining the requirement hierarchy and the value implied by each layer. We can determine whether this process matches the value implied. Therefore, when we design a requirement hierarchy, we need to clarify the meaning and value of each layer.

Summary

This article analyzed the requirement sources, the requirement hierarchy, and the value of each layer. It is a standard reference model with good universality that can be customized based on different business characteristics. For example, layers can be added or reduced based on the complexity of businesses, or the business requirement name may be changed based on the business delivery method. Part 5 of this 27-part series will introduce business-driven collaboration.

Community

Requirement Hierarchy - Alibaba DevOps Practice Guide Part 4

Typical Requirement Hierarchy

Business Requirements

Product Requirements

Technical Tasks

Hierarchy Variants in Different Contexts

Define Clear Meanings and Purposes for Each Layer

Summary

Read previous post:

Read next post:

Alibaba Cloud Community

You may also like

Comments

Alibaba Cloud Community

Related Products

Business Mid-End Solution

Alibaba Cloud for Supply Chain

DevOps Solution

Alibaba Cloud Flow