During the project planning phase, the two most important components are the product requirements and the architectural design. These components create a clear vision for how the product should be engineered. The goal of the architectural design specification (ADS) document is to define the platform software architecture and to provide an assessment of the impact to all areas of the system necessary to complete the product.

Within a software system, there may be multiple parts making up a larger system. Each of these parts will need their own unique design and must be able to fit together. The system’s design should rely on this plan to provide a more detailed description of the reason it was created as such. Within this plan, introduce and discuss key design constraints, a high-level description of new functionality, and interfaces between software modules. The ADS should also contain guidance for significant updates to the existing software modules.

What’s included in the plan

    • Assumptions: Enter any assumptions being made concerning the system, and background on why they are being made. Solid requirements combined with well thought-out assumptions lead to higher quality architectures that are robust and flexible. Assumptions can include anything that may affect the completion, delivery or operation of the feature.
    • Hardware Dependencies: Describe each of the hardware devices and/or platforms associated with the software architecture for this product. These could include internal or external interfaces that must be in place for this implementation to be successful.
    • Architecture Summary: The Architectural Summary provides a basic overview of the conceptual implementation approach for each feature. It should provide a basis for the detailed design and show how the feature “fits” into the overall system.
    • Various Software Architecture Diagrams
      • Software Hierarchy Diagram: Depicting layers/modules relevant to features covered in the document.
      • Platform Specific Architecture Diagram: Depict strategic interaction between modules and discuss the new interfaces to the software platform at a very high level.
      • Use Case Sequence Diagram: Every use case scenario should have a high-level sequence diagram that presents the data modeling and flow. Multiple sequence diagrams may be required for normal and alternate flows. The goal is to identify and describe visually and verbally the areas of the platform software that are affected as derived from requirements and pertaining to the modules. The development of the normal and alternative flows may be iterative and require several passes until the full concept is understood and presented logically.
    • System Software Overview: This section should provide a composite of the use cases identifying the attributes of the feature. It provides the reader with a quick conceptual understanding of the overall use of the feature.  A short description of the drawing will assist the user in fully understanding the concepts.
    • Actors: In this section list the actors and describe their basic roles in the given system. Types of actors at a system software level include other software modules, hardware devices, and device drivers.  Input actors should reside to the left of the use case diagram and provide input stimulus to the software feature.  Output actors should reside to the right of the use case diagram with the feature providing output stimulus to the actor.  The guideline for actors is from the software perspective.
    • Use Cases: Use Cases assist project stakeholders in visualizing the organization of how the system is intended to be used. The Use Case should explicitly express the actor’s intent or propose. A use case starts when the actor does something. An actor always initiates Use Cases.  The Use Case describes actions of the actor and how the system responds and should be phrased in the form of a dialog between the actor and the system. The use case should describe what happens inside the system, but not how or why.

Our software architects are intimately familiar with creating architectural design specifications.

If you need assistance, contact us.

GET STARTED


No Comment

You can post first response comment.

Leave A Comment

Please enter your name. Please enter an valid email address. Please enter message.