[SW Architect] Architecture Document Template

Architecture Document Descriptions

1. Project Overview

• 프로젝트 배경, 이해 관계자 정의, 활동 기간 및 프로젝트 목표에 대해 기술

2. Architectural Drivers

• 시장 및 비지니스 context
• 비지니스 및 기술적 제약
• 기능 요구 사항, Use case diagram, use case 시나리오
• 품질 요구 사항, Quality Attributes 시나리오

3. System Context

• 시스템 내/외부 구성도에 대한 정의 기술

4. Architecture Design

• 설계 내용 기술, 상위에서 하위 레벨의 설계 내용 기술, 필요에 따라서는 detail design 내용이 일부 포함될 수 있음
• 다양한 뷰 관점에서 설계 작성, Physical Perspective, Static Perspective, Dynamic Perspective

5. Architecture Verification

• 설계 안 검증에 대한 내용을 기술

6. Risk Management

• 프로젝트 진행 시 발생 또는 예상된 Risk 관리 내용 기술

7. Lesson & Learned

• 프로젝트 진행을 통해 얻은 배울점 및 반성 점 등에 대해 기술

8. Futrue Works

• 필요에 따라 본 프로젝트 완료 이후 예측되거나 추가 진행할 내용에 대해 기술

---

Architecture Process

설계 문서 작성 가이드 및 순서는 하기 기본 설계 프로세스에 준하여 작성한다.

Step	Activity	Descriptions
요구사항 분석	요구사항 분석	요구사항 취득, 식별, 명세, 분류, 검증 기능적/비 기능적 요구사항 분류 및 명세
아키텍처 분석	품질요소 식별	기능성, 신뢰성, 효율성, 유지보수성, 이식성 등
	품질요소 우선순위 결정	Utility Tree(품질요소의 목표 및 영향도 식별) 품질 시나리오 작성
	전술 개발(Tactic Develop)	품질 속성 별 전술 개발 및 명세
아키텍처 설계	관점 및 View 정의	이해당사자 파악 및 이해당사자 별 관점, View 정의 Module View, Component Connector View, Allocation View, Code View
	아키텍처 스타일 선택	Pipe-Filter, MVC, Layer 등 스타일 혼용 적용
	후보 아키텍처 도출	Context Diagram 및 각종 View 별로 다이어그램 작성 SAD(Software Architecture Description) 기술
검증 및 승인	아키텍처 평가	아키텍처의 요구사항 만족 적합성 평가 품질 속성 간 trade-off 관계 평가
	아키텍처 상세화(반복)	설계 매커니즘 도출 디자인 패턴 고려
	아키텍처 승인	고객 및 이해당사자 최종 승인

---

Architecture Document Template

Copyright

Copyright 내용 추가

 

About This Document

Revision History

Revision No.	Date	Author	Releated Page(Chapter + Req.No)	Comment(변경 내용 + 근거)
1.0	xxxx.xx.xx	Name	최초 작성

 

Person in Change

Person	Component	Role	Description
Name		Architect

 

Definition

Acronyms

Acronyms	Descriptions
FR	Functional Requirement
UC	Use Case
QA	Quality Attribute
QAS	Quality Attribute Scenario
TC	Test Case
WBS	Work Breakdown Structure

 

Reference architecture document

• SRS: SRS 링크 또는 문서 추가
• TC: Test Case 링크 또는 문서 추가

 

1. Project Overview

1.1. Overview

본 프로젝트의 진행 배경 등에 대한 설명을 작성한다.

 

1.2. Information

1.2.1. 프로젝트 요구 사항

본 프로젝트의 요구 사항의 간단한 설명을 작성한다.

1.2.2. 이해 관계자

본 프로젝트과 관련된 이해 관계자를 정의한다.

1.2.3. 활동 기간

본 프로젝트 계획부터 개발 완료까지의 개략적 활동 기간에 대한 설명을 작성한다.

 

1.3. Project Goal

본 프로젝트의 비즈니스 환경 기준 또는 개발 기준의 목표를 작성한다.

 

2. Architectural Drivers

2.1. Context

2.1.1. Market Context

Items	Descriptions
Stack holders/Customers	본 프로젝트의 이해 관계자를 정의한다.
Functional expectations	기능적 프로젝트의 기대 효과를 작성한다.
Target date	프로젝트의 일정 목표를 작성한다.
Notions of quality	본 프로젝트의 품질 목표를 작성한다.
Product package	본 프로젝트의 산출물을 정의한다.

2.1.2. Organizational Context

Items	Descriptions
Structure	본 프로젝트 개발 진행을 위한 구성안을 정의한다.

 

2.2. Constraints

2.2.1. Business Constraint

비즈니스 측면에서의 제약 조건을 정의한다.(출시 목표일 또는 산출물에 대한 설명을 작성한다.)

• Cost and Schedule
  예상되는 적시 출시 때의 시스템의 가격, 예상되는 프로젝트 기간, 사용 시스템과 기존 시스템의 활용
• Marketability
  시장 경쟁에 측면에 대한 시스템의 효용성
• Appropriateness for Organization
  투입 인력의 가용성, 전문가의 할당, 그리고 팀의 정렬과 소프트웨어 구조, 비지니스 프로세스 리엔지니어링에 대한 능력

2.2.2. Technical Constraint

