UAP Templates and Checklists

Use this checklist to confirm that requirements are clear, complete, and architecturally relevant before architecture design begins.

Step 1. Identify Stakeholders

• Stakeholder groups are identified from the SRS and from other sources, such as user interviews, existing systems, related documents, and domain expertise.
• Each stakeholder group is classified by role, influence, and relevance, and has an assigned representative.
• A communication plan keeps stakeholders engaged throughout architecture design.

Step 2. Refine Functional Requirements

• Functional requirements are reviewed and corrected for deficiencies such as incompleteness, inaccuracy, inconsistency, ambiguity, redundancy, and irrelevance.
• Refined requirements are validated by stakeholders, free of conflicts, and feasible within project constraints.
• Each refined requirement is traceable to its source, and the SRS reflects all refinements.

Step 3. Refine Non-Functional Requirements

• Architectural concerns are identified and documented, and non-functional requirements are derived from them.
• Non-functional requirements are reviewed and corrected for the same common deficiencies as functional requirements.
• Refined non-functional requirements are validated by stakeholders and feasible in the target operating environment.
• Each non-functional requirement is traceable to its architectural concern or stakeholder expectation, and the SRS is updated.

Use this checklist to confirm that the context model accurately captures the system’s boundaries, functionality, persistent data, and behavior.

Step 1. Analyze Boundary Context

• Each system tier appears as a process in the DFD, is self-contained and independently deployable, and keeps network overhead between tiers low.
• Terminals cover all user types, connected hardware devices, and external systems or services.
• Data stores hold only persistent data for their tier, and any duplicated data store is justified by clear benefits.
• Every data flow carries named data items and connects only valid elements, with no flows between two terminals, between two data stores, or between a terminal and a data store.

Step 2. Analyze Functional Context

• Functional groups match or validly refine the SRS categories, without overlap.
• Actors cover active and passive roles, including users, hardware devices, external systems, and software agents.
• Use cases cover all system functionality, including CRUD operations and core system functions, and have unique IDs, meaningful names, and consistent granularity.
• Actor–use case invocations are correct, actor-to-actor interactions are excluded, and generalization, «include», and «extend» follow UML semantics.

Step 3. Analyze Information Context

• Each class represents cohesive persistent data, and transient data is excluded.
• The class diagram includes physical, logical, and session-related classes.
• Association, aggregation, composition, and inheritance are each used with their correct meaning.
• Every relationship except inheritance has a valid cardinality, with optional links (0..1) and association classes applied where needed.

Step 4. Analyze Behavior Context

• Fork and join threads are balanced and independent, every Send Event has a matching Receive Event, inter-tier communication is explicit, and closed loops have defined termination.
• There is one activity diagram per tier (excluding virtual nodes), and functional groups are allocated to tiers without duplication or omission.
• Activities and use cases correspond in both directions, and each functional group has a suitable invocation pattern.

Use this checklist to confirm that the schematic architecture integrates suitable architecture styles into a stable and coherent structural layout.

Step 1. Identify Candidate Architecture Styles

• Candidate styles reflect the structural layouts and constraints stated in the SRS and implied by its non-functional requirements, such as scalability, availability, and security.
• The inherent types of the system, such as distributed or interactive, are identified accurately and completely.
• The set of candidate styles is complete and free of redundant, overlapping, or conflicting styles.

Step 2. Evaluate Candidate Architecture Styles

• Each candidate style is assessed against its applicable situations, benefits, and drawbacks, using evaluation items tailored to the target system.
• Practical mitigation strategies are defined for the identified drawbacks.
• Applicability is decided systematically from the average alignment scores and the weights of the evaluation items.

Step 3. Integrate Architecture Styles

• Each instantiated style includes all its required structural elements, named clearly and consistently.
• Styles are integrated in the recommended order, with their interactions and dependencies made explicit.
• The resulting schematic architecture is free of redundancies, conflicts, and ambiguities, and keeps a clear separation of concerns.

Step 4. Refine Schematic Architecture

• Conflicts or inconsistencies introduced during refinement are identified and resolved.
• Refined structural elements remain aligned with the functional and non-functional requirements.
• Connectors reflect the updated relationships, and each new connector is justified by clear benefits without undue cost, risk, or complexity.

Use this checklist to confirm that system functionality is refined into well-defined functional components with clear responsibilities, interfaces, and variability.

Step 1. Refine Use Case Model

