초기의 분석가는 요구 사항을 별도로 문서화하고, 그들 간의 상관관계에 대해 항상 고민하지 않았습니다. 이는 소규모 시스템에서는 작동했지만, 대규모 IT 프로젝트에서는 요구 사항 간의 관계의 복잡성이 급증합니다. 데이터 의존성이 생기고, 무결성 위반, 모순 및 연쇄적 변경이 발생하여 실패 위험이 증가합니다.
문제 — 요구 사항 간의 관계 부족 또는 암시는 기능 블록 누락, 버그, 차단 작업 및 팀 간의 비협조적인 작업으로 이어집니다. 종종 하나의 요구 사항이 변경되면 관련된 요구 사항은 뒤처지고, 이는 제품 작업에 문제를 일으킵니다.
해결책 — 명시적 모델링 및 의존성 추적(요구 사항 의존성 매핑) 관행을 사용하는 것입니다. 이를 위해 다이어그램(예: 추적 매트릭스, ERD), 전문 도구(Jama, Jira 링크, DOORS), "부모" 및 "자식" 요구 사항의 확실한 문서화, 그리고 테스트 시나리오, 아키텍처 및 사용자 이야기로의 영향을 적용합니다. 모든 의존성을 투명하게 문서화하고 관련 요구 사항에 대한 변경 사항을 이해 관계자에게 알리는 것이 필요합니다.
주요 특징:
요구 사항에서 의존성을 명시하지 않으면 어떻게 됩니까?
답변: 중요한 관계를 놓칠 수 있으며(예: 한 요구 사항은 다른 요구 사항 없이 구현할 수 없음), 차단자가 발생하고, 고객 불만이 제기되며, 테스트에 추가적인 부담이 발생할 수 있습니다.
시작할 때 의존성 맵을 한 번만 수집하는 것으로 충분합니까?
답변: 아닙니다. 의존성 맵은 프로젝트 전체 생애주기 동안 현재 상태로 유지되어야 합니다. 어떤 요구 사항의 변경도 모든 관련 요구 사항에 영향을 미칠 수 있습니다.
의존성이 단순히 직선적일 수 있습니까 (A는 B에 의존)?
답변: 아닙니다. 실제 시스템에서는 종종 교차적, 순환적 및 트랜잭션 의존성과 함께 공통 자원이나 통합을 통한 영향을 나타냅니다.
부정적 사례: 전자 상거래 프로젝트에서 다양한 결제 채널 간의 의존성을 반영하지 않았습니다. 하나의 모듈이 변경되었을 때 오류가 발생하여 일부 주문이 처리되지 않았습니다.
장점:
단점:
긍정적 사례: 각 비즈니스 요구 사항에 대해 관련 기술 요구 사항을 문서화하고 추적 매트릭스를 작성했습니다. 변경 사항 발생 시 자동으로 모든 이해 관계자에게 알림이 전송되었습니다.
장점:
단점: