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
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
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 Center | Customers get a paper catalog of available goods from AmGro stores or in the mail. They will use the catalogs to place orders by telephone. |
|---|---|
| Internet | Customers 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
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
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 DU | Data DU | Execution 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 requirement | Description |
|---|---|
| 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 Hours | The 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. |
| Scalability | A 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.
- 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
-1in 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
1in 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
0in the cell and do not change its color.
Figure 4. 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.
- If A and B conflict, meaning a solution that meets A is likely to be
negatively affected by B, place a
- Complete the matrix by identifying conflicts among non-functional requirements.
Figure 5. 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.
- 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. - 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
The modified AmGro component responsibilities are shown below.
Component Responsibilities 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 Mgr Manage 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
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.
The authors would like to thank Jeremy Caine, Jim Hunter, and Philippe Spaas for reviewing early drafts of this article.
Learn
- The operational context diagram (developerWorks, Feb. 2009): Learn about a technique to complement
the SCD with a non-functional oriented operational context diagram.
- Wikipedia's
Notes
on the Synthesis of Form describes Christopher Alexander's 1964 book
about the process of design.
-
The Handbook of Software
Architecture (Grady Booch, IBM 2007) is a concise reference on the design and construction of software-intensive systems.
- Software Systems Architecture - Working With Stakeholders Using Viewpoints
and Perspectives by Rozanski and Woods is a practitioner-oriented guide to designing and implementing effective architectures for information systems. It is both a readily accessible introduction to software architecture and an invaluable handbook of well-established best practices.
- Visit the
Rational RequisitePro
area on developerWorks
for resources to help you manage requirements.
- Visit the
Rational Software
Modeler area on developerWorks
for resources to help you do visual modeling and design.
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
- Check out
developerWorks blogs
and get involved in the
developerWorks community.
Fabio 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.
Pete 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.
