A Map of Agile Requirements Practices

When dealing with requirements information in agile development, there are many work practices that propose instruction and advice. But sometimes it can be difficult to keep up with the many options: Which of these practices are particularly important? How do they relate to each other?

This article offers you orientation and guidance in the wide and growing field of agile requirements practices. It shows which practices are essential, which can be useful additions, and when you should focus on what.

The figure presents a map of agile requirements practices. All listed practices can be useful to agile requirements. Those highlighted in light blue font color are particularly important. And those in the Core Practices area represent the backbone and starting point of requirements activities in agile development.

Let’s walk through it one step at a time …

Start with User Stories, Backlog and Little More

The contents of the Core Practices area drive agile development with regard to requirements. They are essential building blocks of Scrum, the most widespread agile development approach.

Product backlog and sprint backlog are used to define the work to be done. From a requirements perspective, user stories and epics are the most relevant kinds of backlog items. Sprint goals define the requirements context of a development iteration, and the Definition of Done can be used to establish quality requirements.

When you search for advice on these practices, take a first stop at the Scrum Guide and explore topics further using the Agile Alliance’s glossary of agile terms. Later you may deepen your understanding with Dean Leffingwell’s seminal book on agile software requirements.

Specifically for user stories, your information sources of choice can be Mike Cohn’s blog articles and his book.

You might wonder why the map does only list but not highlight the product owner role? The answer is simple: I assume that you are already familiar with this role. Quite likely you even are a product owner.

The highlighted practices all are artefacts that can help product owners doing their job well. Adopting such artefacts or work products (as opposed to new job roles or procedures) usually is the most direct and easiest way to establish new practices.

Artefacts that are not highlighted are less central to agile requirements management. And generally, for the reason above, roles-related practices like feature teams and the three amigos are not highlighted. Neither are procedures like sprint review and product backlog refinement. Of course, they can be very important at times.

Let’s continue our journey to improved agile requirements practices …

Templates and Checklists Help with User Stories and Backlog

Once you have user stories and backlog in place, you might want to use them more effectively and improve their quality. You receive help from the various templates- and checklists-related practices in the Supporting Practices section.

Most important is to establish a suitable user story template. The role – feature – reason template will likely be the central part of it. Definition of Ready is an instrument to set focus on quality of user story and backlog.

The best one-stop information sources on these practices are, again, the Agile Alliance’s glossary and Mike Cohn’s blog articles and his book.

Product Definition and Planning Provide Direction and Context

Development needs direction and context. Product vision, product definition, and road map provide this. They need business model and value proposition as their foundations. Release plan brings the road map into action. Together, these practices provide business context and important planning guides for the requirements-related work.

These practices have originated from the field of software product management. And there is a rich body of knowledge available there, which lately has also taken up many inspirations and contributions from the agile movement. Becoming familiar with the software product management perspective can be very valuable for agile product owners.

The primary recommended information source on software product management is the website of the ISPMA, the International Software Product Management Association. Their free resources on the software product management framework and the various syllabi of their education scheme give both a good overview and a solid foundation.

For agile concepts on software product management, the Scaled Agile Framework® (SAFe®) website and books provide the most systematic and richest information at date.

Basic Requirements Practices Give Momentum and Mastery

Agile requirements work starts from its specific angle with user stories and backlogs. But it can soon arrive at areas where traditional requirements management offers effective solutions. Examples are: How to deal with quality requirements (aka non-functional requirements)? Or how to capture system scope and context?

A good entry point into the field of requirements engineering and management is the International Requirements Engineering Board (IREB). Their website offers many free resources and links to further information.

Explore and Deepen over Time

Entries from the Additional Practices and Scaling Practices areas of the above map offer additional concepts that can enrich and improve agile requirements.

The Scaling Practices are important, because Scrum only addresses the situation of project-oriented development by one single team. In larger or more complex settings, and especially in continuous product development, you need supplementary approaches and practices.

In addition, there are several agile practices that are not specific to requirements but that interrelate with it and affect it. For instance, tasks are derived from user stories and conduct their implementation. But usually they don’t provide specific additions to a requirement.

Many other disciplines from the area of software engineering provide concepts and practices that can be valuable to agile requirements. Particularly noteworthy are architecture and design as well as testing. Also user experience design (UX design) offers very interesting and useful approaches.

