답변.

문제의 역사:

전통적인 프로젝트와 애자일 프로젝트에서 분석 산출물에 대한 요구 사항은 다릅니다: 어떤 곳에서는 상세한 사양과 클래스 다이어그램이 필요하고, 어떤 곳에서는 간단한 테이블/스케치로 충분합니다. 많은 조직이 자체 템플릿을 가지고 있지만, 문서의 실제 유용성은 그것의 적시성과 응용 가능성에 의해 결정됩니다.

문제:

표준 산출물 집합의 부재는 혼란을 초래하며(‘언제 무엇을 그릴까?’), 과도한 양은 관료주의와 팀에서 사용되지 않는 구식 문서로 이어집니다. 종종 분석가들은 개발자 및 테스터와의 상담 없이 ‘형식적으로’ 산출물을 만듭니다.

해결책:

능숙한 시스템 분석가는:

• 팀과 고객과의 초기 미팅을 진행하여 그들의 고충과 편리한 산출물 형식을 파악합니다.
• 문서에 대한 책임 매트릭스 (RACI)를 형성합니다: 어떤 산출물이 누구에게 필요한지, 누가 그것을 유지하는지, 어떤 단계에서 필요한지를 정의합니다.
• 아키텍트 및 리더들과 협력하여, 예를 들어 클래스 다이어그램이 필요한 복잡한 논리의 경우와 BPMN 프로세스 또는 목업으로 충분한 경우를 협의합니다.
• 프로젝트 진행 중 산출물 집합을 지속적으로 확인하고 검토합니다 — 적시성이 완전성보다 우선입니다.

주요 특징:

• 보편적인 산출물 집합은 없습니다: 다양한 프로젝트마다 다양한 문서가 필요합니다.
• 커뮤니케이션과 공동 합의는 성공의 기초입니다 (공유 소유권).
• 각 산출물은 특정 문제를 해결해야 하며, 살아 있고 관리되어야 합니다.

함정 질문.

모든 상황에 대해 단일 다이어그램(예: BPMN)만 사용하는 것이 가능한가?

아니요, 각 다이어그램 또는 문서는 시스템의 다른 측면을 드러냅니다: BPMN은 프로세스를, UML은 객체 및 상호작용을, 테이블은 참조를 위해 사용됩니다. 이들을 조합하는 것이 최선의 관행입니다.

항상 상세한 요구 사항 사양 문서가 필요한가?

항상 그렇지는 않습니다. 스타트업, 파일럿, 애자일(Agile) 프로젝트에서는 백로그에 기반한 간단한 문서로 충분할 수 있습니다 — 팀이 작업을 이해하기만 하면 됩니다.

분석가가 팀에게 자신의 문서 템플릿을 따르도록 요구할 수 있는가?

아니요. 문서 형식과 템플릿은 팀과 고객과의 논의 및 합의 과정에서 발생해야 하며, 모든 참여자에게 편리해야 합니다.

일반적인 실수 및 안티패턴

• 다른 프로젝트에서 전체 문서 패키지를 기계적으로 복사합니다.
• ‘문서화를 위한 문서화’를 합니다.
• 팀의 피드백을 무시하고 적절한 산출물 작업을 거부합니다.

실생활 예

부정적인 사례: 시스템 분석가는 기업 프로젝트의 각 프로세스에 대해 6개의 다른 다이어그램을 도입했습니다. 팀은 문서 덩어리에 압도당했고, 아무도 그것을 읽지 않았으며, 구술 작업으로 진행했습니다.

장점:

• 높은 수준에서 시스템을 형식화하려는 의지.

단점:

• 시간 낭비, 혼란.
• 구현 시점에 부정확한 문서.

긍정적인 사례: 다른 프로젝트에서 분석가는 BPMN 다이어그램과 간단한 속성 표만 기록하고, 개발자와의 회의 후 정기적으로 그것들을 확인하고 업데이트했습니다.

장점:

• 최소한의 필요 산출물 패키지.
• 문서는 실제로 팀에서 사용되었습니다.

단점:

• 때때로 외부 감사인을 위해 추가 보고서와 도표가 필요했습니다.