This article presents ReqSuite^® RM by OSSENO Software GmbH. ReqSuite RM is definitely one of the more interesting modern requirements tools on the market. It includes several features that can be regarded innovative, addressing critical needs of the requirements workflow.

Like only few other tools, ReqSuite RM has been designed originally and specifically to support core requirements management activities like defining, structuring, and approving requirements and specifications. Other requirements tools often have originally been issue trackers that were extended by requirements functionality.

ReqSuite RM’s original requirements management focus manifests in several attractive features rarely found in other tools, at least not in this combination. The most important such features are:

• Language templates that blend explicit requirements attributes with easy-to-read textual display of requirements
• Input forms based on typesetting and table templates
• A rich set of options to guide and guard-rail requirements structuring:
  • Requirements types, grouping into folders, relationship types
  • Cardinality information associated with relationship types
• Automation functions like calculated fields and generation of new items
• Support for different types of requirements reuse
• Quality checks based on a rich and further growing library of quality criteria
• Process guidance and assistance based on quality checks, custom-defined workflows, and interactive user guides

Let’s look into these features below. First, what are the most important technical characteristics of the tool?

Availability and Technical Characteristics

ReqSuite RM comes as a modern, up-to-date web app offered both as cloud app (i.e., vendor-hosted) and for on-premise installation (i.e., customer-hosted). It offers a REST API and ReqIF export. And it also provides important integration options with other tools like Atlassian Jira, Microsoft DevOps Server, GitLab, and Sparx Systems Enterprise Architect.

Now to the selected interesting features of ReqSuite RM, starting with language templates.

Language Templates

ReqSuite RM provides several configuration options for controlling the textual display of requirements information while maintaining strong underlying information structures. The most prominent such feature is Language Templates.

A language template defines a blueprint of individual requirements statements based on the requirement’s attributes. For instance, you can define that every requirements statement shall have the form „The system (must|shall|can) <specific functionality> ….“. Then you would define an attribute called Relevance, defined as an enumeration of the three values must, shall, and can. And you would have another attribute called Functional Description of type Text.

Then ReqSuite RM lets you freely define a text template, for instance: „The system <Relevance> <Functional Description>.“ Then requirements authors can set each requirement’s Relevance and define its functional description. Whenever users display the requirement, the text contains the correct statements. This combines a high level of information structuring and control with intuitive readability of requirements contents.

ReqSuite RM provides several additional features that support textual display of requirements information. For instance, you can define the plural forms for the names of requirements categories, and their gender-specific articles needed in languages like French or German.

Requirements Structuring

Requirements tools store each requirements statement as an individual data record, consisting of several attribute/value pairs. Examples of attributes are Name, ID, Description, Status, Priority, and Estimated Effort. Each project or organization can define its specific requirements types, like Customer Requirement, Product Requirement, and Module Requirement, which all have their specific sets of attribute types.

The tools allow structuring this information in folder-like collections, and establishing link relationships between them. For instance, Customer Requirements can be related to Product Requirements, and these further to other information types like Test Case.

ReqSuite RM offers these features, as it can be expected from any modern requirements tool. Requirements types are called Categories in ReqSuite RM. Each has its specific set of attributes, input form, workflow (i.e., states and state transitions), and relationship types.

Particularly interesting structural features of ReqSuite RM are: Calculated fields, value conditions, dynamic enumerations, and relationships with cardinality constraints.

Calculated fields

Calculated fields allow for numeric calculations of attribute values based on other attributes. While several requirements tools offer such features, the solution in ReqSuite RM is particularly well thought-through and usable, concerning the collection of numeric functions and the way formulas can be expressed. It can be used, for instance, for calculating risk ratings from basic probability and severity evaluations.

Value conditions

Value conditions control which elements of an enumerations a user can select in a specific situation. This way, requirements data can be kept at a high level of consistency and integrity.

Dynamic enumerations

Dynamic enumerations are attribute values that are determined at usage time. Usually, enumeration values are configured by central administration when a requirements tool is installed, or when a new project starts. With dynamic enumerations, the elements of a selection list are determined at runtime. For instance, all current code modules or all currently defined use cases can be offered as selection lists.

Relationships with cardinality constraints

Another notable structural feature of ReqSuite RM are relationships with cardinality constraints, denoted relationship quantities in the tool. Relationships are not only directed. They also can have indications of how many instances may be connected with each other. For instance, a cardinality of „1->1..*“ between Requirement and Acceptance Criterion defines that every requirement must have at least one or multiple acceptance criteria, while each acceptance criterion belongs to exactly one requirement.

Cardinality constraints on relationship types help providing a high level of structural information among requirements. This is an important prerequisite for establishing strong control of requirements quality, and for guiding users during requirements definition.

Quality Checks

ReqSuite RM comes with a rich and continuously growing collection of automated quality checks. The many features for defining structural properties among requirements provide the baseline of these quality checks. For instance, completeness of trace relationships can be checked, and the tool even identifies indicators of over-specification.

Other quality checks analyze requirements language. These include, among others, ambiguous meaning (e.g., through nominalization or generalization), duplicate statements, contradictions, and the use of yet undefined terms and abbreviations.

Process Guides

Another use of the strong structural properties of ReqSuite RM are its process guides: Users can receive detailed guidance during the requirements process, such as what steps for requirements elicitation, definition, review, and refinement shall be performed. For this purpose, ReqSuite RM presents tasks to its users that describe the next activity to be performed.

Once more, ReqSuite RM ‘s capability to configure rich structures like requirements types and links forms the basis of such advanced features like context-sensitive process guides. For instance, when a user writes a use case specification, then ReqSuite RM can point to lacking information like actors or preconditions. Later, the tool can remind its user that each use case shall have at least one associated detailed requirement.

ReqSuite RM can present pre-defined advice to users, offer guidelines for requirements authoring, and checklists for evaluating and documenting requirements quality. It also manages monitoring of task lists and documents their completion.

ReqSuite^® RM Tool Profile

When this article was published, the tool possessed the following characteristics.

Product	ReqSuite® RM
Release	3.7 (Feb 2022)
Vendor	Osseno Software GmbH
SaaS/Cloud	Yes
On-Premises	Yes
Available since	2014

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.

 

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.

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: When Do You Need It?
• Product Requirements Specification: Product Perspective
• Product Requirements Specification: System Perspective
• Product Requirements Specification: Integrating Product and System Perspective (this article)

 

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.

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).

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.

• Product Requirements Specification: When Do You Need It?
• Product Requirements Specification: Product Perspective
• Product Requirements Specification: System Perspective (this article)
• Product Requirements Specification: Integrating Product and System Perspective