For scaling agile requirements, useful approaches are LeSS (Large-Scale Scrum) and once again SAFe®. An overview of agile practices in general provides the Agile Alliance. Also Wikipedia can be a good source. For general software engineering methods it is most useful to scan the web and (online) bookstores by browsing and web search.

Information Resources

The following list summarizes the links to further information. It also contains brief additional comments and recommendations.

Scrum Guide: The scrum guide explains most core agile requirements practices and other agile practices.

Mike Cohn’s blog articles at Mountain Goat Software: Very concise and helpful information on user stories and epics.

Mike Cohn’s book “User Stories Applied” (2004): Very instructive. However, note that the role – feature – reason template wasn’t broadly known at the time and is not addressed in the book.

Dean Leffingwell’s book “Agile Software Requirements” (2011): A very systematic and comprehensive treatment of the topic. This work has resulted in the SAFe® framework (see below), for which many resources are available. However, I like this book because of its coherent description and the many practical tips and examples.

Agile Alliance Glossary: Comprehensive collection of relevant agile terms and crisp explanatory articles. Provides a good initial understanding of important agile concepts.

SAFe® website (Scaled Agile Framework®): Very rich source of information. The homepage shows overview diagrams of SAFe®. Each item in these diagrams has a link to a detailed webpage that describes it.

LeSS website (Large-Scale Scrum): A marked lean and light-weight approach for scaling Scrum, with many smart and useful agile requirements practices. Most practices can be adopted independent of the others, which facilitates experimentation and stepwise evolution of work practices.

ISPMA website (International Software Product Management Association): ISPMA introduces itself as “an open non-profit association of experts, companies, and research institutes with the goal to foster software product management excellence across industries”. Provides a comprehensive, systematic, and experience-based body of knowledge with many free information resources.

IREB website (International Requirements Engineering Board): A non-profit organization that fosters qualification and experience exchange on requirements engineering. A good starting point for further exploration on software and system requirements. Most of the accumulated body of knowledge can be accessed free of charge.

Wikipedia: Last but not least, many agile methods and associated requirements practices are described well in Wikipedia articles. Another good starting point for quick overviews and links to further information.


What Will Come after Atlassian Server?

On October 16, 2020, Atlassian has announced the end of sales and end of support of its server product editions. In a blog post Co-Founder and Co-CEO Scott Farquhar emphasizes that cloud products will be the company’s future focus. For customers who need or want high control over their installations, the Data Center editions will be continued and strengthened further.

This is an important turning point, because today’s market dominance of products like Jira Software has been built on the server editions as entry points into customer organizations. Also, much of the existing installed base of the products is still in this product segment.

Pointing out that “more than 90 percent of [customers] start with Atlassian cloud products”, Farquhar makes clear that the situation is different today. Cloud can be viewed the new server. “Today, the majority of [customers] are already benefitting from the advantages of cloud”.

What Will Change?

Affected are the server editions of the following products: Jira Software, Confluence, Jira Core, Jira Service Desk, Bitbucket, Bamboo, Crowd, and a few others.

End of new server license sales will be effective by February 2, 2021 Pacific Time (PT). At the same time, new prices for existing customers’ server renewals and upgrades will become valid.

Three years later, on February 2, 2024 PT, there will be end of support for all server products.

Detailed comprehensive information on the updates are described on Atlassian’s Upcoming Price Changes web page. Migration aspects explains the Journey to Cloud page.

Who Can (Widely) Ignore the Changes?

The changes will have little to no impact on you in the following situations:

If you are pure user and not concerned with setup, provisioning, or procurement of your Atlassian products, there will at least be no immediate changes, if any.

If you are concerned with product setup, provisioning, or procurement of Atlassian cloud or data center products, there will be little (i.e., new data center pricing) to no changes.

If you are concerned with product setup, provisioning, or procurement of Atlassian server products, and your intended product use will end prior to February 2, 2024 PT, then you can mostly continue as planned. This can apply, for instance, to time-limited subcontracted development projects. But be prepared that your prices might change.

However, in any case, you should be aware that the changes may impact some of your apps or plugin products, depending on how these products’ vendors react to Atlassian’s changes. So you might want to analyze this aspect of your current product installations and configurations.

Who Will Be Affected?

The changes will impact your use of Atlassian products in the following situations. In most cases you will still have more than three years  for your transition while staying in support and maintenance.

If you are considering a new purchase of Atlassian server products, then you need to get a quote before February 2, 2021 PT, in order to be entitled to purchase.

If you are concerned with product setup, provisioning, or procurement of Atlassian cloud products, and you have planned to use the products beyond January 2024, then you may receive price changes. And most important, you will need to move to an alternative setup in order to receive continued support and maintenance.

How Can You React?

It is always good to review and update one’s plans from time to time. This applies also to your development tool infrastructure.

If you are an existing Atlassian server customer and you can continue well on cloud or data center editions of your products, then this solution will definitely have advantages. However, there might be parts of your tool infrastructure that can benefit from additional changes. And every change is a new opportunity.

Quite some customers will not or not easily be able to make the transition from server to cloud or data center. Possible reasons are the higher pricing of data center (also depending on your number of users), technical characteristics or limitations of cloud or data center, and legal or regulatory constraints that prohibit you from using the cloud. In these cases, at least a partial move to other solutions might become necessary.

In future articles, we will take a closer look into these options and investigate possible tactics and strategies. Stay tuned.

Product Requirements Specification: Integrating Product and System Perspective

The previous two articles of this series on product requirements specification have addressed the two key specification parts: product perspective and system perspective. This part looks at how the two perspectives interrelate and integrate with each other.

Product and system perspectives complement each other

Product and system perspectives are two complementary parts of a product requirements specification. The represent different perspectives on the product, and they establish two separate but integrated workspaces for product management and development.

The following diagram shows this big picture: Product management is responsible for defining the product perspective, which is made up of product requirements. It provides a high-level definition of the product. In particular it describes how the product contributes to fulfilling (1) the needs of the product stakeholders and (2) the assumptions of the adjacent systems.

Development is responsible for defining the system perspective, which is made up of system requirements. It describes how the product requirements shall be implemented based on specific technologies and platform characteristics.

Link product and system requirements

Product requirements should be explicitly linked with the system requirements that implement them. This is indicated by the dots and arrows in the above diagram. The subsequent diagram illustrates this using an example from smartphone development.

Product management emphasizes that usage time will be critical for the success of the next product generation to be developed (i.e., product requirement: “The phone shall have a very high usage time.”).

It is up to development, represented by a system architect in this case, to propose how the goal of high usage time can be established. In the example, a combined solution of high battery capacity and fast charging technology is selected. Links from the product requirement to the two system requirements document the technical solution (i.e., combination of system requirements) to the market-driven product requirement.

The explicit linking of product and system requirements brings various benefits:

  • Support and ease collaboration between product management and development
  • Document design decisions and development activities for demonstrating regulatory provisions and quality standards
  • Facilitate maintenance by clarifying the context and dependencies of each requirement
  • Enable requirements reuse by identifying clusters of requirements that belong together

How to derive system requirements from product requirements

Product requirements are derived from system requirements in close collaboration between product management and development. Therefore, each party must be deeply familiar with their own domain and must have sufficient understanding of the other domain.

Product management must be able to validate whether a proposed technical solution is actually viable. And it must assess the implications that a technical solution has for customer, market and business. For instance, this includes price and license implications, or technological trends and preferences in the market.

Development must of course excel in technical implementation matters and be able to propose state-of-the-art or leading-edge solutions to the product requirements. At the same time, this requires a sufficient understanding of the entire customer, market and business context.

These required competence areas (is responsible vs. must know & understand) are illustrated in the following diagram. The interface between product perspective and system perspective marks the area of collaboration between product management and development. This is where product requirements must be broken down into and mapped to system requirements.

How can the interaction between product management and development be organized?—There are two basic models or styles of collaboration:

Negotiation of implementation proposals: In a contractor/subcontractor relationship product management (as contractor) defines the product to be developed. Development (as subcontractor) develops an implementation proposal, which is then negotiated with product management until a consensus is reached. Sometimes a formal development contract will be defined.

Continuous evolution of solution design: Product management and development jointly work on a central overall product requirements specification (i.e., on their product or system perspectives, respectively). Whenever new features or new technical solution candidates appear, they investigate, discuss, and decide on updates or extensions of the central product requirements specification.

