Manage operational requirements for production

Part 1. Four steps to ensure that dev and ops teams agree on nonfunctional requirements


Content series:

This content is part # of # in the series: Manage operational requirements for production

Stay tuned for additional content in this series.

This content is part of the series:Manage operational requirements for production

Stay tuned for additional content in this series.

The idea of identifying and tracking requirements is well established among IT professionals. Unfortunately, requirements are often automatically identified with user requirements, such as the function related to a use case or the response time requested for a specific operation.

However, there is another class of requirements that is more elusive and often the source of serious problems for production systems. It includes things such as number of connections to the database, memory allocation, and coexistence with other, often unrelated systems.

These requirements originate from the fact that, in today's data centers, no software is an "island" with infinite resources. Instead, the entire hardware and software infrastructure must be continuously optimized to improve price and performance yields. Therefore, new software that goes to "in production" has to comply with a set of requirements related to shared resources, along with the constraints that originate on new systems.

In this two-part article, we show how the Development and the Operations departments can use IBM® Rational® Requirements Composer collaboratively in two ways:

  1. To model and track the requirements related to the use of the application in production
  2. To prepare and track the preproduction tests by later adding IBM® Rational® Quality Manager

Why nonfunctional, operational requirements can be a problem

As discussed in previous articles (see the Loasacco and Castiglioni citation in Related topics), nonfunctional requirements (NFRs, hereafter) represent the needs of various types of stakeholders who have an interest in the IT system under construction (see the Rozanski and Woods citation in Related topics).

In this article, we concentrate on those NFRs that are directly related to the production environment of the new system and to the set of processes that support its operations. We refer to these requirements as operational requirements.

Of course, as for any requirement, the first source of specifications for the production environment of a new system is the business intent. Specifically. SLAs (Service Level Agreements) are mainly originated by the characteristics (number of intended users, response time during critical transactions, and acceptable downtimes, for example) of the business processes and the business environment that the system must support.

However, the second important source of operational requirements is the IT Service Management (or Operations) organization, which includes people in these roles:

  • The configuration management specialists, who maintain the system configuration, apply corrections, enhancements and upgrades and introduce new elements if needed.
  • The database administrators, who define the physical database, monitor its health and backup stale data.
  • The service manager, who decides the placement of the new system on physical servers.
  • The network and system management specialists, who monitor and control the new application and its infrastructure at run time (hardware and software)

In addition, other stakeholders such as these might be represented:

  • The enterprise architects, who guarantee that the new system complies with established design and architectural prescriptions
  • The security officer, who establishes the standards and security rules the applications and the infrastructure must comply with, and perform the appropriate audits
  • The assessors, who verify compliance with internal or external standards and/or legal regulations
  • The maintenance staff members, who perform the system maintenance and the problem determination in case of failure.
  • The suppliers, who provide the hardware and software products to build the infrastructure that will host the new system
  • The support staff members, who provide support to the end users

In summary, as a general rule, the operational requirements derive from these sources:

  • Policies of the IT organization that manages the data center
  • The architecture of the data center infrastructure
  • Products and tools already in use or planned for use in the data center
  • Resource constraints in the Operations data center.
  • Constraints due to the placement of some components of the application on specific servers

However, operational requirements cannot be taken out of the more general context of other nonfunctional requirements, because the two sets are closely interrelated. An example of an NFR expressed by an actor (in this case, the business owner) that translates to an operational requirement, you can take the request for a specific (high) throughput on a given interface. This might push the IT Operations to choose a specific level of operating system (maybe a newly announced version that promises substantial performance improvements) or middleware software, thus originating a new operational requirement.

Even this very simple example shows how operational requirements are often highly correlated and require an effective communication between the Development team and the various roles of the Operations team.