• Each functional group has a single, cohesive responsibility, and its use cases are identified completely, for example with a CRUD-based method.
• Actors are complete, including software agents, and classified as active or passive, with active actors marked as primary or secondary.
• Actor–use case relationships and generalization, «include», and «extend» relationships are refined in line with UML guidelines.
• Complex or critical use cases have detailed descriptions that cover alternate and error flows.

Step 2. Define Functional Components

• Functional groups map to functional components, one-to-one unless an exception is justified.
• Architecture style–specific and interface-centric components are added where needed.
• Each component has clear boundaries, high cohesion, low coupling, and a noun-form name that follows the naming convention, and all components are shown in a UML component diagram.

Step 3. Allocate Functional Components

• Functionality placeholders in the schematic architecture are identified, each with a distinct responsibility.
• Components are allocated to tiers by function and by style-specific placement rules, with read-only and full-access roles distinguished in shared tiers.
• The schematic architecture is fully populated in line with the Functional Component Allocation Table, and responsibilities are balanced across tiers.

Step 4. Define Functional Component Interfaces

• Interfaces are defined for the components that need them, excluding small or low-complexity components.
• Provided interfaces expose public methods that are traceable to the component’s use cases.
• Required interfaces and setter methods are defined for components that bind external variants such as plug-ins, and all method signatures follow UML conventions.

Step 5. Design for Functional Variability

• Bindings between variation points and variants are shown with UML assembly connectors, and the adaptation schemes follow the Open-Closed Principle.
• Variation points within each component are identified and documented, and each valid variant is clearly described.
• The variant scope of each variation point is classified as binary, selection, or open-ended.

Use this checklist to confirm that persistent information is organized into well-structured data components with clear interfaces and reliable persistence.

Step 1. Refine Persistent Object Model

• All persistent datasets are identified, and each has a persistent class, including logical classes such as session-related or technology-dependent ones.
• Associations are defined correctly, including association classes with attributes, and structural design patterns are applied where they improve the model.
• The persistent attributes of each class are identified and clearly defined.

Step 2. Define Data Components

• Related classes are grouped into data components based on the order and hierarchy of their relationships.
• Data components are highly cohesive and modular, with minimal dependencies between them.

Step 3. Allocate Data Components

• Each data component is assigned to a tier or layer and placed with the functional components that manipulate it.
• Cross-tier dependencies are kept low, and access privileges are defined for distributed data components.
• Critical data components are replicated or distributed for availability and fault tolerance.

Step 4. Define Data Component Interfaces

• Public interfaces provide CRUD operations and, where needed, transaction methods such as commit, rollback, and validation.
• Method signatures are complete, including visibility, parameters, return types, and constraints.
• Common operations are defined at the superclass level, and subclass-specific methods keep internal logic encapsulated.

Step 5. Design Object Persistence

• The persistence medium, such as a relational database, NoSQL database, or cloud storage, fits the functional and non-functional requirements.
• Object mapping, such as ORM or ODM, translates correctly between objects and their stored form.
• Backup, recovery, sharing, and synchronization mechanisms are defined, and persistence is tested for fault tolerance and resilience.

Use this checklist to confirm that the system’s runtime behavior is refined into clear, complete, and consistent control flows.*

Step 1. Refine Overall Control Flow

• Each functional component uses the most suitable invocation pattern.
• Every Send Event has a matching Receive Event, and every closed-loop thread has a termination mechanism such as preemption or a defined exit condition.
• Parallel threads in fork–join constructs have no hidden interactions, and activities remain aligned with the use cases in the functional view.

Step 2. Identify Key Behavioral Elements

• Elements selected for detailed design are justified by their importance to system functionality or by their behavioral complexity.
• Representation schemes are chosen based on intended use, modeling formalism, required level of detail, and ease of interpretation.
• Ambiguous or adaptive behaviors are identified for explicit modeling.

Step 3. Define Detailed Control Flows

• The chosen diagrams, whether UML or other notations such as flowcharts or BPMN, follow the syntax, semantics, and conventions of their notation.
• Diagrams use the relevant modeling elements, such as states, transitions, actions, events, and swimlanes, to represent behavior completely.
• Algorithmic descriptions are clearly structured, for example as pseudocode, and specify branches, loops, recursion, and exception handling.
• Control flows cover edge cases and exceptional scenarios without logical gaps.

Step 4. Integrate Refined Control Flows