The negotiation model can often be found when product development is project-based or customer-driven, or when external development partners are involved. It can work with document-based requirements management, not necessarily mandating the use of a specialized requirements tool (although this would have advantages). However, possibilities for requirements reuse and highly efficient requirements management are limited.

The continuous evolution model requires that a tool-based requirements management infrastructure is in place. It must include a requirements repository, workflow and stage gate definitions, as well as versioning and release management on the basis of individual requirements.

Typically, product management and development have their separate work areas within the requirements repository (i.e., product and system perspective). Coordination between both areas is accomplished by committees, boards, and work groups with members from each area of domain.

Continuous evolution of solution design can often be found in market-driven development of software or software-based products (including high-tech products). It favors a central coherent collection of requirements for the entire product or product line, and it provides a good foundation for efficient requirements reuse.

Divide, Specialize, and Integrate

Product requirements specifications that explicitly distinguish between product and system perspective form the basis for highly effective and efficient requirements management.

The two perspectives and their respective requirements collections establish specialized work areas for product management and development, fostering and supporting internal and external collaboration of the two parties. The explicit and central storage of requirements information and trace relationships ensure high transparency and availability of requirements for the entire development organization (e.g., including testing, production planning, and support). Moreover, this approach can lead to high requirements quality and enable requirements reuse.

The inherent complexity of requirements management can be mastered by the combination and interplay of three principles:

  1. Divide the overall collection of requirements into manageable segments
  2. Specialize each requirements segment to a dedicated area of competence and responsibility (i.e., work areas and workspaces)
  3. Integrate the requirements segments and their work areas by managing the interfaces and interactions between their explicitly documented requirements collections

The division of requirements into product and system perspective is guided and facilitated by assigning specific characteristics to each perspective. This has been described in the two previous articles of this series on product perspective and on system perspective, respectively. The following table summarizes and compares the characteristics of both perspectives.

Product Perspective System Perspective
Describes external view on the product Describes internal view on the product
Answers What

    • Is the product?
    • Does the product do?
Answers How

    • Does the product work?
    • Does the product accomplish its functionality?
    • Does the product provide or achieve its (non-functional or quality) characteristics?
Addresses business and usage aspects of the product Addresses technological, implementation, and operational aspects of the product
Uses Problem Domain language and concepts Uses Solution Domain language and concepts
Is a “Black Box” view Is a “White Box” view

If you want to explore these aspects further, you might look up the earlier parts of this article series:


Product Requirements Specification: System Perspective

The system perspective of a product requirements specification defines the solution design of a new product or product release. As a starting point it takes a previously described product perspective and defines all important detailed aspects of solution design and solution technology.

This is the third article in a series on product requirements specification. The previous one has addressed product perspective. The subsequent and last article discusses aspects of integrating product and system perspectives.

System Perspective: Work Product of Development

The system perspective of a product requirements specification is an important instrument of development, especially of those development roles that are responsible for solution design: Architecture, UX design, product owner (depending on role separation with product management), system engineers, lead developers, and to some extent other roles like testing and test management, quality management, and IT security management.

Typically, one or two persons take the lead for defining and coordinating the system perspective. They are responsible for the resulting specification. In agile development, product owners might have core responsibility, with support from UX designers. In development of software-based technical systems, system architects or system engineers often play the key role.

Architects at least take a role as key consultants and contributors. Rather unfrequently they have the organizational lead for defining the system perspective, because of their various other cross-sectional responsibilities. Similarly, testing, test management, and quality management contribute and must be informed.

Purposes: Bridge between Product Perspective and Implementation

For development the system perspective serves four important purposes: (a) It documents development’s response to the product requirements defined by product management (i.e., forming the foundation of a development contract with product management). (b) It supports and facilitates a consistent solution design across the various disciplines involved. (c) It supports and facilitates systematic evaluation of alternative design options. (d) And it communicates to other development roles (esp. to component developers and testers) how the product or new feature shall be implemented.

System Perspective as Workspace of Development

So overall, the system perspective builds a bridge between product perspective and implementation (see figure above). It is defined using system requirements, which are derived from product requirements and can represent major design decisions. The derivation relations should be documented explicitly using trace links (e.g., by cross-references in text documents or relationships in requirements tools).

When using such trace links, the information about relevant product requirements  remains accessible from every system requirement (i.e., following the link up-stream). For instance, it can be identified which primary stakeholder needs, which are usually expressed by product requirement, have led to a specific solution design in the system requirements.

