요구사항 문장 패턴

주체·조건·행동·결과가 분명한 요구사항 문장을 작성하고 검토하는 데 쓸 수 있는 패턴과 점검 카드를 제공한다.

권장 사용 순서

도구 본문

이 부록은 15장과 17장을 읽은 뒤 요구 초안을 작성하거나 동료 검토할 때 사용한다. 패턴은 생각을 대신하는 자동 문장 생성기가 아니다. 실제 주체·조건·대상·결과·근거·측정 환경을 확인한 뒤 필요한 칸만 사용하고, 서로 독립적으로 변경·검증할 의무는 별도 요구로 나눈다.

기본 조립 순서

[조건 또는 사건]에서
[책임 주체]는
[대상]에 대해
[관찰 가능한 반응 또는 결과]를
[필요한 제약·측정]에 따라 제공해야 한다.

모든 문장에 다섯 요소를 억지로 넣지 않는다. 항상 적용되는 요구라면 조건을 생략할 수 있고, 측정값은 품질 요구나 수용 조건으로 분리할 수 있다. 그러나 누가 무엇을 언제 어떻게 반응하는지 해석이 갈린다면 빈칸을 숨기지 않는다.

일반형과 조건형

일반형

[주체]는 [대상]에 대해 [관찰 가능한 결과]를 제공해야 한다.

나쁜 예: “시스템은 수강신청을 지원해야 한다.” 무엇을 접수·판정·조회하는지와 완료가 무엇을 뜻하는지 알 수 없다.

개선 예: “인증된 학생은 자신의 신청 ID로 현재 판정 상태, 공개 가능한 사유, 마지막 갱신 시각과 가능한 다음 행동을 조회할 수 있어야 한다.” 이 문장은 FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다.의 사용자 관찰 결과를 표현한다.

검토 질문: 주체의 권한 범위가 보이는가, 결과가 외부에서 관찰되는가, 다른 학생의 정보가 포함되지 않는가?

조건형

[조건]이면 [주체]는 [대상]에 대해 [반응]해야 한다.

나쁜 예: “오류가 나면 적절히 처리한다.” 오류 종류와 안전 결과가 없다.

개선 예: “규칙 서비스가 실패하거나 응답이 무효이거나 시간 초과이면 시스템은 신청을 자동 승인하지 않고 원인 코드가 있는 처리 보류로 기록하며 재평가할 수 있어야 한다.” IR-001IR-001 · 인터페이스 요구자격·운영 흐름.은 실패 종류와 금지 결과뿐 아니라 후속 처리 방법도 함께 명시한다.

검토 질문: 조건이 판단 가능한가, 조건이 끝나면 어떤 상태가 되는가, 예외가 정상 결과를 우회하지 않는가?

사건·상태 기반 패턴

사건 기반

[사건]이 발생하면 [주체]는 [시간·순서 제약] 안에서 [반응]해야 한다.

예: “동일 신청 의도의 요청을 다시 수신하면 시스템은 새로운 승인 결과나 좌석 변동을 만들지 않고 기존 신청 ID와 현재 상태에 연결해야 한다.” 이 문장은 FR-004FR-004 · 기능 요구같은 신청 의도를 다시 보내도 복수 승인이나 좌석 변동을 만들지 않고 기존 신청 상태에 연결한다는 기능 요구다.의 중복 안전 의도다. 동일성 키와 보존 기간은 별도 결정이 필요하다.

상태 기반

[대상]이 [현재 상태]일 때 [행위자]가 [행동]하면 [다음 상태·결과]가 되어야 한다.

예: “자신의 신청이 정책상 취소 가능한 상태일 때 인증된 학생이 취소를 요청하면 시스템은 취소 결과와 정원·상태 후속 변화를 일관되게 기록해야 한다.” FR-005FR-005 · 기능 요구신청·판정 이력.의 허용 상태·기간은 정책 확인 전 빈칸으로 남긴다.

상태 기반 문장은 상태 이름만 나열하지 않는다. 촉발, 권한, 전이 결과, 늦은 응답과 금지 전이를 상태 모델·수용 조건에서 보완한다.

금지·불변조건 패턴

[조건]에서도 [주체]는 [금지 결과]를 만들어서는 안 된다.

예:

• 규칙 서비스 실패·무효·시간 초과에서도 시스템은 신청을 자동 승인해서는 안 된다.
• 동일 신청 의도의 재전송은 여러 승인 결과나 좌석 변동을 만들어서는 안 된다.
• 늦은 판정 응답은 더 새로운 취소 또는 최종 상태를 덮어써서는 안 된다.
• 인증된 학생은 다른 학생의 신청 상태와 비공개 사유를 조회할 수 없어야 한다.

금지 요구만으로 정상 반응이 사라지지 않게 한다. “자동 승인 금지”와 함께 원인 코드가 있는 처리 보류·재평가·조회라는 안전 결과를 IR-001IR-001 · 인터페이스 요구자격·운영 흐름.에 둔다.

예외·대체 흐름 패턴

[기본 흐름의 단계]에서 [예외 조건]이 발생하면
[주체]는 [보존할 상태·데이터]를 유지하고
[안전한 결과·다음 행동]을 제공해야 한다.

예: “신청이 접수된 뒤 응답이 유실되면 시스템은 요청 ID와 신청 ID의 관계를 보존하고, 같은 요청의 재전송 또는 상태 조회가 기존 신청 결과에 연결되게 해야 한다.”

검토 질문: 예외 전후의 공식 상태가 무엇인가, 사용자가 다시 시작해야 하는가, 재시도가 중복 결과를 만드는가, 운영자가 원인을 구별할 수 있는가?

품질 시나리오 패턴

품질 요구는 이름과 수치만 적지 않고 원천, 자극, 환경, 대상, 반응과 측정을 묶는다.

[환경]에서 [자극 원천]이 [자극]하면
[대상]은 [반응]하고
[측정 방법·범위]에서 [목표]를 만족해야 한다.

QR-001QR-001 · 품질 요구합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다. 적용 예:

합의된 피크 부하 시험 환경에서 인증된 학생이 자신의 신청 상태를 조회하면 상태 조회 경로는 본인 상태·공개 사유·마지막 갱신 시각을 반환하고, 합의된 측정 경계에서 응답시간 p95가 후보값인 2초 이하여야 한다.

이 문장도 아직 수용 기준은 아니다. 동시 사용자, 요청률·혼합, 데이터량, 네트워크 위치, 캐시 상태, 워밍업, 표본 수, 오류와 신선도 기준이 DEF-003DEF-003 · 미정의 항목부하·표본·측정 구간 미정.으로 열려 있다. 환경 없는 “2초 이내”를 모든 신청 처리에 확대하지 않는다.

IR-001IR-001 · 인터페이스 요구자격·운영 흐름.·QR-010QR-010 · 품질 요구정의된 장애에서 안전 상태를 보존하고 합의된 목표 안에 재평가·복구·대사할 수 있어야 한다 적용 예:

신청 판정 중 규칙 서비스가 합의된 시간 제한을 넘으면 판정 경로는 자동 승인 없이 원인 코드가 있는 처리 보류를 기록하고, 신청 ID로 상태 조회와 재평가를 추적할 수 있어야 한다.

검토 질문: 품질 목표를 달성하는 과정에서 보안·정합성·신선도를 희생하지 않는가, 측정 위치와 산식이 재현 가능한가, 후보값과 승인값이 구분되는가?

데이터·인터페이스 패턴

데이터 요구

[업무 목적]을 위해 [주체]는 [데이터 항목·관계]를 [무결성·생명주기 제약]에 따라 유지해야 한다.

예: “판정 재현과 감사 목적을 위해 시스템은 학생·강좌 ID, 요청 시각, 결과, 사유, 규칙 버전과 최종 상태 변경을 판정 기록으로 연결해야 한다.” 규칙 버전을 제공할 수 있는지는 ASM-002ASM-002 · 가정규칙 버전 제공 여부 미확인.에서 확인해야 한다.

인터페이스 요구

[제공자]와 [소비자]는 [목적]을 위해 [정보·의미]를 교환하고,
[오류·시간·중복·버전 조건]에서 [안전 결과]를 지켜야 한다.

예: “규칙 연계는 판정 요청 ID, 결과·사유와 규칙 버전을 연결하고, 실패·무효·시간 초과 응답을 승인으로 해석하지 않아야 한다.” 프로토콜·제품은 근거가 생긴 뒤 설계에서 선택한다.

수용 조건 패턴

Given [초기 상태·공식 입력]
When  [행위·사건]
Then  [관찰 결과·금지 결과·증거]

Given-When-Then은 문장 형식이지 품질 보증이 아니다. 공식 입력, 동시성, 접근 제어, 오류·복구 환경과 증거 위치가 없으면 실제 시험 오라클이 되지 않는다.

문장 리뷰 카드

패턴을 적용한 뒤에는 문장만 읽지 말고 유스케이스, 상태 모델, 결정표, 화면·API·데이터와 시험 항목을 함께 읽는다. 문장이 짧고 문법적으로 완전해도 다른 산출물과 결과 의미가 다르면 좋은 요구가 아니다.

관련 학습

이 도구를 사용하는 가이드