콘텐츠로 이동

요구사항과 추적성

요구사항은 만들려는 기능의 의도입니다. 추적성은 그 의도가 어떤 화면·데이터·API·검증 항목으로 이어지는지 확인하는 방법입니다.

  1. 프로젝트의 요구사항 모델을 열고 문서 보기를 확인합니다.
  2. 요구사항 추가 또는 첫 요구사항 추가를 선택합니다.
  3. 제목과 본문을 작성합니다. 유형·우선순위·근거·선행조건·입출력 같은 선택 항목을 보완하려면 부가정보를 펼칩니다.
  4. 부가정보 안의 인수 조건에는 성공과 거절을 어떻게 판단할지 한 줄씩 작성합니다. 이번 예시에서 내용을 보완하는 단계이며 초안을 저장하기 위한 필수 입력은 아닙니다.
  5. 초안 저장을 선택하고 문서에서 다시 읽습니다. 작성 중에는 선택 항목을 모두 채울 필요가 없습니다.

설명 예시:

입력 항목 예시
제목 배송 전 주문 취소
본문 사용자는 자신의 주문이 배송되기 전에 취소를 요청할 수 있다.
선행조건 로그인했고 해당 주문의 구매자다.
입력·출력 주문 식별자·취소 사유 → 취소 결과·주문 상태
인수 조건 배송 전 본인 주문의 취소는 성공한다. 다른 사람의 주문과 배송이 시작된 주문은 거절한다.

“취소 버튼을 만든다”만 적으면 권한과 상태 조건이 빠집니다. 관찰 가능한 결과까지 적어 두면 설계·검사를 연결하기 쉽습니다.

왼쪽 목차에서 항목을 찾고 가운데 본문을 읽습니다. 항목을 선택하면 오른쪽에서 상세 정보와 연결 자원을 확인할 수 있습니다. 편집은 수정 액션이나 편집 팝업에서 진행합니다.

상단의 추적성 보기로 전환하면 커버리지, 직접 연결·목차 범위·변경 영향·사용자 보기 등을 목적에 맞게 살펴볼 수 있습니다. 사용자 보기의 배치는 원본 요구사항 문서 구조와 구분됩니다.

화면이나 API 편집기의 요구사항 연결 액션에서 대상을 선택합니다. 이름이 비슷한 항목 대신 실제 의도에 맞는 대상을 확인하세요. 연결 위치는 모델 종류에 따라 다릅니다.

주문 취소 예시에서는 다음 연결을 검토합니다. 이름은 설명용이며 실제 프로젝트에서 사용자가 정합니다.

요구사항에서 확인할 대상 검토할 질문
주문 상세 화면·취소 버튼 어떤 상태에서 어떤 동작을 하는가?
주문 테이블·상태 컬럼·사전 상태를 어디에 저장하고 어떤 값으로 구분하는가?
취소 API·처리 소스 본인 주문과 배송 상태를 어디서 검사하는가?
정상·권한 거절·상태 거절 검증 항목 인수 조건에 맞는 입력과 결과가 있는가?

커버리지에서 연결이 없는 요구사항을 찾습니다. 필요하면 편집의 추적 목표 단계를 조정해 필요한 단계만 지정합니다. 연결이 있다는 사실만으로 구현이나 검사가 성공한 것은 아닙니다.

프로젝트의 통합 추적성 및 변경 영향에서 자원을 검색하고 선택합니다. 영향 범위, 업무 관점과 관계 출처를 바꿔 직접 연결과 연쇄 영향을 확인합니다.

주문 상태의 의미를 바꿨다면 요구사항·취소 API·화면·검증 항목을 함께 살펴봅니다. 변경 후 검토의 상태·담당자·검토 메모에 판단을 남기고 필요한 출력이나 검사를 다시 수행합니다.

화면의 최대 표시 수나 영향 단계는 전체 데이터 수와 다를 수 있습니다. 필터에 보이는 일부 관계만 보고 영향이 없다고 결론 내리지 마세요.

모델의 Revision은 변경과 검사 시점을 구분하기 위한 값입니다. 그래프 Revision은 추적 관계를 확인한 시점을 이해하는 데 쓰며, SaaS 프로젝트의 판은 저장 대상이 검토 이후 바뀌었는지 확인하는 데 쓰입니다.

Revision 값이 올라갔다고 요구사항이 승인됐거나 모든 검사가 성공한 것은 아닙니다. 내용을 변경한 뒤에는 관련 자원과 검토 항목을 다시 확인하세요.

문서 전달은 내보내기에서 확인할 수 있습니다.