시스템 분석의 역사에서 가장 어려운 작업 중 하나는 불분명하거나 모호하거나 숨겨진 요구 사항을 식별하고 형식화하는 것입니다. 종종 고객은 자신이 정확히 무엇이 필요한지 명확히 설명할 수 없거나, 진정한 기대를 드러내지 않으면서 용어를 사용합니다.
형식화되지 않은 요구 사항 문제는 첫 번째 구현 프로젝트 시기부터 알려져 왔습니다. 처음에는 간단한 인터뷰를 사용했지만, 지금은 사용자 스토리 매핑, 프로토타이핑, 촉진 또한 사용합니다.
암묵적인 요구 사항은 잘못된 작업 지시에, 불필요한 노력과 당사자 간의 갈등을 초래합니다.
인터뷰 기술, 시각화(프로세스 맵, 프로토타입), 촉진 및 결과의 명확한 문서화를 사용하세요. 요구 사항 기록의 각 단계 후 피드백을 검토하세요.
프로젝트 시작 전에 모든 요구 사항을 사전 형식화할 수 있나요?
아니요, 많은 요구 사항은 프로토타이핑 및 프로젝트 구체화 과정에서 명확히 되고 밝혀집니다.
고객이 분명히 제시한 바람만 기록해야 하나요?
아니요, 분석가는 암묵적인 기대와 비즈니스 목표를 분석하고 숨겨진 필요를 식별해야 합니다.
시스템 분석가의 임무는 요구 사항을 기술 문서로 번역하는 것뿐인가요?
아니요, 분석가는 요구 사항의 형식화, 조율 및 구체화, 그리고 모순의 식별에 대해서도 책임이 있습니다.
부정적인 사례:
분석가는 고객이 말한 모든 것을 프로젝트에 기록했으나 세부 사항을 확인하지 않았습니다.
장점: 개발이 빠르게 시작되어 분석 시간 절약.
단점: 잘못된 기대 때문에 고객과의 갈등 및 변경 작업이 많음.
긍정적인 사례:
분석가는 프로토타입을 만들고 уточняющие 세션을 진행하며 고객과 함께 암묵적인 요구 사항을 기록했습니다.
장점: 요구 사항의 높은 정확성, 만족한 고객, 갈등 감소.
단점: 촉진 및 피드백 수집 비용.