기술적 측면에서의 제약 조건을 정의한다.(개발 언어, 개발 환경 그리고 설치 지원 환경 등을 작성한다.)

 

2.3. High Level Functionality

2.3.1. Functional Requirements

본 프로젝트의 요구 사항을 정의한다.

Level	Descriptions
Must Have	반드시 제공해야 하는 요구사항
Should Have	미래에 반영해야 할 것으로 예상되는 요구사항
Nice to Have	있으면 좋지만 우선순위가 낮은 요구사항. 우선은 반영하지 않는 것으로 생각
Won’t Have	반영되면 큰 risk가 생길 수 있는 요구사항

ID	Title	Descriptions	Priority
FR-01	요구 사항 제목	요구 사항에 대한 설명	Must Have

 

2.4. Use Cases

2.4.1. Use Case Diagram

본 프로젝트와 관련된 Use Case Diagram을 정의한다.

2.4.2. 기능 별 Use Cases

본 프로젝트에서 정의된 Use Case 중 설계 시 중요하게 고려되어야 할 대표 Use Cases 시나리오를 작성한다.

Use case ID	UC-01
Use case title	Use case t시나리오 title를 작성한다.
Stakeholders	Use case를 사용하는 이해 관계자를 정의한다. ex) 솔루션 사용자
Pre-conditions	Use case를 위한 선제 조건을 설명한다.
Post-conditions	Use case 종료 후 사용자에게 제공되는 정보 또는 시스템 반응 등을 설명한다.
Brief Description	Use case에 대한 간략한 정의를 설명한다.
Description	사용자 입력 기준 시스템 반응 순으로 기능 정의를 설명한다.
Exceptions	본 Use case 시나리오의 예외 조건 발생에 대한 정의를 설명한다.
Alternatives	본 Use case 시나리오의 대안 시나리오를 설명한다.

 

2.4. Quality Attributes

본 프로젝트와 관련된 품질 속성 측면에서의 요구 사항을 작성한다.

2.4.1. Priority Scale

Priority	Priority Value	Description	Score
H	Must Have	Solution에 반드시 포함되어야 하는 요구사항	5
M	Nice to Have	Solution에 포함되면 고객이 좋아할 만한 요구사항	3
L	If there is time	Solution에 포함되어야 하는지 충분히 재 검토 되어야 하는 요구사항	1

2.4.2. Difficulty Ranking Scale

Priority	Description	Score
H	복잡도가 높으며 구현하기 위해 노력이 많이 요구되는 요구사항	1
M	복잡도가 높거나 구현하기 위한 노력이 많이 요구되는 요구사항	3
L	보통의 복잡성과 적당한 노력을 요구되는 요구사항	5

2.4.3. Quality Attributes Priority

ID	Quality Attribute	Tactics	Descriptions	Priority	Difficulty	Score

2.4.4. Quality Attributes Scenarios

주요 QA로 선정된 항목들에 대한 QA 시나리오를 작성한다.

• Quality Attributes의 점수 순위 중 높은 순위를 차지한 QA를 선정
• 설계 복잡도가 높더라도 Priority Value가 5인 항목에 대해서는 QA 점수와 무관하게 중요 QA로 선정

ID	QAS-1
Scenario (s)	QA 시나리오에 대한 간략한 설명을 작성한다.
Relevant Quality Attribute(s)	연관된 QA
Stimulus	시스템에 도달했을 때 고려해 볼 필요가 있는 것
Stimulus Source	자극을 만들어내는 존재
Environmental Condition (s)	자극이 발생하는 특정 환경이나 상황
Artifact (if known)	자극을 받는 대상
Response	자극이 도달한 후 취해지는 행위
Response Measures	응답이 발생했을 경우, 요구사항을 검증할 수 있는 측정 방법

 

3. System Context Diagram

본 프로젝트의 시스템 내/외부 환경을 정리한 그림

• 외부와 연동하는 환경을 작성
• 외부 인터페이스 위주로 작성
• 다른 시스템과의 의존성을 표시

 

4. Architecture Design

4.1. Physical View / Allocation View

주변 환경에 존재하는 비소프트웨어 구조와의 연결 구조에 대한 정의 및 설명을 작성한다.

 

4.2. Static View / Module View

구현 단위들의 구조화된 구조에 대한 정의 및 설명을 작성한다.

 

4.3. Dynamic View / C&C View

실행 시간 행위나 상호 작용을 하는 요소들의 구조화된 구조에 대한 정의 및 설명을 작성한다.

설계 시 고려된 대안에 대해서도 기술하고 설계 안 선택을 위해 검토한 의사 결정 내용을 작성한다.

상위 레벨부터 Detail Design까지 각 기능 별 정의가 필요한 경우에는 단계를 나눠 설계 문서를 작성한다.

 

5. Architecture Verification

본 프로젝트에서 정의한 QA 시나리오를 검증할 계획을 수립하고 검증 결과에 대한 설명을 작성한다.

 

6. Risk Management

본 프로젝트 진행에 있어 위험 요소를 관리하기 위한 방안 등에 대한 설명을 작성한다.

 

7. Lesson & Learned

본 프로젝트 진행을 통해 배운 점에 대한 설명을 작성한다.

 

8. Future Works

본 프로젝트과 관련하여 향후 추가 진행 계획에 대한 설명을 작성한다.