Characteristics of System Perspective

The main characteristics of the system perspective are:

  • Describes internal view of the product
  • Answers *How* …
    • Does the product work?
    • Does the product accomplish its functionality?
    • Does the product provide or achieve its (non-functional or quality) characteristics?
  • Addresses technological, implementation, and operational aspects of the product
  • Uses Solution Domain language and concepts
  • Is a “White Box” view

Internal View & “How?” Questions

Among the characteristics of the system perspective two are essential: (1) It describes an internal view of the product. (2) It focuses on “How?” questions.

Internal view of the product: The system perspective defines the product’s  solution design from the viewpoint of development. It forms a separate workspace where development has full responsibility to design an optimum solution for the given product requirements.

“How?” questions: The system perspective defines how the product shall work and be built. This clear focus on “how?” aspects helps deciding whether a requirement belongs to system perspective (as opposed to product perspective, addressing “what?” questions). It also guides formulation of precise, high-quality system requirements statements.

The following figure illustrates these two aspects of the system perspective: Development (i.e., one or few nominated persons from development) is accountable for solution viability and must be responsible authors of the system perspective or its respective parts (e.g., UX Design responsible for user interface design and all other UX aspects).

Key Aspects of System Perspective

System requirements are the main contents of the system perspective. As an internal view of the product, they define how product requirements shall be implemented. They refer to a certain technological basis and to platforms to be used by development and operations. This technological basis and platforms provide the foundation that underpins the solution design. They must be defined explicitly within the system perspective so that the system requirements can be understood clearly and be formulated in a concise manner.

Examples of system requirements are:

  • Functional requirements of a finance application: When and how various relevant taxation policies shall be considered during calculations
  • Performance requirements of technical products: Which measures for energy management shall be applied in order to ensure long battery life
  • Security and privacy requirements of mobile apps: How personal data shall be stored and transmitted

Technology, Implementation, Solution Domain & White Box

The other three characteristics of the system perspective are implied by the former two. However, emphasizing them helps to understand important facets of system perspective better. They also guide us to writing better system requirements.

Technology, implementation, and operations aspects: These are the typical contents of the system perspective. They all refer to “how?” questions of solution design instead of just “what?” questions (i.e., what shall the product be and look like–focus of the product perspective). Thus they establish the relevant internal view of the product.

Technology is an important aspect of solution design especially for technical products like combined hardware/software systems. Other aspects where technology can make a difference are, for instance, security and system performance.

When should we define implementation aspects as system requirements and not just leave them do the developers’ decisions?–They should be defined explicitly as system requirements whenever there are several alternative solution options, among which a specific one shall be preferred. For instance, one implementation approach (e.g., an algorithm) might offer important competitive advantages (e.g., higher performance).

Aspects of system operations must be considered, because they can have high impact on a product’s long-term cost structure (e.g., dependability or scalability). They also can open up competitive advantages (e.g., availability of operations data). So they should be addressed in system requirements.

Solution Domain: A solution domain is a subject matter area that contributes to solving a given problem. For instance, for the problem how to drive a vehicle, relevant solution domains can be combustion engines or electric engines.