• Related detailed control flows are combined into a coherent representation of runtime behavior.
• Behavioral inconsistencies, such as conflicting triggers, states, or paths, are identified and resolved.
• The behavior view is consistent with the functional and information views, and the finalized view is documented.

Use this checklist to confirm that the deployment infrastructure and the allocation of software artifacts are fully and correctly specified.

Step 1. Define Computing Devices

• A computing device node is specified for each physical tier, with its essential hardware attributes.
• Hardware configurations meet the performance and reliability criteria, and specialized hardware such as GPUs is included where needed.
• Device nodes can scale to accommodate future workloads.

Step 2. Define Execution Environments

• Execution environments are identified for each device node from the design specifications.
• Each node has a suitable operating system, plus a language runtime or framework and a DBMS where required.
• All elements within the execution environments are verified to be compatible and interoperable.

Step 3. Define Connectivity

• Communication paths between nodes match the interaction patterns in the schematic architecture.
• Each connection specifies essential attributes such as protocol, port, bandwidth, and latency.
• Failover and redundancy are specified where applicable, and the network configuration can scale with future demand.

Step 4. Allocate Software Artifacts

• Deployment relationships use UML stereotypes such as «deploy», and a complete deployment diagram integrates all deployment decisions.
• All deployable artifacts are identified and aligned with the functional and data components, including control components such as controllers.
• Artifacts are organized into deployment packages where appropriate and allocated to suitable nodes, including presentation-layer artifacts.

Use this checklist to confirm that architectural tactics are systematically derived, evaluated, integrated, and validated to satisfy the non-functional requirements.

Step 1. Identify Facts and Policies

• Each non-functional requirement is analyzed to extract its underlying facts and policies, which are documented with references to relevant domain knowledge or standards.
• Facts and policies match the intent and scope of their non-functional requirement and are necessary for addressing it.
• Facts do not overlap, and together the facts and policies cover all critical aspects of each non-functional requirement.

Step 2. Define Criteria for Tactics

• Every fact and every policy is addressed by at least one criterion, with explicit traceability.
• Each criterion is stated in clear, directive language that can guide the design of tactics.

Step 3. Define Candidate Tactics

• Every criterion is realized by at least one tactic, and the tactics do not conflict with one another.
• Tactics are specified in sufficient technical detail and supported by figures, diagrams, tables, or algorithms.
• Tactics are feasible with the available tools, technologies, people, schedule, and budget.

Step 4. Evaluate Candidate Tactics

• The costs, benefits, conflicts, and trade-offs of each candidate tactic are analyzed.
• Rejected tactics are justified objectively and recorded in the Tactic Evaluation Table.
• The selected tactics fit the architectural goals, quality attributes, and design constraints, with stakeholder input on costly or risky trade-offs.

Step 5. Integrate Selected Tactics

• The design elements affected by each selected tactic are identified, and the impacts are analyzed.
• Tactics are integrated without introducing inconsistencies, redundancies, or conflicts, and all resulting changes are documented and validated.
• The integrated design is reviewed and approved by stakeholders.

Step 6. Validate Conformance

• The Conformance Map includes all design artifacts and shows the conformance relationships between consecutive design steps.
• Missing conformance is identified, its root causes are analyzed, and each gap has an actionable remediation plan.
• Remediation actions are validated and approved, and the validation results are documented and communicated to stakeholders.

Use this checklist to confirm that the architecture is evaluated systematically and that the findings are used to improve it.

Step 1. Identify Target Elements for Evaluation

• All design elements in the architecture description are listed and considered for evaluation.
• Elements with high technical uncertainty or implementation risk, and those with significant impact on compliance, regulation, or system quality, are selected.
• The selected elements reflect stakeholder priorities and project objectives.

Step 2. Define Architecture Evaluation Methods

• A suitable evaluation approach and method are chosen for each target element, tailored to the system’s characteristics and constraints.
• The chosen methods cover all relevant metrics and criteria.
• The methods fit the team’s expertise and resources, and their time and cost are feasible within project constraints.

Step 3. Apply Architecture Evaluation Methods

• The tools, frameworks, and resources for each method are prepared, and each method is applied rigorously according to its guidelines.
• Metrics and criteria are defined for each target element, and the results, including risks, deficiencies, and improvement opportunities, are consolidated into an evaluation report.
• Findings are communicated to stakeholders, their feedback is incorporated, and the architecture is refined accordingly.