In our experience, most of the problems that occur when a new application is released to production are rooted in misunderstandings or lack of communication between these two organizations. An analysis of these problems shows that these are the most common causes:

  • Lack of completeness in the communication. Information is often text-only, based on forms and synthetic checklists that may be only partially appropriate to the new system and subject to interpretation.
  • Lack of sharing. The information flows only one way as formal documents (usually from Development to Operations), even though good comprehension and clarification of the content would require an extended discussion with multiple viewpoints, instead.
  • Overlooking important information. The person who receives the information doesn't grasp the relevance of the requirement and fails to communicate it. This often means that the requirement will not be included in either the Development or the Operations Test Plan.

In this article, we propose four-step communication process between Development and Operations:

  1. Step 1 is about identification of the Context NFRs, meaning those nonfunctional requirements that are directly affecting the actors of the new system in development, including other pre-existing systems that need to be interfaced. The System Context diagram (or better, the Operational Context diagram) and the documents that describe internal and external standards are the artifacts at the base of this step.
  2. Step 2, the logical deployment NFRs, registers mainly NFRs that originate from technology and architecture, including Development decisions during application design. This step is built around the Logical Deployment Model of the new application.
  3. Step 3, the physical deployment NFRs, identifies operational requirements linked to the production environment physical model and physical constraints, which originate from the infrastructure and the middleware supporting the new system.
  4. Step 4 finalizes the list of nonfunctional requirements with the related discussion threads by sharing explicit reviews and approvals from all involved stakeholders.

How using Rational Requirements Composer is different

Tools for managing requirements across the software lifecycle have been available for a long time. They are widely adopted today to create, trace, and manage requirements and to link them to the various artifacts in the software development process.

Tools focused on supporting the activity of gathering and defining requirements are much newer.

Over time, we have seen that modeling techniques (use case modeling, business process modeling, and so on) have been gradually adopted to complement the traditional, text-based approach, because they provide richer and more sophisticated ways to express business and technical needs.Nevertheless, such techniques and tools are mainly oriented to software architects or development teams. End users, business experts, analysts, and other stakeholders typically ask for a less formal approach, with tools that are easier to use, such as storyboarding or simulation software that also gives them the ability to speak their own language to exchange comments, ask questions, and get answers.

In this scenario, solutions that address specific needs for the individual look inadequate, with the extended team being the target audience. A repository-based approach, with information sharing and strong integration capabilities to other Application Lifecycle Management (ALM) or modeling tools is by far the preferred choice.

Rational Requirements Composer is a server-based solution built to help teams of people to collaborate around defining, refining and reviewing requirements; it builds on the Jazz platform, and its rich collaboration environment, complemented by smart editors and other visual and textual techniques.

The collaborative approach

Rational Requirements Composer supports teams of users that are working on requirements definitions. Team members can be geographically dispersed, work remotely, and work at different times. Whenever they connect to the repository, they have an at-a-glance view of the project (or projects) that they're working on and immediate access to the artifacts, comments, reviews, and so forth that have been created or updated since they last checked.

According to their responsibilities, they can read and respond to comments, create and update supporting artifacts, create and update requirements.

To facilitate the discussion about requirements, vocabularies of the business and technical terms, called Glossaries, provide the common terminology to be used consistently throughout the entire project. This is especially useful when the community of stakeholders is large, varied, or geographically dispersed.

Comments are a very simple but powerful mechanism that help stakeholders express and record different viewpoints and discuss implications, priorities, expected benefits, timeframes, and so on to eventually converge and reach a the final definition. Comments, which can be associated with entire artifacts or single elements within an artifact, are organized in threadsor discussions and can be visible either to specific users or to the entire community. This iterative discussion process simulates an extended, ongoing meeting and allows for more precise and stable requirements definition.

Artifacts and modeling

Rational Requirements Composer includes several editors and tools to produce requirements and supporting artifacts.

Text documents are still widely used in the requirements definition process. Existing documents (Microsoft Word documents, for example) can be easily uploaded to Rational Requirements Composer, or a new text document can be created.With the Smart Text capabilities, any piece of text, like a sentence or even a single word, can be selected and marked as a requirement or used to create a new entry in the Glossary.In the same way, a piece of text can have associated comments or tags, or it can be linked to other artifacts and elements.

