답변.

역사적으로 요구사항 수집 접근 방식은 선형으로 간주되었습니다: 분석가는 다양한 이해관계자와 소통하고, 요구사항 목록을 작성한 후 사양서로 정리했습니다. 사실 프로젝트가 클수록 서로 다른 이해관계자 그룹 간의 요구사항에서 교차점, 중복 및 정반대 과제를 파악하고 추적하는 것이 훨씬 더 어려워집니다.

문제

대규모 시스템에서 자주 발생하는 문제는:

• 다른 부서 간 요구사항 간의 모순(예: 보안 vs 편리함);
• 중복 및 겹침(다른 팀이 서로 다른 방식으로 동일한 것을 원함);
• 숨겨진 의존성(하나의 변경이 다른 변경을 초래함).

분석 단계에서의 오류는 구현 시 충돌을 초래하고, 일정 지연, 작동하지 않는 메커니즘 또는 모듈 통합 불가능성으로 이어질 수 있습니다.

해결책

전문 시스템 분석가는 다음과 같은 기법을 사용해야 합니다:

• 의존성 매트릭스(예: "requirement-traceability-matrix") 및 모델(UML 다이어그램, ER 다이어그램) 작성;
• 이해관계자의 서로 다른 그룹 간의 작업 회의 및 리뷰 진행;
• 요구사항 충돌 해결 기법(예: 촉진 세션) 사용;
• 요구사항 간의 상관관계를 각 단계에서 볼 수 있도록 하는 트레이스 가능성 도구 구현(예: API 요구사항 및 동일 작업에 대한 보안 요구사항);
• 요구사항의 정기적인 업데이트 및 우선순위 지정.

핵심 특성:

• 복잡한 프로젝트에는 매트릭스와 다이어그램이 필수입니다.
• 충돌 해결은 분석가의 책임입니다.
• 숨겨진 의존성은 모델링과 커뮤니케이션을 통해 밝혀집니다.

함정 질문.

요구사항의 우선순위 지정이 모순 해결의 방법인가요?

아니요, 우선순위 지정은 구현 순서의 설정입니다. 모순은 백로그에 추가되기 전에 합의, 타협 또는 요구사항 검토를 통해 해결되어야 합니다.

자동화 도구만으로 모든 상관관계를 식별할 수 있나요?

아니요, 자동화(예: 트레이스 가능성 도구)는 도움이 되지만, 내재된 비즈니스 의미, 프로세스의 미세한 차이 및 숨겨진 충돌은 실제 이해관계자와의 논의를 통해서만 파악됩니다.

요구사항의 교차가 반드시 하나의 요구사항이 불필요하다는 것을 의미하나요?

아니요, 요구사항은 표현이 겹칠 수 있지만 서로 다른 최종 목표를 가질 수 있습니다. 의미를 확인하고 집합 또는 설명의 기회를 찾아야 합니다.

일반적인 실수 및 안티 패턴

• 모순된 요구사항의 급격한 통합(하나를 제거하면 비즈니스 시나리오가 깨짐).
• 연결 고리를 기록하지 않음 — 수정 중에 기존 요구사항이 "실종"되고 손상됨.
• 활성 커뮤니케이션 없이 문서화에만 의존함.

사례

부정적인 케이스: 은행 CRM에서 두 부서가 독립적으로 "신속한 고객 검색"을 요청했습니다. 요구사항이 별도로 구현되어 중복을 식별하지 못하여 두 가지의 서로 다른 검색과 복잡한 시나리오가 발생했습니다.

장점:

• 각 부서의 요구 만족

단점:

• 인터페이스의 비일관성
• 지원 비용 증가
• 프로젝트 비용 증가

긍정적인 케이스: 분석가는 주요 요구사항의 워크샵을 조직하고, 의존성 매트릭스를 작성하며, 고객 및 수행자와 시나리오를 반복적으로 조율했습니다.

장점:

• 버그 수 감소
• 예측 가능한 결과
• 크로스 기능적 시나리오

단점:

• 더 복잡하고 긴 분석 단계
• 촉진 기술이 필요함