설명한 요구사항은 사용자, 업무, 자료, 상태와 관계를 기준으로 정리합니다. 업체가 문장을 옮기는 데 그치지 않고 조건과 미정 항목을 구분하는지 확인합니다.
초기 요구의 예시
일반회원과 파트너의 이용일반회원의 예약 신청파트너의 예약 수락확정 상태의 알림예약 조건에 따른 결제예약
예약 예시에서는 역할별 권한과 처리 단계, 결제와 알림의 연결을 정리할 수 있습니다. 항목 간 관계를 확인하면 누락과 모순을 검토하기 쉽습니다.
권한과 처리 조건이 미정이면 구현 중 변경이 필요할 수 있습니다. 결정할 항목과 담당자, 시점을 기록합니다.
업무와 자료의 관계를 문서로 남기면 변경과 인계의 기준으로 활용할 수 있습니다. 정리된 구조도 실제 구현과 함께 검토해야 합니다.
검토 결과의 확인업체가 정리한 결과는 요구를 다시 분류했는지뿐 아니라 관계와 조건이 정확한지, 미정 항목과 근거가 표시되었는지로 확인합니다.
요구 목록과 관계도의 상호 보완
요구 목록과 관계도는 서로 보완합니다. 목록은 개별 요구를, 관계도는 연결과 처리 순서를 확인하는 데 사용합니다.
예약의 신청, 수락, 확정, 완료를 정리했다면 취소, 변경, 기한 초과의 조건을 함께 확인합니다. 각 상태에서 가능한 행동을 구분합니다.
일반회원, 파트너, 관리자가 조회하고 변경할 수 있는 자료를 정합니다. 다른 사용자의 정보 접근과 예외 권한도 확인합니다.
정리의 목적은 중요한 조건을 일찍 확인하고 미정 사항을 관리하는 데 있습니다. 모든 누락을 사전에 없앨 수 있다고 가정하지 않습니다.
역할, 상태와 작업량의 산정
역할과 상태, 자료의 관계는 개발과 시험의 범위, 견적을 산정하는 근거가 됩니다.
역할이 세 종류라고 화면이 반드시 세 개가 되는 것은 아닙니다. 공통 화면과 역할별 표시, 행동의 차이를 확인합니다.
상태 변화마다 알림이 필요한지도 별도로 결정합니다. 대상과 채널, 발송 조건과 중복, 실패 처리를 산정합니다.
요구가 구체화되면 견적을 보완할 수 있습니다. 금액은 범위와 방식에 따라 오르거나 줄어들 수 있으므로 변경 근거를 확인합니다.
정상, 예외 상태의 처리 기준
정상 처리뿐 아니라 실패와 취소, 중간 상태를 확인합니다.
예약의 변경, 기한 초과, 미방문, 환불을 검토하고 업무별 필요성을 결정합니다. 모든 상태에 별도의 화면이나 알림이 필요한 것은 아닙니다.
각 단계에서 실패했을 때의 안내와 재시도, 담당자 처리를 질문합니다. 나중에 결정할 항목은 이유와 시점, 영향 범위를 기록합니다.
역할과 업무 흐름의 설계 사례
역할별 행동, 자료 접근, 처리 순서, 전달 정보
흐름소프트 사례
흐름소프트의 비대면 진료 플랫폼 사례에서는 환자와 의사, 약사와 병원 관리자 등 역할별 업무를 정리했습니다.
역할별 행동과 자료 접근, 처리 순서와 전달 정보를 확인하고 설계 문서로 정리했습니다. 정리한 문서는 개발 방향과 확인 항목을 공유하는 기준으로 사용했습니다.
사례 보기프로젝트의 구성을 다른 서비스의 표준으로 단정하지 않습니다. 구현 중 바뀐 조건도 함께 관리해야 합니다.
기획 기간은 업무의 복잡도와 기존 자료, 조사와 결정 범위에 따라 검토합니다. 기간이 길거나 짧다는 사실만으로 충분성을 판단하지 않습니다.
사용자, 자료, 단계의 초기 정리
초기 자료는 사용자와 업무 자료, 처리 단계의 세 항목부터 정리할 수 있습니다.
자료를 바탕으로 업체에 누락, 모순과 구현 조건을 검토해 달라고 요청합니다. 미정 내용은 기획 과정에서 함께 보완합니다.
여러 업체에 같은 자료를 전달하면 제안을 비교하기 쉽습니다. 제기된 항목은 실제 필요성과 근거를 검토한 뒤 반영합니다.
정리 결과의 용어, 상태, 범위 확인
정리 결과에는 용어와 상태, 초기 범위의 기준이 명확해야 합니다.
업무 용어의 뜻을 확인하고 확인 사실, 가정, 미정 사항을 구분합니다. 모든 칸이 채워졌다는 이유만으로 추정으로 작성했다고 판단하지 않습니다.
초기 기능과 후속 기능을 구분하고 각각의 필요성과 의존 관계를 확인합니다. 범위에서 제외한 항목의 운영 방법도 정합니다.
합의한 문서는 적용 버전과 범위, 우선순위를 표시해 계약 자료로 활용할 수 있습니다. 변경과 미정 항목의 처리 절차도 함께 정합니다.
기존 설계의 적용과 조정
정리된 문서가 실제 업무에 적합한지 검토해야 합니다.
기존 양식과 설계를 활용하면 정리에 도움이 될 수 있습니다. 적용할 수 있는 부분과 조정할 부분을 구분합니다.
기존 설계와 다른 업무 조건을 확인하고 구현 대안과 운영 영향을 비교합니다. 사업에 불필요한 기능도 제외합니다.
제안한 구조와 실제 업무의 공통점과 차이를 설명받습니다. 특이한 조건이 없다는 답변도 근거와 확인 범위로 검토합니다.
비용과 제약, 자료와 운영의 연결 조건까지 비교
담당자 변경과 문서의 갱신
정리 문서는 담당자 변경과 후속 개발의 참고 자료가 됩니다.
새 담당자가 기존 결정과 미정 조건을 확인할 수 있도록 문서와 변경 기록을 전달합니다. 설명과 실제 구현도 함께 대조합니다.
발주자와 개발, 운영 담당자가 같은 기준을 사용하도록 문서의 위치와 접근 권한, 관리 책임을 정합니다.
필요한 문서와 제출 시점, 변경 시 갱신 범위를 결과물 목록에 포함합니다. 실제 구현과 일치하는 최종본도 확인합니다.
기관과 기업 과업과 설계의 연결
기관과 기업의 과업은 요구사항 번호와 설계 항목의 연결을 확인하는 것이 중요합니다.
제안서에서 업무별 묶음과 관계, 수행 순서를 검토합니다. 원래 요구사항이 빠지거나 다른 의미로 바뀌지 않았는지 대조합니다.
누락과 모호한 조건에 대한 질문과 제안 근거를 확인합니다. 재분류했다는 사실만으로 이해도나 수행력을 단정하지 않습니다.
권한과 상태 흐름이 필요한 과업이면 해당 자료를 함께 제공할 수 있습니다. 역할별 확인과 미정 사항의 결정 절차를 정합니다.
자주 묻는 질문
01요구사항은 어떤 기준으로 정리합니까
사용자, 업무, 자료, 상태와 관계를 기준으로 정리합니다. 예약 서비스라면 일반회원, 파트너, 관리자의 역할과 신청, 수락, 확정, 완료 상태, 결제와 알림의 연결, 역할별 권한을 정리합니다.
02예약 상태는 정상 처리만 정리하면 됩니까
취소, 변경, 기한 초과, 미방문, 환불의 조건도 함께 확인합니다. 각 단계에서 실패했을 때의 안내와 재시도, 담당자 처리를 정하며 모든 상태에 별도의 화면이나 알림이 필요한 것은 아닙니다.
03사용자 역할이 세 종류이면 화면도 세 개가 필요합니까
역할이 세 종류라고 화면이 반드시 세 개가 되는 것은 아닙니다. 공통 화면과 역할별 표시, 행동의 차이를 확인해 개발과 시험 범위를 산정합니다.
04업체에 처음 전달할 자료는 무엇입니까
사용자와 권한, 업무 자료, 처리 단계의 세 항목부터 정리할 수 있습니다. 이 자료로 업체에 누락과 모순, 구현 조건의 검토를 요청하며 여러 업체에 같은 자료를 전달하면 제안을 비교하기 쉽습니다.
05요구사항이 구체화되면 견적이 달라집니까
요구가 구체화되면 견적을 보완할 수 있습니다. 금액은 범위와 방식에 따라 오르거나 줄어들 수 있으므로 변경 근거를 확인합니다.