This network of relationships constitutes, in itself, a true wealth of business and technical knowledge.

In addition to text processing, Rational Requirements Composer provides several editors to produce specific artifacts:

  • Use Case editor to create use-case specifications and use-case diagrams;
  • Business Process editor to depict diagrams, based on the BPMN notation, representing the flow of activities and events. This is a flexible technique for requirement definitions; BPMN diagrams can then be exported to other Business Process Modeling Notation (BPMN) modeling tools for further refinements.
  • Sketch editors for building models of the user interface. It's pretty easy to compose screen views and screen flows that illustrate how the system looks to the end user.
  • Storyboarding feature, to create storyboards, which are composed of frames on a timeline that reflect a particular scenario, such as a specific user experience. Typically, storyboarding is used to simulate how the end users navigate through the GUI. However, this is a flexible mechanism that can be adapted to several purposes. In our case, we used storyboarding to support the human collaborative process of defining and refining the technical operations scenario and its requirements.

Requirements definition in Rational Requirements Composer

Rational Requirements Composer uses a specific type of artifact for expressing requirements. Several types of artifact (use cases, storyboards, and so forth) can be used to support the requirement definition, but a requirement is definitively expressed as an instance of the requirement type.

Requirements can be defined at any time during the analysis, either explicitly, by creating an artifact of the requirement type, or by attaching a requirement to selected text in a document or to any element in a supporting artifact. Team members can then review and comment on the requirement and the associated artifacts, but there is also a formal process of review and validation.

In Rational Requirements Composer, a review consists of a set of requirements and supporting artifacts to be validated as a whole, by a group of users, each one performing a specific role, such as Approver or Reviewer, and a set of actions to be executed, for example: Approve or Reject.The set of artifacts can be selected just for the purpose of the review or can be a collection of related artifacts that has a wider scope. All involved users are notified of a review creation and requested to review the assets, express their comments, or propose changes as needed. Eventually, all of the Approvers have to validate the assets.

To illustrate how the software enables the collaboration between the Development team and the IT Operations one for the identification of operational requirements, we will use an example: the introduction of a new system (an "Auction-based e-marketplace") in an existing data center.

Step 1. The Context NFRs in the new storyboard

The first set of operational requirements that goes into our "New System Operations Story" comprises the nonfunctional requirements that originate from the scope of the new system. These can be usefully connected to the application's System Context diagram, thus identifying the Operational Context of the new system (see the Castiglioni-Losacco citation in Related topics).

Requirements are placed on the System Context diagram
Requirements are placed on the System Context diagram

Typically, the first version of the Operational Context diagram contains actor-originated NFRs, such as response time for interactive users, number of concurrent sessions, or availability windows for the application.

In our example, the Registered Users interface must be available during business hours to allow participation to auctions, support up to 200 concurrent users, guarantee response times below two seconds, and be secured through the user ID and password.

To help the visual association of requirements to the elements of the diagram, we use the technique of positioning text labels on the diagram (highlighted in green in Figure 2) and to attach requirements and comments to those labels.

To this base IT requirement, the Operations staff can add their own "context" NFRs:

  • Constraints imposed by external systems already in place that must be integrated
  • Policy-related requirements, such as security requirements on the users' and external system's access, ID management policies, audit and logging
  • Data center architectural decisions

In our example, the company's architecture standard calls for IBM® WebSphere® Application Server as the application platform and IBM® DB2® as the database server.

Requirements can be part of a text document
Requirements can be part of a text document

Step 2. The logical deployment nonfunctional requirements

The next iteration between Development and Operations occurs when the deployment structure of the new system has been defined. At this stage, the Development team has a clear picture of the main components of the system and what features are required to support them. Therefore, in this phase, we expect that all appropriate technologies have been identified and that the main architectural decisions have been made. A UML Deployment diagram or equivalent can be usefully used to convey these decisions.

These are the common requirements mismatches at this stage:

  • The technology level supported by the middleware already deployed in production is not the right one.
  • Development's assumptions about the production system's topology are not met by the real system.
  • Development requests ad hoc middleware, which is equivalent to something already installed in production, thus redundant.

At this stage, you will see the strength of the collaborative approach of Rational Requirements Composer. If the information exchange is done at the right time, both the Development and Operations teams are probably in time to adapt their designs to match each other's requirements.

Discuss requirements based on the deployment model
Discuss requirements based on the deployment model

In our example, the Development team has (apparently) duly followed the middleware standards of the company, because the new system is a quite regular Java 2 Enterprise Edition (J2EE) application, with a web component, a back-end component, and a web services requester component. However, they relied on the availability of a certain technology: JAX-WS (Java API for XML Web Services). If support for JAX-WS is not available, the application's web services component will have to be completely rewritten.Therefore, in case this technology level is not yet available in the production environment, an upgrade must be planned.

Other operational constraints can be negotiated in the opposite way. For example, Development can agree to use the IBM® DB2® database on the IBM® z/OS® operating system, rather than DB2 on a distributed platform if this is the Operations preferred platform for this class of data.

These "conversations" are an important piece of information. In certain cases, they can be as important as the final requirement, because they capture the rationale for the decisions made.

Step 3. The physical deployment nonfunctional requirements

The collaborative negotiation process of requirements and constraints shown so far eventually reaches the point where the system's physical model can be specified; therefore, the whole set of operational requirements can be identified.

Although, in the previous iterations, Development was the initiator of the information exchange, now it is the Operations department that starts the process. Requirements identified in this phase are mainly related to these two factors:

  • Architecture of the data center (physical systems and network connections)
  • Constraints imposed by the specific production systems involved in the architecture (typically resource constraints, such as memory or maximum number of connections to the database machine)
Requirements placed on the system physical model
Requirements placed on the system physical model

For the sake of clarity, in this example, we have chosen to represent the physical model with a high-level illustrated diagram first, and then with a more detailed textual one. Typically, both types of information can be included in a single large, detailed diagram.

Requirements placed on the detailed physical model
Requirements placed on the detailed physical model

Lastly, the requirements stipulate that the new system must be developed on an IBM® WebSphere® Application Server and DB2, which are the middleware standards of the company.

As we did in previous iterations, we add text labels to identify elements that are subject to requirements and then attach requirements to text annotations. These labels specify resources available to the new application are on the back-end servers and the size of the connection pool that can be allocated on the database server.

Step 4. The final reviews

After the final round of clarifications and negotiations is finished, we can say we have a firm set of shared requirements to be validated.

Once again, Rational Requirements Composer shows its strength in supporting such a workflow: multiple reviewers can be defined before the final signoff is given (see Figure 6), and the review process itself can be supported by comments and discussion threads. Typically, Operations staff and developers will be reviewers, but end users and other organizations, such as Architecture, can be involved also. The final signoff can come from the application's business owner or the CIO.

Each requirement has its own approval status
Each requirement has its own approval status

Next, it's time to take the requirements and transform them in real usage scenarios that can be tested in a preproduction test to show that the system is, in fact, behaving as expected in the production environment. That will be the subject of the second article of this series.


Identifying nonfunctional requirements related to the production environment of an application is a matter of collaboration between different actors in the Development and Operations groups, but also end users and, potentially, other stakeholders. This process must be supported by a tool that makes this cooperation possible in a simple but structured fashion, because all that happens in the process is important, not just the final result.

In this article, you have seen that Rational Requirements Composer can be such a tool. We suggest that the process be structured in four steps, or iterations, starting very early in the development cycle. This fosters smooth sharing of relevant information at all stages of the design, so you avoid late surprises and rework. We also suggest that you support this process by an extensive use of diagrams to avoid the misunderstandings that can derive from text-only descriptions.

Requirements identified with this process will be the base for the scenarios of the preproduction Test.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

ArticleTitle=Manage operational requirements for production: Part 1. Four steps to ensure that dev and ops teams agree on nonfunctional requirements