Likewise, solution domains for developing web applications range from internet protocol via programming languages (like C# and Java) and frameworks (like .NET) to specific technology areas (like VPN, cryptography, and blockchains).

A solution domain provides the concepts and building blocks of the solution. It establishes the conceptual and terminological framework for formulating system requirements. In order to understand system requirements correctly, it is important to know the solution domain to which they refer to or belong.

White Box: The notion of a white box stands for a system whose internal mechanics can be viewed (i.e., transparent box that allows to see the inside). System perspective is such a white box. This is different from product perspective, which intentionally shall hide (or abstract from) the internal aspects (denoted black box) in order to reduce complexity and highlight external properties of a product.

This “white box” characteristic of system perspective plays an important role for development: It shall define and expose all relevant internal aspects of solution design, so that everyone involved into implementation can gain a good understanding of how the product shall work, and how it shall be implemented.

Contents of System Perspective

System perspective usually should have the following overall contents:

  • Solution overview
    • Solution architecture
    • Development technology & platforms
    • Operations technology & platforms
  • Architecture and design principles
  • System requirements (including use cases)

System requirements are by far the largest part. Their internal structure usually contains groups of requirements that match the parts of system architecture (e.g., UI, processing, and database) or important subject matter categories of the solution domains.

Solution overview defines the scope of the solution and describes its basic elements. For instance, it indicates relevant solution domains important for designing the solution and for understanding the system requirements. So an important purpose of the solution overview is to frame and introduce the solution to readers of the system perspective (e.g., new development team members, auditors).

Architecture and design principles define essential general, cross-sectional properties of the solution–e.g., software design patterns and UI style guide. These basic rules and policies shall facilitate construction of the solution and ensure solution quality. They also can ease definition of the system perspective, because general principles and policies are defined in a central location and do not need to be repeated in several individual requirements across the specification.


The next and last part of this article series discusses how system perspective is derived from product perspective, and how the two perspectives interrelate.


Requirements Management Tools: March 2020 Update

The list of requirements management tools on MakingOfSoftware.com has received a new update: The March 2020 version includes 69 tools, with a selected subset of 13 tools that we find particularly noteworthy.

The list gives an up-to-date overview of the requirements management (RM) tools market. It shall guide teams and organizations when compiling a longlist for tool evaluation and selection.

RM Tools Market: Ongoing Transformation & Consolidation

During our research for this update, we could once again observe that the RM tools market is undergoing a transformation and consolidation process. After the recent acquisition and merger wave, important tool vendors have now restructured their portfolios.

Most notably: Micro Focus has positioned Dimensions RM as its core RM tool, with ALM Octane as a very interesting additional candidate for agile requirements management. Its previous other RM-related products Caliber (former RM flagship) and Atlas (more recent agile tool) have reached end of marketing.

Micro Focus ALM/Quality Center is positioned fully towards test management. When looking for a new RM tool solution, it is not a relevant choice any more. However, if you happen to have it inhouse, it can still effectively support your RM processes. In particular, the tool will pair well with the agile ALM Octane.

Other important portfolio consolidations happened at Broadcom, PTC, and IBM: after Broadcom has acquired CA, it has renamed the tool CA Agile Central into Rally Software. So, it has reinstalled the Rally brand, which CA had acquired and removed some years ago.

PTC Integrity Lifecycle Manager platform has been renamed into PTC Windchill RV&S. And IBM has restructured and rebranded its former IBM Rational portfolio. As a consequence, the two DOORS requirements products are now called IBM Engineering Requirements Management DOORS Family and IBM Engineering Requirements Management DOORS Next.

13 RM Tools in Selected List

Due to the large number of tools, we have again compiled a list of 13 selected tools that we regard particularly noteworthy. Features and technology of these tools are markedly up to date, or the tools obviously have strong market presence. When you want to collect a longlist for your tool evaluation, you might start your research by scanning through this list of selected tools.

Compared to our previous release of the tools list, we have removed Micro Focus ALM/Quality Center from the selected list. As described above, the tool is not a hot candidate any more for new purchases. Existing Micro Focus customers might have a look at Dimensions RM instead, and at ALM Octane for agile development in particular.

A new tool on the list is ReqSuite RM from Osseno Software. Over the past years, ReqSuite RM has gone through a remarkable development and maturation process. It started with novel and very interesting support for business analysis. Today it includes an attractive feature set with most characteristics we find important for an up-to-date RM tool.

Tool Availability & Up-to-Date Information

During the update of the RM tools list, we have conducted the following steps:

  • All tools have been checked for availability and up-to-date web links to tool and vendor pages
  • Several tool entries have been changed (e.g., name changes, new product bundles), several obviously outdated ones have been deleted
  • All tools have been supplied with up-to-date version information (where available, as of late February 2020) and assigned to the relevant tool categories (e.g., RD, RM, Agile)

We have again removed several tools for the following reasons: (a) the tool has been discontinued or is not actively marketed any more, or (b) the tool’s product or vendor websites have not received any substantial updates for more than two years.

  • Atlas
  • Caliber
  • CORE
  • DevSuite
  • Raven
  • RDD-100
  • Rhythm
  • TopTeam Visual Use Case
  • TraceCloud
  • TREND/Analyst
  • Visual Trace Spec

If you want to get an overview of the RM tools market, or want to select a suitable requirements tool for your team and organization, feel free to explore the latest list of requirements management tools: