요구사항을 구체화할 때 사용자 목적과 판정 조건을 함께 보존한다

요구사항을 구체화할 때는 누가 어떤 상황에서 얻으려는 결과를 보존하면서, 충족 여부를 관찰할 수 있는 조건을 정한다. 숫자나 기술 이름이 붙었다고 좋은 요구사항이 되는 것은 아니다. 상세 조건을 모두 통과해도 원래 목적을 해결하지 못한다면 구체화 과정에서 목표가 바뀌었을 수 있다.

목적에서 판정 조건으로

사용자의 발언, 그 배경에 대한 해석, 제안한 요구사항을 구별한다. 수집한 발언을 바로 확정 계약으로 올리기보다 실제 업무·제약을 확인하고, 어떤 요구에서 상세 조건을 도출했는지 설명할 수 있게 한다.

예를 들어 작성자가 만든 ‘주문 단계를 줄인다’와 ‘배송 상태를 빨리 보여 준다’는 서로 다른 개선이다. 둘 다 속도와 관련돼 보여도 한쪽의 기준을 다른 쪽의 수용 조건으로 대신할 수 없다.

성능 조건이 필요하면 측정 대상과 시작·종료 지점, 적용 부하·환경, 집계 방식, 허용값을 함께 정한다. 평균과 최댓값은 같은 기준이 아니다. 미정인 값은 제안이나 결정 필요로 표시하고, 예시 숫자를 합의된 기준처럼 넣지 않는다. 모든 요구사항에 수치를 강제할 필요는 없으며, 관찰 가능한 행동·상태·금지된 부작용으로도 조건을 정의할 수 있다.

해석의 범위

이 원칙은 제품 요구사항의 도출과 수용 조건에 적용한다. 취향·성찰·개념 설명을 모두 이진 체크리스트로 바꾸자는 뜻은 아니다. 기술 선택이 이미 외부 제약이나 채택된 결정이라면 그 근거를 함께 보존한다.

• 소프트웨어 분석설계 - WikiDocs: 모호한 요구의 구체화와 목적이 바뀌는 예시를 대조한 증류.
• NASA, How to Write a Good Requirement: 필요성·근거·가정·검증 가능성 점검. 위 주문 사례와 측정 항목의 묶음은 이를 적용한 Codex의 설명이다.
• 현행 업무 분석에는 예외와 임시 처리까지 포함한다
• 요구사항의 변경 영향은 설계·구현·검증 연결로 추적한다
• 요구사항에서 검증까지