개발자에서 아키텍트로

 

부쩍  아키텍트 관련 책을 많이 읽는 중 

아키텍트 이론보다도 
설계 변경된 부분을 시각화해서
파트원과 공유(워크숍, 문서 등)를 진행하는
실질적인 방법론을 얻고 싶어 
읽기 시작한 책이다.  

 

그중 ASR 워크북 만들기라는 부분이
지금 우리에게 필요하다는 것을 깨달았다.
(ASR = Architecturally Significant Requirement)

파트원들과 자주 하는 대화인데, 

"어제는 맞았고, 오늘은 아니다."
"이렇게 결정되었었는데,
그때 그렇게 결정한 이유가 뭐였죠?"

 

워낙 하루에 결정하고
정리해야 하는 많지만 ㅎㅎ
여러 서로 다른 부문에서의
다양한 요구사항에 따라 아키텍처, 스키마 등을 
지속 변경하게 되고 요구사항을 수용하기 위한
개념이 등장, 삭제되어서 그렇다는 것을 깨달았다. 

 

ASR은 아키텍쳐 핵심 요구사항으로
아키텍처를 선택하고 구성할 때
큰 영향을 미치는 요구사항을 말한다. 

ASR 구분 - 제약, 품질속성, 영향력있는 기능 요구사항, 기타

 

본 책에서는 이러한 ASR 등을 워크북이라는
노트로 지정하고 지속 갱신, 참고자료 화하고
시간이 지날수록 그간의 변화를 담는
역사책으로서의 의미를 지니게 할 것을 추천한다. 

지금 딱 필요한 것 같은 문서 🤓🤓
(지금 펼쳐져있는 컨플루언스 문서들을
줍줍해와서 편집해야지..)

본 책에서는 해당 체크리스트를 제공한다.

---

ASR 워크북 목차의 예

• 목적과 범위
• 사용자 범위
• 비즈니스 콘텍스트
  • 이해관계자
  • 비즈니스 목표
• 아키텍처 핵심 요구사항
  • 기술적인 제약
  • 비즈니스적인 제약
  • 품질 속성에 대한 요구사항
    • 최상위 시나리오
  • 영향력 있는 요구사항
    • 최우선 사용자 또는 페르소나
    • 유스케이스 또는 사용자 스토리
• 부록A: 용어집
• 부록B: 품질 속성의 위계와 분류 

---

우리 파트의 경우 영향력있는 요구사항이지만,
기존에 지켜야 하는 제약사항 및 개념들을 정리하기 위해
아래와 같이 정리할 예정이다. 

---

실전 목차(컨플루언스 문서) 

• 영향력 있는 요구사항 (등록자, 등록일)
• 반영에 따라 변경된 개념
  • 개념 명칭 
  • 개념 정의
  • 제약사항
  • 개발방향  
  • 개념 간의 관계를 보여주는 관계도

---

책에서의 이야기처럼
개발자, 테스터 물론 나에게도
프로젝트의 맥락과 다양한 정보를 제공해주기를 

그리고 잊지 말고
추후 프로젝트를 최초 시작하게 된다면
역사를 쌓아두기로...! 

[전자책] 개발자에서 아키텍트로