Analyze requirements for complex software systems in a new, holistic way

A method to resolve conflicting functional and non-functional requirements

This article describes a method for systematically analyzing requirements of an IT system so you can create a component model that addresses the requirements in a holistic way. Explore sample requirements with uses cases and "stress cases" to identify potential conflicts between functional and non-functional requirements. Stress cases must be addressed by defining an optimum solution that resolves the conflict. Learn how functional and non-functional requirements are opposing forces that are handled similarly to forces in civil engineering structures.

Fabio Castiglioni, Senior IT Architect, IBM

Fabio Castiglioni photoFabio Castiglioni is a senior IT architect with IBM Sales and Distribution in Italy. He has 13 years of experience in a development lab, where he covered technical and management positions on international projects. In 1995 he was appointed Technical Director for a research project on OO technologies. In 1998 he was an IGS Senior IT Architect working on major government projects. Fabio is one of the teachers of Component Modeling classes for IBM architects. He was a speaker at the SOA and Web Services conference in 2005, and TLE speaker in 2006 and 2008.


developerWorks Contributing author
        level

Peter J Cripps (pete_cripps@uk.ibm.com), Senior IT Architect, IBM

Peter CrippsPete Cripps is a Senior IT Architect in Global Business Services in the UK. His areas of technical expertise and interest include: the application of component and service based development techniques, the use and practical application of methods and the development of good architecture practice across the IBM architectural community. As well as being an experienced teacher of IBM’s method classes he has recently been involved in the development of the IBM Unified Method Framework.



17 February 2009

Introduction

Today's software systems are more complex than ever. The complexity comes from difficult functional requirements, and from demanding non-functional requirements, such as very high availability, fast performance, and challenging security requirements.

With lots of varying, complex requirements to accommodate, how does the IT architect ensure that the architecture satisfactorily encompasses all the requirements? It is usually left to the architect's own judgment, because existing processes and techniques provide very little guidance. The danger is that requirements are addressed in isolation, without considering how resolution of one requirement might impact other requirements.

To start thinking about requirements in a holistic way, envision them as opposing "forces." The IT solution can be a way of resolving those forces in an optimum way. Figure 1 shows an example.

Figure 1. Requirements as opposing forces
Requirements as opposing forces

The forces are:

  • The functional requirements.
  • The qualities and constraints (the non-functional requirements) that we impose on the IT system.

Grady Booch compares the resolution of IT requirements to the forces that civil engineers designing a bridge must address. The engineering task of a bridge designer is to design a structure that resolves a number of fundamental forces, such as:

  • Dead loads — the weight of the bridge itself.
  • Live loads — the weight of the people or vehicles passing over the bridge.
  • Dynamic loads — the rapidly changing forces caused by the sudden impact, shifting, and removal of those live loads.
  • Environmental loads — external factors, such as wind, water and earthquakes, which conspire to move the bridge in unintended ways.

Considering the forces (functional and non-functional requirements) that the IT architects contend with, how do they systematically resolve these forces in an elegant, functional solution that will also meet the required service level characteristics?

There will always be "tension" between requirements on all but the simplest of software systems. It's the IT architect's job to ensure that these tensions are first identified, and then resolved in an optimal way. When searching for conflicts between requirements, a technique first devised by Christopher Alexander comes to mind. The technique is for understanding the conflicts that urban designers face when planning towns and cities that must meet numerous heterogeneous requirements. This technique involves taking each requirement and considering its interaction with every other requirement using a Requirements Conflict Matrix (RCM).

An RCM is a tool that lets you identify sets of potentially conflicting requirements called stress cases. The RCM is a simple matrix with rows and columns that identify the requirements of the IT system.

Following Alexander, let's use the approach below when deciding if two requirements, A and B, are likely to conflict or concur with each other.

  • If A is a functional requirement (usually in the form of a use case) and B a non-functional requirement, consider how the use case execution will be affected by the non-functional requirement.

    For example, a use case to place an online order may not be able to complete successfully if the order management system is out of service because it's undergoing scheduled maintenance. Some non-functional requirements (such as "The system shall be developed in Java") are completely orthogonal to the use case or have non-obvious results.

  • If A and B are both non-functional requirements, consider whether the solution that meets one requirement is compatible with the solution for the other.

    For example, does meeting a strict "Availability" requirement facilitate keeping "Development cost and budget" objectives? This may not be the case, so you have to consider those two requirements as conflicting. On the other hand, the requirement to use a package could concur with a requirement to deliver the system in six months.

  • A and B are both functional requirements that are realized by components that have been structured according to the object-oriented principles of:
    • High cohesion
    • Loose coupling
    • The correct level of granularity
    • Being well layered
    It is highly probable that there is neither a positive nor negative interaction between them.

    This article assumes that the initial version of the component model has already gone through functional analysis, so disregard the functional-functional interactions.

The approach described in this article assumes there is a relatively complete set of non-functional requirements. The next section explores where requirements come from.


Where do requirements come from?

According to Alexander:

"A design problem can only ever be stated in terms of errors we have observed in past solutions to past problems. The best we can do is to include all the requirements we can imagine."

He goes on to ask:

  • How do we get an exhaustive list of requirements?
  • How do we know that all the requirements we include in the list are relevant to the system under development?

For IT system requirements, it is key to ensure that all stakeholders who have an interest or concern in the system have been identified, and that they've had a chance to express their concern. Rozanski and Woods categorize the various stakeholders who have an interest or concern in an IT system as follows.

Acquirers
Oversee the procurement of the system or product.
Assessors
Oversee the system's conformance to standards and legal regulation.
Communicators
Explain the system to other stakeholders in documentation and training materials.
Developers
Construct and deploy the system from specifications (or lead the teams to do this).
Maintainers
Manage the evolution of the system once it is operational.
Suppliers
Build or supply the hardware, software, or infrastructure on which the system will run.
Support staff
Provide support to users of the product or system when it is running.
Systems Administrators
Run the system once it has been deployed.
Testers
Test the system to ensure it is suitable for use.
Users
Define the system functions and ultimately use it.

After identifying all the stakeholders, the next task is to capture their concerns. The concerns are subsequently categorized, prioritized, and specified formally as functional requirements (usually as use cases) or non-functional requirements (qualities and constraints).


The AmGro-from-Home case study

The fictitious AmGro-from-Home case study will serve as an example to explain the technique. The case study is based on an actual client engagement, uses real business requirements, and closely follows the architecture and design work developed during the project. (AmGro-from-Home is used in the IBM internal architecture class called Component Modeling.)

AmGro wants to venture into home shopping, with the capability to offer services over several "channels:"

Call CenterCustomers get a paper catalog of available goods from AmGro stores or in the mail. They will use the catalogs to place orders by telephone.
InternetCustomers browse and order online. AmGro envisions a fairly typical Internet service, which will likely be used by customers who want to place a smaller than average order and who only use a home shopping service from time to time.
In-store AmGro-from-Home is an ideal mechanism for extending AmGro's in-store product range. Though not in the first phase, there's a desire to install in-store kiosks from which customers can order items otherwise not available to them from AmGro (future requirement).

This article focuses only on the capabilities to Create Orders (Shopping carts) and Submit Orders with delivery and payment details to the AmGro Main Order Office.

The AmGro environment includes the locations and logical nodes shown in Figure 2. External nodes are not part of the AmGro system, but AmGro has interfaces to them.

Figure 2. AmGro locations
AmGro locations

For AmGro, the initial attempt at identifying components based on an analysis of the functional requirements produces the component model shown below.

Figure 3. AmGro initial component model
AmGro initial component model

The responsibilities identified for the various components shown in Figure 3 are described in Table 1 below.

Table 1. AmGro Component Responsibilities
Component Responsibilities
Dialogue Mgr Manages the flow of screens for the users (customers, call center representatives) and the related security.
Customer Processing Handles the creation, update, removal, and search of customer records. Creation includes an address check and approval by the finance department based on a credit history check. Deletion includes a check that no orders/shipments are pending.
Customer Mgr Manages create, read, update and delete (CRUD) operations in the customer database.
Order Processing Handles the creation, submission, cancellation, and search of orders. Creation and submission includes a credit card check and a check on the availability of goods at the warehouse. Cancellation includes a check that no shipments have already been sent.
Warehouse Intf Interface to the existing warehouse system. Sends stock query and stock update messages.
Credit Auth Intf Interface to the external credit card (CC) system. Sends a credit history check and a credit authorization check.
Order Mgr Manages CRUD operations in the order database.
Product Mgr Manages CRUD operation in the product database.
Mail Intf Interface to the existing mail system for sending e-mails to customers after order submission or update.

A Deployment Unit (DU) is the mechanism used to support the deployment of components or data onto nodes on the operational model. The Architecture Description Standard (SDS) defines four types of DUs according to the four aspects of a component:

Presentation DUs
Show the way the processes and data of an IT system are presented to external actors (both human and system).
Execution DUs
Describe the processes (the 'execution' of the process requiring computational resources) supported by the IT system.
Data DUs
Describe the data that is managed by the IT system.
Installation DUs
Describe where components are installed.

Table 2 below shows three of these DUs for the components defined previously. Ignore installation DUs for this example. For each component we have an initial assignment of DUs based on the responsibilities assigned to the components in Table 1.

Table 2. Component to DU mapping
Component Presentation DUData DUExecution DU
Dialogue Mgr U_DLG
Customer Processing E_Create_Cust, E_Update_Cust, E_Search_Cust, E_Remove_Cust
Customer Mgr D_Cust_Data E_Cust_CRUD
Order Processing E_Submit_Order, E_Create_Order, E_Cancel_Order, E_Search_Order
Warehouse Intf U_WH_INT E_Check_Stock, E_Update_Stock
Credit Auth Intf U_CA_INT E_Auth_Payment, E_Credit_Check
Order Mgr D_Order_Data E_Order_CRUD
Product Mgr D_Product_Data E_Product_CRUD
Mail Intf E_Send_Mail

Table 2 identifies an initial set of DUs based on an analysis of the responsibilities assigned to components, which came from the functional requirements. However, there are also the non-functional requirements you must consider. The main non-functional requirements of the case study are in Table 3 below.

Table 3. Non-functional requirements of the case study
Non-functional requirementDescription
Response Times No page should take more than 2 seconds to display (including search results).
Scheduled Service Hours The system will be available 24 hours per day, 6 days per week, with the possibility of a 2 hour service outage 1am to 3am GMT on Monday morning.
Unscheduled Service HoursThe system should have no more than 2 hours unscheduled outage per month.
Network Infrastructure AmGro's network infrastructure across office and store locations consists mainly of 64 Kb/s leased lines. A similar arrangement is anticipated for linking the outsourced Call Center to AmGro HQ. Historical data suggests that the Availability characteristics of the existing network are, at best, standard.
Degraded Functionality Unavailability of some parts of the system (planned or unplanned) must not prevent a Call Center Representative (CSR) from providing some level of service to the customer. A CSR in the Call Center must be able to create an order, add items to the order, and complete an order. They must have access to product descriptions and order codes to search by key word and confirm item selection.
Data Volatility Product and Customer information are considered Low Volatility, while Orders are subject to constant changes. Both Customer and Order data must be at the latest update level to be used.
Page Requests Per Second The AmGro-from-Home Order management system must support 80 orders per hour (peak hour 18:00 - 19:00), after 2 years, via the Internet.
Channel Hopping Customers must be able to begin shopping on one channel and then switch to another before completing their order.

For example, a customer starts to build an order online over the Internet. At some point, she contacts the Call Center with an inquiry on a product feature. Following a discussion with the CSR, who will probably need to "see" the partial order, the customer wants the CSR to add this product to their shopping basket and then submit the order.

Development Team Skills AmGro has made a large investment in J2EE technology, so the application has to be developed in Java.
ScalabilityA massive increase in Internet usage is foreseen in the next three years. The system must be able to scale to loads (users, pages per second, and so on) that are twice what's currently planned.

With the non-functional requirements above, you can now apply our method for determining how best to place DUs based on the combined functional and non-functional requirements.


The "Conflicting Forces" analysis method

The "Conflicting Forces" method for analyzing requirements is organized into four steps.

  1. Identify conflicts between use cases and non-functional requirements.

    The example will consider only two use cases. In reality, you should consider all of the architecturally-significant use cases. The Requirements Conflict Matrix (RCM) tool described earlier was used to represent the conflicts map. The matrix, in Figure 4, records the interaction between two requirements (A and B). The requirement on the row is A, and B is the requirement on the column.

    • If A and B conflict, meaning a solution that meets A is likely to be negatively affected by B, place a -1 in the cell and color it red.
    • If A and B concur, meaning a solution that meets A is likely to be positively affected by the solution of B, place a 1 in the cell and make it green.
    • If a solution that meets A is likely to neither positively nor negatively be affected by B, place a 0 in the cell and do not change its color.
    Figure 4. Use requirements conflict matrix (use cases only)
    Use requirements conflict matrix (use cases only)

    To understand the rationale when completing the RCM, consider the first two columns only. We decided that both the use cases will be negatively affected by the Network Infrastructure non-functional requirement (the existing network is slow and unreliable, and will therefore affect all use cases). However, only use case "Create Order" will be affected by the Degraded Functionality non-functional requirement, because the requirement states that orders must be able to be created even if there is degraded function - but doesn't say anything about ability to submit orders.

    Some non-functional requirements have no, or unspecified, impact. For example, at this stage there is no indication that the "Submit Order" use case will be affected by the non-functional requirement Developed in Java.

    Similar thinking was used when completing the RCM for the remaining columns.

  2. Complete the matrix by identifying conflicts among non-functional requirements.
    Figure 5. Requirements conflict matrix (completed)
    Requirements conflict matrix (Completed)

    Consider the throughput-related non-functional requirements (Pages per Second and Scaling to 2X the Current Workload). These will be negatively affected by the slow and unreliable network infrastructure, and by the requirement for always up-to-date order data (which prevents data being cached).

    On the other hand, the need to continuously have customer and order data up-to-date also complicates the ability to support the Degraded Functionality, Channel Hopping, and Unscheduled Outages non-functional requirements, since they might produce conflicts on the data.

    You now have a set of "stress cases" for the solution. For a stress case, one of the rows of the RCM contains at least one conflicting pair of requirements, indicated by a red cell with -1.

    The next step analyzes the consequences of the stress cases on the solution, and tries to re-factor the component model for the solution to resolve the stress cases. To do this, you'll focus on the stress cases that include both functional and non-functional requirements. Think of these as the sets of correlated opposing forces that will affect the (currently functional) component model.

    Purely non-functional stress cases (a row containing conflicts between non-functional requirements only) are best addressed by reviewing the operational model. This article doesn't cover these occurrences.

  3. Analyze the consequences of the stress case on the components involved in the use cases execution.

    A consequence can be a combination of three basic types:

    • DU Placement - The component (one or more of its DUs) must be placed in a specific location on the Location Map of the system to address the stress case.
    • Modified Responsibility - The component has to take an additional responsibility to address the stress case.
    • New Component - The component model must be enriched with a new component to resolve the stress case.

    To identify changes to the component model, it's good practice to consider the placement-related issues, as they may influence several types of non-functional requirements. Modified placements might also require modified responsibilities in existing components. Constraints linked to the network's bandwidth or reliability are typical examples of placement-related issues.

    At this point you can review the sequence diagram of the 'stress' use case to test its adequacy in view of the remaining constraints and quality objectives.

    Go through the example to see how you might address the stress cases. First, consider how the first stress case may affect the components involved in the "Create Order" use case.

    • You're aware that the requirement to keep the existing network is conflicting with most other functional and non-functional requirements. This is especially troublesome for the Call Center, which has requirements for working on degraded functionality in case of connection failure.

      On the other hand, a solution to support Degraded Functionality will help reduce the availability impact of the planned service hours and of the unplanned outages. To support the degraded functionality, you need to make the Call Center as autonomous as possible from the main order location. You can achieve this by replicating in the Call Center the Create Order use case execution logic and the Products Catalog (low volatility) data (DU Placement).

    • To support the Product Data replication to the Call Center, introduce a "publish and subscribe" technical component and related DUs (New Component).
    • The high volatility of the orders does not allow a replication solution; you're forced to keep a single image of the submitted orders database in the main order location. To address the channel-hopping constraint and the response time requirement, keep in-flight copies of incomplete orders in the other locations.

      Initially, this encompasses just the Call Center but later it could include the in-store kiosks. In this way, you can make the peripheral sites autonomous in the order creation task (Modified Responsibility of the Order Manager Component). The same Publish & Subscribe component introduced earlier will handle the alignment of the incomplete orders database by aligning incomplete orders in all locations.

    Now, consider how the second stress case may affect the components involved in the "Submit Order" use case.

    • For this case, degraded functionality is not a requirement -- resilience to unscheduled outages, response time, and alignment of order data are the only requirements. To shorten process and response time, and handle failures, orders can be submitted asynchronously from the interface, with control being returned to the user once the process is started.
    • The Order Process component will ensure recovery of the (complex) order submission process by saving its state in permanent storage (Modified Responsibility). The final confirmation to the Customer will be by e-mail only.

    Stress case resolution can be documented in a tabular form, as shown below.

    Stress Case Name Submit Order
    Source Requirement Submit Order
    Conflicting Requirement(s) Network Infrastructure: Existing infrastructure unlikely to allow orders to be submitted 24x7.
    Data Volatility: What if a product is being changed when an order is submitted?
    Response Times: Existing system for dealing with orders means order submission is unlikely to meet response time.
    Unscheduled Outage: Unscheduled outages may affect submission of orders.
    Scalability: The Use Case execution flow must be able to handle twice the current volume of orders.
    Resolutions Modified Responsibility: Component Order Processing must be able to save its state.
    Modified Responsibility: Component Order Processing must be able to restart its process in case of system failure.
  4. Convert the above analysis into an updated component model.

    The updated model will have:

    • A modified structural view (showing the new components).
    • A modified responsibility table, showing new and modified components.
    • A modified mapping view, represented by an updated component to DU mapping table, which will show how the additional responsibilities map to DUs.

    Figure 6 is an updated component model showing the additional component you've identified: the Store and Forward Mgr.

    Figure 6. Modified component model
    Modified component model

    The modified AmGro component responsibilities are shown below.

    ComponentResponsibilities
    Order Processing Handles the creation, submission, cancellation, and search of orders. Creation and submission include a credit card check and a check on the availability of goods at the warehouse. Cancellation includes a check that no shipments have already been sent.

    Manages partial orders and their notification. The process is asynchronous, interruptible, and restartable/recoverable.

    Order Mgr Manages CRUD operations in the order database for both full and partial orders.
    Publish & Subscribe MgrManage a reliable distribution of update events.

    Finally, you take the updated DUs and place them onto nodes, as shown in Figure 7.

    Figure 7. DU mapping diagram

Conclusion

In this article you learned about a method for systematically reviewing non-functional requirements in the design of the component model for an IT system. You explored the interaction of requirements with use cases, and learned how the stress case helps identify potential conflicts between functional and non-functional requirements.

Analyzing stress cases leads to a re-factored component model. You were able to add new components, modify the responsibility of already identified components, and place components in a new location in the IT System.


Acknowledgements

The authors would like to thank Jeremy Caine, Jim Hunter, and Philippe Spaas for reviewing early drafts of this article.

Resources

Learn

Get products and technologies

  • Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  • Download a free trial version of IBM Rational RequisitePro V7.1, a requirements and use case management tool for project teams who want to improve the communication of project goals, enhance collaborative development, reduce project risk and increase the quality of applications before deployment.
  • Download a free trial version of IBM Rational Software Modeler V7.5, a Unified Modeling Language (UML) 2.0-based visual modeling and design tool for architects, systems analysts, and designers who are responsible for specifying and maintaining system or software models and designs.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=369448
ArticleTitle=Analyze requirements for complex software systems in a new, holistic way
publish-date=02172009