<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore"
    xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-YeVRerdEixh4HgHOuw2KRQ"
    name="analyze_arch_reqs,_42UD4A3tEduibvKwrGxWxA" guid="-YeVRerdEixh4HgHOuw2KRQ"
    changeDate="2007-06-29T13:28:32.759-0700" version="1.0.0">
  <mainDescription>&lt;h4>&#xD;
    Identify architectural goals&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Architectural goals provide the motivation and rationale&amp;nbsp;for decisions. These goals are&amp;nbsp;often driven&#xD;
    by&amp;nbsp;the software requirements, particularly in&amp;nbsp;&lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/workproducts/supporting_requirements_spec_7D9DD47C.html&quot; guid=&quot;_BVh9cL-CEdqb7N6KIeDL8Q&quot;>Supporting Requirements Specification&lt;/a>, because they are not always&amp;nbsp;obvious from&amp;nbsp;the use cases alone [&lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../../openup/guidances/supportingmaterials/references_6CCF393.html&quot; guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>ALL02&lt;/a>].&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Architectural goals define how the system needs to respond to change over time. Consider these questions when writing&#xD;
    your goals:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        What is the expected lifespan of the system?&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Will the system need to respond to technological changes over that time, such as new versions of middleware or&#xD;
        other products?&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        How&amp;nbsp;frequently is&amp;nbsp;the system&amp;nbsp;expected to adapt to change?&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        What changes can we anticipate in the future, and how can we make them easier to accommodate?&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    These considerations will have a significant effect on the structure of the system.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Identify architecturally significant requirements&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Some of the requirements will be more significant than others when considered from an architectural perspective.&#xD;
    Identifying them will define&amp;nbsp;the subset of requirements that will generally need to be satisfied before the&#xD;
    architecture can be stabilised. Furthermore, the system will generally be more sensitive to changes&amp;nbsp;against&#xD;
    architecturally significant requirements&amp;nbsp;than others, so identifying and communicating ths subset will help others&#xD;
    understand the potential implications of change.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Requirements can be explicitly or implicitly architecturally significant. Implicitly significant requirements may&#xD;
    define the essence of the functional behaviour of the system (for example, making a purchase from an on-line store).&#xD;
    Explicitly significant requirements are often overtly technical in nature, such as performance targets; the need to&#xD;
    interface to other systems; the number of users that must be supported; or security requirements.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    See &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/guidances/guidelines/determine_architecturally_significant_requirements_817DFD9B.html&quot; guid=&quot;_D3JXMNvKEduv2KOT-Teh6w&quot;>Determine Architecturally Significant Requirements&lt;/a>&amp;nbsp;for more information.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Identify constraints on the architecture&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Gather information about the existing&amp;nbsp;environment and identify any constraints in the solution. This will ease&#xD;
    integration with the environment; and may reduce risk, cost and duplication of solution elements.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Architectural constraints can arise from various factors:&#xD;
&lt;/p>&#xD;
&lt;div style=&quot;MARGIN-LEFT: 2em&quot;>&#xD;
    &lt;ul>&#xD;
        &lt;li>&#xD;
            Network topology&#xD;
        &lt;/li>&#xD;
        &lt;li>&#xD;
            Use of a given database vendor or an existing database&#xD;
        &lt;/li>&#xD;
        &lt;li>&#xD;
            Web environment (server configurations, firewall, DMZs, and so forth)&#xD;
        &lt;/li>&#xD;
        &lt;li>&#xD;
            Servers (hardware model, operating system)&#xD;
        &lt;/li>&#xD;
        &lt;li>&#xD;
            Use of third-party software or a particular technology&#xD;
        &lt;/li>&#xD;
        &lt;li>&#xD;
            Compliance with existing standards&#xD;
        &lt;/li>&#xD;
    &lt;/ul>&#xD;
&lt;/div>&#xD;
&lt;p>&#xD;
    For example, if the company uses only one type of database, you will probably try to use it as much as possible to&#xD;
    leverage&amp;nbsp;the existing database administration skills, rather than introducing a new one.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    These architectural constraints, combined with the requirements, help you define&amp;nbsp;an appropriate&amp;nbsp;candidate for&#xD;
    the system architecture.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Survey, assess, and select from available assets&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    To assess and select assets to reuse on your project, you need to understand the requirements of the system's&#xD;
    environment. You also need to understand the scope and general functionality of the system that the Stakeholders&#xD;
    require. There are several types of assets to consider, including (but not limited to): reference architectures;&#xD;
    frameworks; patterns; analysis mechanisms; classes; and experience. You can search asset&amp;nbsp;repositories (internal or&#xD;
    external to your organization) and industry literature to identify assets or similar projects.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    You need to assess whether available assets contribute to solving the key challenges of the current project and whether&#xD;
    they are compatible with the project's architectural constraints. You also need to analyze the extent of the fit&#xD;
    between assets and requirements, considering whether any of the requirements are negotiable (to enable use of the&#xD;
    asset). Also, assess whether the asset could be modified or extended to satisfy requirements, as well as what the&#xD;
    tradeoffs in adopting it are, in terms of cost, risk, and functionality.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Finally, decide, in principle, whether to use one or more assets, and record the rationale for this decision.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Define approach for structuring the system&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Structuring your system helps you manage its complexity by using the well-known &quot;divide and conquer&quot; strategy. By&#xD;
    breaking the process into smaller and more manageable pieces, you make development easier.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Layering&amp;nbsp; is&amp;nbsp;one of the most&amp;nbsp;commonly used&amp;nbsp;approaches for structuring and decomposing systems. Each&#xD;
    layer groups similar classes or components, which communicate insofar as possible only with adjacent layers.&amp;nbsp; See&#xD;
    &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/guidances/guidelines/layering_F169CF07.html&quot; guid=&quot;_0gpkAMlgEdmt3adZL5Dmdw&quot;>Guideline: Layering&lt;/a> for more information.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    You do not define which layers contain which classes or components. Instead, you define how many layers you will need&#xD;
    and which kinds of layers you will use. For example, if you are developing a new middleware system, you probably do not&#xD;
    need a business layer. Later, during&amp;nbsp;design activities, you decide which classes and components will populate&#xD;
    these layers.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Define approach for deploying the system&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Develop a high level overview of how the software is deployed. For example, determine if the system needs to be&#xD;
    accessed remotely, or has requirements that suggest distribution across multiple nodes. Some sources of information to&#xD;
    consider are:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        users at geographical locations&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        organization of business data&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        service level requirements&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        constraints (such as requirements to interface with legacy systems)&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Validate that the deployment overview supports users (especially those users at remote locations if this is required)&#xD;
    performing typical&amp;nbsp;usage scenarios&amp;nbsp;while satisfying nonfunctional requirements and constraints. Validate that&#xD;
    the nodes and connections are adequate to support the interactions between components on different nodes, and between&#xD;
    components and their stored data.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Identify key abstractions&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Requirements and analysis tasks usually uncover key concepts and behaviors that the system must be able to handle.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The concepts manifest in design as key abstractions.&amp;nbsp;Key behaviors should correlate with the scenarios identifed&#xD;
    as part of the architecturally significant requirements and represent the important interactions between key&#xD;
    abstractions.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/workproducts/vision_2E71B03C.html&quot; guid=&quot;_0WVxcMlgEdmt3adZL5Dmdw&quot;>Vision&lt;/a> and &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/workproducts/glossary_5D300778.html&quot; guid=&quot;_Wn7HcNcEEdqz_d2XWoVt6Q&quot;>Glossary&lt;/a> work products are&#xD;
    good sources for key abstractions. These abstractions are often easily identified because they represent things that&#xD;
    are significant to the business. For example, Customer and Account are typical key abstractions in the banking&#xD;
    business.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The abstractions that&amp;nbsp;are identified at this point will also probably change and evolve during the course of the&#xD;
    project. The purpose of this step is not to identify&amp;nbsp;the complete&amp;nbsp;set of classes and relationships that will&#xD;
    survive throughout design.&amp;nbsp;Rather, it is&amp;nbsp;to identify the&amp;nbsp;important&amp;nbsp;concepts that the system must&#xD;
    handle. The value in calling them out early in the project is that everyone on the team understands the importance of&#xD;
    these&amp;nbsp;concepts and develops&amp;nbsp;coherant software to handle them consistently.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Don't spend too much time describing&amp;nbsp;abstractions in detail at this initial stage, because there is a risk that&#xD;
    spending too much time will result in identifying classes and relationships that the solution does not actually need.&#xD;
    When&amp;nbsp;identifying&amp;nbsp;key abstractions, it can be useful to also define any obvious relationships that exist&#xD;
    between them.&amp;nbsp;These can be captured in a table or&amp;nbsp;in diagrams (in a tool or whiteboard), and create a short&#xD;
    description for each abstraction.&amp;nbsp;In general, it is not worth agonizing over defining a highly detailed set of&#xD;
    relationships at this early stage in design. The relationships will become more concrete and detailed later and&#xD;
    will&amp;nbsp;probably modify&amp;nbsp;these early&amp;nbsp;assumptions.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Identify&amp;nbsp;architecture mechanisms&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    See&amp;nbsp;&lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/guidances/concepts/arch_mech_2932DFB6.html&quot; guid=&quot;_mzxI0A4LEduibvKwrGxWxA&quot;>Concept: Architectural Mechanism&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Capture architectural decisions&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    It is often useful to record key architectural decisions and working assumptions on an architectural overview diagram&#xD;
    to make it easier to communicate the architecture to the project team and stakeholders.&amp;nbsp;This information should be&#xD;
    part of the description of the architecture, but it can vary in format to suit the needs of the project.&amp;nbsp;For&#xD;
    example, on an agile and low-ceremony project the overview diagram can be an informal picture story board or a graph&#xD;
    with icons on either a whiteboard or a drawing tool. The illustration needs to show the nature of the proposed&#xD;
    solution, convey the governing ideas, and represent the major building blocks.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Architecture decisions should be captured in the &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/workproducts/architecture_notebook_9BB92433.html&quot; guid=&quot;_0XAf0MlgEdmt3adZL5Dmdw&quot;>Artifact: Architecture Notebook&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    If a more complex system is required, then the architecture can be represented as a more comprehensive set&#xD;
    of&amp;nbsp;views that describe the architecture from a number of viewpoints. See &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/guidances/guidelines/architectural_view_FF6EDA37.html&quot; guid=&quot;_T9nygClEEduLGM8dfVsrKg&quot;>Architectural View&lt;/a>&amp;nbsp;for more information.&lt;br />&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>