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