1. 시스템은 시스템 외부와 어떻게 연계되어 있는가? 
2. 어떤 개념과 역할을 지닌 시스템을 만들고자 하는 것인가? 
3. 내부에 주요 모듈은 어떤 것이 있는가? 
4. 모듈들은 어떻게 상호 동작하는가? 
5. 소프트웨어 로직이 하드웨어 상에 어떻게 배포 되는가? 
6. 각각의 구성 요소들의 역할은 무엇인가? 





소프트웨어 아키텍처를 정의하는 가장 처음에 해야할 일은, 

목표 시스템을 정의하는 것이다.

무엇을하는 시스템인가? 누가 사용하는 것인가?

언제 사용될 것인가? 어떤환경에서 사용되는가? 

어떤 시스템과 연동을 해야 하는가? 

한번만 사용될 것인가? 여러번에 걸쳐 적용되어 사용될 것인가?

에 대한 정의가 필요하다. 


아키텍처 문서 작성의 7가지 원칙

1. 도큐먼트는 작성자가 아닌 독자의 입장에서 쓰여져야 한다. 
     - 읽기 좋은 문서가 아닌, 참조하기 좋은 문서가 되도록 구성되어야 한다. 
     - 독자를 위하여 정중하게 작성하라. 
     - 작성자가 모르는 것이 무엇이며, 결정되지 않은 것이 무었인지 비워두지 말고, 표시해 두어라. 
     - 불필요한 어려운 말은 피하고, 함께 일하는 사람들이 이해할 수 있는 용어를 사용하라. 
 
2. 불필요한 반복을 피해야 한다. 
    - 하나의 정보는 하나의 장소에서만 기록되어야 한다. 이는 문서를 사용하기 편하고, 지속적으로 
      수정하기 편리하게 만들며, 혼돈을 피할 수 있게 한다.  
    - 반복되는 정보가 조금씩 다르게 나타날때, 독자는 혼란에 빠진다. 이게 무슨의미인가? 하고. 
    - 참고 정보는 그때그때 기록하여 보기 편하게 만들어라. 
    - 반복을 피하기 위해서 독자가 지불해야할 대가가 너무 클때에만, 정보를 반복하여 기록하라.  
 
3. 모호함을 피하라. 
    - 아키텍처가 유용한 첫번째 이유는 시스템이 개발되기 전에 풀어야 하는 여러 세부 사항들을 
      압축하여 정리하고 유도될 수 있게 만들기 때문이다.  때문에 아키텍처는 애매모호한 부분이 있다고 
      말할 수도 있다. 아키텍처 문서는 다양한 방식으로 해석될 수 있고, 이들의 해석이 목적에 부합하다면 
      틀린 것이 아니다.  그러나, 문서가 한가지 이상의 방식으로 해석될 수 있고, 이들 해석중에 부적절한 
      것이 있다면, 이는 혼란을 야기한다. 
    - 아키텍처 문서는 이러한 혼란을 막기 위할 정도로 충실하게 작성되어야 한다.  
    - 만약 당신이 새로운 표기법을 사용했다면, 당신이 사용한 표기법에 대해서 설명하라. 
 
4. 표준 구성을 사용하라. 
   - 표준적이고, 계획된 문서 구조를 구성하고, 문서를 그에 맞도록 작성하라. 
      그리고 유저가 이러한 구성에 익숙한지 확인하라. 
 
5. 이성적인 근거를 기록하라. 
   - 만약 결정들의 결과를 기록할때, 거부한 결정들과 이들을 거부했는지 사유를 기록하라. 
      이는 재논쟁을 막아줄 것이다. 장기적으로는 이는 당신의 많은 시간을 절약할 수 있게 한다. 
 
6. 문서를 지속적으로 개정하되, 지나친 수정은 피하라. 
    - 정확하고 현재의 사항이 반영된 문서가 필요하다. 
      그렇지 않다면 문서의 신뢰성은 떨어지고, 사용되지 않을 것이다. 
      지속적으로 수정되는 문서는 "이 문서가 유용하다!"라는 아주 강력한 메시지를 전달한다. 
      다만, 아키텍처는 설계시에 빈번하게 사용되는 문서이기 때문에, 지나친 수정은 
      불필요한 소모를 야기하기 때문에, 지나친 수정사항의 반영 보다는 Version Control 주기에 
      맞추어 반영하는 것이 좋다.  
 
7. 목적에 부합한지 문서를 리뷰하라. 
    - 의도된 문서의 사용자(아키텍처 관련 Stakeholder로 추정)들만이 문서의 내용이 유용하고, 
     올바른 방법으로 표현되었는지 검토할 수 있다. 이들의 도움을 나열하고, 문서를 배포(Release)하기 
     전에 이들 그룹의 도움을 받아 리뷰 하라.