17장. 자연어 요구사항 명세

자연어 문장 패턴과 금지 요구를 사용해 정상 동작뿐 아니라 해서는 안 되는 결과와 실패 경계를 표현한다.

이번 장에서 해결할 질문

학습 목표

• “자연어의 장점을 살리면서 모호성과 과도한 설계 지정을 어떻게 줄이는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
• 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.

핵심 개념

자연어는 이해하기 쉽지만 조건과 예외가 늘어날수록 구조가 흐려진다. 특히 시스템이 해야 할 일만 쓰고 해서는 안 되는 결과나 실패 시 경계를 쓰지 않으면, 구현자는 금지된 동작을 요구 밖의 문제로 여길 수 있다. 표현 패턴은 사고를 대신하지 않지만 빠진 요소를 보이게 한다.

이 장에서는 조건·사건·상태·선택 기능에 맞는 자연어 요구 패턴과 금지 요구를 사용한다. 수강신청 사례의 정상 동작과 오류·중복·권한 경계를 구조화된 문장으로 바꾸고, 패턴을 기계적으로 적용할 때 생기는 과도한 설계 제약도 함께 살펴본다.

1. 자연어의 장점과 한계

요구사항을 쓰는 목적은 문서를 아름답게 만드는 데 있지 않다. 이해관계자와 개발·시험·운영 담당자가 같은 필요와 의무를 이해하고, 구현 결과가 그 의무를 충족하는지 판정하게 만드는 데 있다. 자연어는 이 목적에 가장 널리 쓰이는 표현 수단이다. 별도 표기법을 배우지 않아도 읽을 수 있고, 정책·업무 맥락·예외처럼 수식만으로는 다루기 어려운 의미를 설명할 수 있으며, 회의와 검토에서 바로 고칠 수 있다. 수강신청 담당자에게 상태 기계부터 보여 주는 것보다 “규칙을 판정할 수 없으면 자동 승인하지 않는다”라고 말하는 편이 먼저 대화를 열기 쉽다.

그러나 익숙하다는 사실은 정확하다는 뜻이 아니다. 자연어는 같은 단어가 여러 의미를 갖고, 주어와 조건을 생략해도 문장처럼 읽히며, 앞 문장의 전제를 뒤 문장에 암묵적으로 물려준다. “신청이 완료되면 즉시 결과를 안내한다”는 말에서 완료가 접수인지 판정인지, 즉시가 몇 초인지, 안내 실패가 신청 결과까지 되돌리는지 알 수 없다. 작성자는 알고 있는 맥락을 독자도 안다고 착각하기 쉽고, 독자는 각자의 업무 경험으로 빈칸을 채운다.

자연어의 한계 때문에 모든 요구를 다이어그램이나 형식 언어로 바꾸는 것도 해답은 아니다. 다른 표기로 옮기는 순간에도 해석과 누락이 발생하며, 모델에는 모델이 잘 보여 주지 못하는 정보가 있다. 상태 모델은 허용 전이를 잘 드러내지만 성능 목표의 근거까지 말해 주지 않는다. 결정표는 규칙 조합을 점검하기 좋지만 사용자가 왜 그 결과를 필요로 하는지 설명하기 어렵다. 이 부에서는 표현 형식을 경쟁시키지 않고 역할에 맞춰 결합한다.

이 장의 사례 문장은 모두 작성 후보다. RULE-001–RULE-005RULE-001–RULE-005RULE-001: 신청자가 적용되는 선수과목의 동시 이수·대체·면제·성적 시점 조건을 충족해야 한다는 업무 규칙 후보다. · RULE-002: 승인으로 계산되는 학점 합계가 학생에게 적용되는 최대 신청 학점을 넘지 않아야 한다는 업무 규칙 후보다. · RULE-003: 시간 충돌 판정. · RULE-004: 분반의 승인된 수강 등록 수가 적용되는 정원을 넘지 않아야 한다는 업무 규칙이다. · RULE-005: 우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다.의 권한 있는 출처와 예외, ASM-003ASM-003 · 가정처리 보류가 좌석을 점유하는가?의 보류 좌석 점유 정책, ISS-001ISS-001 · 미결 쟁점우선 배정 조건과 정원 초과 금지가 충돌할 때 마지막 좌석의 승자를 어떻게 정할지 남아 있는 정책 쟁점이다.의 정원과 우선순위 충돌이 확인되기 전에는 승인 요구가 아니다. 문장 패턴은 빠진 성분과 섞인 사건을 보이게 할 뿐, 사실을 만들어 내거나 정책 결정을 대신하지 않는다.

자연어를 선택하기 좋은 상황과 보완 수단을 먼저 구분한다.

좋은 선택은 “자연어인가 모델인가”가 아니라 “어떤 질문에 어느 표현이 가장 적합하며, 서로 어떻게 추적할 것인가”다.

2. 요구사항 문장 패턴

15장15장. 좋은 요구사항을 작성하는 법한 문장을 구현·시험·검토할 수 있는 요구사항으로 어떻게 작성하는가?페이지로 이동의 기본 구조는 다음과 같았다.

[조건] + 주체 + 의무 수준 + 동작 + 대상/결과 + [제약·측정 기준]

여기에 상황에 따른 조건의 종류를 붙이면 문장을 더 일관되게 만들 수 있다. EARSEARS조건과 사건에 따라 자연어 요구 문장을 일정한 패턴으로 작성하는 표기 접근법이다.(Easy Approach to Requirements Syntax)는 무제약 자연어의 흔한 결함을 줄이기 위해 요구를 몇 가지 조건 패턴으로 표현한다. 2009년 원 논문은 다섯 패턴을 제시했고, INCOSE Guide to Writing Requirements는 조건절·주체·동작·측정 가능한 결과를 갖는 확장 구조와 함께 사건·상태·원하지 않는 상황 등의 조건을 소개한다. 이 책에서는 한국어 어순과 프로젝트 용어에 맞게 다음처럼 사용한다.

패턴을 고르는 순서는 단어를 채우는 순서가 아니다. 먼저 업무 사실을 확인하고, 의무가 항상 적용되는지 특정 기능·상태·사건·실패에만 적용되는지 묻는다. 그런 다음 책임 주체와 관찰 가능한 결과를 적는다. 조건이 두세 겹으로 늘거나 결과가 갈라지면 문장을 억지로 완성하지 말고 여러 원자 요구, 유스케이스 분기 또는 결정표로 옮긴다.

같은 수강신청 흐름을 패턴별로 정리하면 다음과 같다.

문장 패턴은 문서의 표면을 통일하지만, 모든 문장을 같은 길이나 리듬으로 만들 필요는 없다. 공통 정의·조건을 외부 참조로 둘 수 있고, 수치의 측정 방법은 별도 속성이나 시험 개념에 연결할 수 있다. 중요한 것은 참조가 정확하고 독자가 필요한 정보를 찾을 수 있는가다.

3. 조건형 요구사항

조건형 요구사항은 의무가 적용되는 범위를 제한한다. 시간, 사용자 유형, 선택 기능, 객체 상태, 입력의 유효성, 정책 적용 범위가 조건이 될 수 있다. “조건을 만족하면”이라는 추상 표현 대신 어떤 사실이 성립해야 하는지 적는다.

수강신청 기간을 예로 들어 보자.

수강신청 기간에는 학생이 과목을 신청할 수 있어야 한다.

일상 대화로는 충분해 보이지만 시스템 의무로는 빈칸이 많다. 어느 달력과 시간대를 따르는지, 시작·종료 경계의 요청을 어떻게 판정하는지, 학생이 인증되어야 하는지, 강좌가 신청 가능한 상태여야 하는지, “할 수 있다”가 제출 버튼 노출인지 유효한 요청 접수인지 분명하지 않다.

정책을 확인하기 위한 후보는 다음처럼 나눌 수 있다.

• 본 신청 기간에 인증된 학생이 신청 가능한 강좌의 신청을 제출하면, 수강신청 시스템은 그 요청을 고유한 신청 식별자와 함께 접수해야 한다.
• 본 신청 기간 밖에 신청이 제출되면, 수강신청 시스템은 요청을 승인하지 않고 적용된 기간 사유를 제공해야 한다.
• 수강신청 기간의 시작·종료 시각 판정에는 학사 일정의 기준 시간대를 사용해야 한다.

첫 문장은 접수 의무이지 승인 의무가 아니다. 신청 가능 강좌의 정의와 기간의 권한 출처도 아직 붙여야 한다. 두 번째 문장은 기간 밖 요청의 결과를 분리하며, 세 번째는 시간대라는 공통 판정 기준을 명시한다. 이렇게 나누면 경계 시각 시험과 정책 검토가 가능해진다.

기능 선택 조건도 조건형이다. 예를 들어 대기명단이 이번 범위에 포함되는지 결정되지 않았다면 “대기명단이 있으면 자동 등록한다”라고 확정하지 않는다. 대기명단 기능이 승인된 범위에 포함되는 경우라는 조건을 붙이는 것만으로도 부족하다. 진입 기준, 순서, 좌석 점유, 알림 실패와 포기 기한이 결정되어야 한다. 범위 조건은 미결정 기능을 몰래 요구로 바꾸는 장치가 아니다.

조건 검토에서는 참·거짓 경계를 찾아야 한다.

조건이 늘어날수록 자연어만으로 조합을 관리하기 어렵다. 결과가 조건 조합마다 달라지면 20장20장. 모델로 표현하는 요구사항경계·상태·순서·데이터·결정의 질문에 맞는 모델을 어떻게 선택하는가?페이지로 이동의 결정표를 사용하고, 문장에는 결정표 참조와 결과 의무를 둔다.

4. 이벤트 기반 요구사항

이벤트 기반 요구사항은 특정 사건이 발생했을 때 시스템이 해야 할 반응을 표현한다. 이벤트는 사용자의 요청, 시각 도달, 외부 시스템의 메시지, 상태 변경, 운영자의 승인처럼 한 시점에 관찰할 수 있는 일이다. “–할 때”가 항상 이벤트인 것은 아니다. “신청 기간일 때”는 지속 상태이고, “신청 기간이 시작되면”은 상태 진입 사건이다.

정원이 변하는 사례를 보자.

자리가 나면 다음 학생을 처리한다.

자리, 다음, 처리가 모두 모호하다. 취소가 확정되어 가용 좌석 수가 증가한 사건인지, 대기명단이 있는지, 어떤 우선순위를 적용하는지, 처리 결과가 자동 승인인지 신청 기회 제공인지 알 수 없다. 현재 RULE-005RULE-005 · 업무 규칙우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다.와 ISS-001ISS-001 · 미결 쟁점우선 배정 조건과 정원 초과 금지가 충돌할 때 마지막 좌석의 승자를 어떻게 정할지 남아 있는 정책 쟁점이다.이 미결정이므로 임의의 정책을 넣지 않는다. 대신 사건과 필요한 결정을 드러내는 후보를 만든다.

• 승인된 신청의 취소가 확정되어 가용 좌석 수가 증가하면, 수강신청 시스템은 해당 강좌에 적용되는 후속 배정 규칙을 평가해야 한다.
• 후속 배정 결과가 확정되면, 수강신청 시스템은 대상 신청의 상태와 판정 근거를 DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다.에 기록해야 한다.

이 문장은 “다음 학생을 자동 승인한다”라고 결론 내리지 않는다. 후속 배정 규칙의 출처, 대상 집합, 동률 처리, 응답 기한과 학생 의사 확인이 합의된 뒤 결과 요구를 추가해야 한다. 사건 기반 문장이 정책 빈칸을 선명하게 만든 셈이다.

이벤트에는 중복·순서·유실 질문이 따라온다. 학생이 같은 신청을 두 번 제출하거나, 취소 사건이 정원 변경보다 늦게 전달되거나, 외부 메시지가 재전송될 수 있다. 요구에서 특정 메시지 기술을 지정할 필요는 없지만 다음은 결정해야 한다.

• 같은 업무 사건을 식별할 기준은 무엇인가?
• 중복 사건은 무시·재응답·오류 중 무엇으로 처리하는가?
• 순서가 바뀌면 어느 상태와 시각을 기준으로 판정하는가?
• 사건 처리 중 일부만 성공하면 어떤 상태로 복구하는가?
• 처리 결과와 원인을 어떤 기록으로 재현하는가?

이 질문은 18장18장. 유스케이스와 시나리오사용자 목표와 정상·대안·예외 흐름을 유스케이스로 어떻게 명세하는가?페이지로 이동의 예외 흐름, 20장20장. 모델로 표현하는 요구사항경계·상태·순서·데이터·결정의 질문에 맞는 모델을 어떻게 선택하는가?페이지로 이동의 시퀀스·상태 모델과 연결된다. 이벤트 문장 한 줄만으로 상호작용의 순서와 원자성을 모두 보장할 수는 없다.

5. 상태 기반 요구사항

상태 기반 요구사항은 대상이 특정 상태에 머무는 동안 계속 적용되는 의무나 허용·금지를 표현한다. 상태는 화면이 보이는지 같은 일시적 UI 조건이 아니라 업무적으로 구별할 가치가 있는 상황이어야 한다. 수강신청에서는 접수, 판정 중, 보류, 승인, 거절, 취소가 후보지만, 정의와 허용 전이는 20장20장. 모델로 표현하는 요구사항경계·상태·순서·데이터·결정의 질문에 맞는 모델을 어떻게 선택하는가?페이지로 이동의 상태 모델에서 확인해야 한다.

신청이 대기 중이면 상태를 보여 준다.

대기 중이 접수 대기인지 규칙 서비스 실패로 인한 보류인지, 누구에게 무엇을 보여 주는지 불분명하다. IR-001IR-001 · 인터페이스 요구자격·운영 흐름.과 맞추면 다음 후보로 바꿀 수 있다.

• 신청이 보류 상태인 동안, 수강신청 시스템은 인증된 학생에게 현재 상태와 보류 원인, 가능한 다음 행동을 제공해야 한다.
• 신청이 보류 상태인 동안, 수강신청 시스템은 유효한 규칙 판정 없이 그 신청을 승인 상태로 변경해서는 안 된다.

첫 문장은 지속적으로 조회 가능한 정보 의무이고, 두 번째는 안전 금지다. 그러나 보류가 좌석을 점유하는지는 ASM-003ASM-003 · 가정처리 보류가 좌석을 점유하는가?으로 남아 있다. 좌석 점유 여부를 문장에 슬쩍 끼우지 말고 정책 결정과 상태 전이 규칙으로 별도 관리한다.

상태와 사건을 혼동하면 중복 동작이 생긴다. “승인 상태인 동안 학생에게 승인 알림을 보낸다”는 문장은 조회 때마다 알림을 보낼 수 있게 읽힌다. 알림이 필요하다면 “신청이 승인 상태로 전이되면”이라는 사건 기반 요구가 맞다. 반대로 “승인 상태인 동안 학생은 취소 가능 기간에 자신의 신청을 조회할 수 있다”는 지속 권한이므로 상태 기반이 알맞다.

상태 기반 문장은 상태 모델과 양방향으로 검토한다. 문장에 등장한 상태가 모델에 있는지, 모델의 각 상태에서 필요한 정보·권한·시간 제한이 문장에 있는지, 종료 상태에서 금지해야 할 전이가 있는지 확인한다. 문장만 있고 전이가 없으면 생명주기 결함이고, 모델에만 있고 관찰 가능한 의무가 없으면 요구가 빠졌을 수 있다.

6. 금지 요구사항

금지 요구사항은 시스템이 만들면 안 되는 결과나 허용하면 안 되는 행동을 명시한다. “오류가 없어야 한다”처럼 모든 실패를 뭉뚱그린 부정문이 아니라 위험한 상태를 구체적으로 관찰할 수 있어야 한다. 특히 권한 위반, 중복 처리, 정원 초과, 유효하지 않은 판정에 의한 승인처럼 한 번 발생하면 복구 비용이 큰 결과에 유용하다.

중복 신청을 예로 든다.

학생은 같은 과목을 두 번 신청할 수 없다.

이 문장은 업무 규칙처럼 보이지만 중복의 동일성, 적용 상태, 재시도의 사용자 결과가 없다. 같은 학생·같은 강좌·같은 학기인지, 거절·취소된 과거 신청도 중복인지, 네트워크 재시도가 새 신청인지 기존 결과 조회인지 결정해야 한다.

작성 후보는 다음처럼 분리한다.

• 동일 학생·강좌·학기에 유효한 승인 신청이 존재하는 동안, 수강신청 시스템은 새로운 승인 신청을 생성해서는 안 된다.
• 동일한 신청 제출이 반복 수신되면, 수강신청 시스템은 모순되는 복수의 최종 판정이나 좌석 반영을 생성해서는 안 된다.
• 중복으로 판정한 요청에는 수강신청 시스템이 기존 신청의 현재 상태와 식별 가능한 사유를 제공해야 한다.

유효한 승인 신청, 반복 제출 동일성, 취소 후 재신청 허용은 정책 확인이 필요하다. 금지문을 긍정적 결과와 함께 쓰는 이유는 금지만으로 정상 행동을 알 수 없기 때문이다. “복수 승인을 만들지 않는다”는 의무를 지켜도 모든 요청을 거절하는 잘못된 구현이 가능하다. 기존 결과를 재사용할지, 중복 사유로 거절할지, 판정을 다시 조회할지 성공 행동을 정의해야 한다.

금지 요구의 검증은 위험 조건을 의도적으로 만들고 금지 상태가 한 번도 관찰되지 않는지 확인한다. 동시 제출, 재시도, 지연 응답, 서버 전환 같은 조건에서 승인 수·좌석 수·판정 기록을 함께 검사한다. 금지 결과가 발생했을 때 탐지·복구하는 예외 요구도 필요하지만, 복구가 가능하다는 이유로 금지를 약화해서는 안 된다.

7. 예외 요구사항

예외 요구사항은 정상 흐름이 성립하지 않을 때 안전하고 설명 가능하게 멈추거나 복구하도록 한다. 예외는 개발자가 나중에 정할 오류 메시지가 아니다. 외부 연계 실패, 유효하지 않은 데이터, 시간 초과, 권한 불일치, 동시 변경처럼 목표와 신뢰에 영향을 주는 업무 결과다.

IR-001IR-001 · 인터페이스 요구자격·운영 흐름.은 이 장의 대표 예외다.

규칙 서비스가 실패하면 적절하게 처리한다.

실패 범위와 안전 결과가 없다. 지금까지 확인한 의도를 보존하면 다음 후보가 된다.

규칙 서비스가 정한 시간 안에 유효한 판정과 적용 규칙 버전을 제공하지 못하면, 수강신청 시스템은 해당 신청을 자동 승인하지 않고 원인 코드가 있는 보류 상태로 기록해야 한다.

이 문장은 실패 조건, 주체, 금지 결과, 대체 상태와 기록을 포함한다. 그렇다고 예외 처리가 완성된 것은 아니다. 시간 한도, 유효성 판정, 보류의 좌석 점유, 재평가 사건·횟수·종료 기한, 학생 안내, 수동 개입 권한이 남아 있다. 한 문장에 모두 합치지 말고 다음처럼 복구 생명주기를 도출한다.

예외와 대안은 구분한다. 선수과목 미충족처럼 시스템이 정상적으로 규칙을 평가해 거절한 것은 대안 결과다. 규칙 서비스 무응답처럼 정상 판정을 끝내지 못한 것은 예외다. 알림 전송 실패는 판정 실패와 다르므로 이미 승인된 신청을 거절로 되돌리면 안 될 수 있다. 실패가 어느 책임 경계와 업무 결과에 영향을 주는지 분리해야 한다.

이 장에서 만든 전후 비교를 최종 정리한다.

패턴을 적용한 뒤에도 요구 ID, 상위 목표, 출처, 상태와 검증 방법을 붙여 16장16장. 좋은 요구사항의 품질정확성·명확성·완전성·일관성·검증 가능성을 어떤 증거로 판단하는가?페이지로 이동의 품질 기준으로 다시 검토한다. EARS 원 논문은 자연어를 다섯 가지 간단한 템플릿으로 구조화해 결함을 줄이는 접근을 제시했고, IREB CPRE 자료는 개별 요구·사용자 스토리·유스케이스 등에 알맞은 템플릿과 작업 산출물 선택을 다룬다. 어느 자료도 템플릿이 정확한 업무 사실과 완전한 요구 집합을 자동으로 만든다고 보장하지 않는다.

다음 장에서는 이 문장들을 한 사용자의 목표와 시작부터 종료까지의 상호작용으로 묶는다. 그 과정에서 자연어 요구 한 줄에는 보이지 않던 기본 흐름, 대안, 예외와 사후조건이 드러난다.

수강신청 사례에 적용

판단 기준과 흔한 오류

직접 해보는 실습

핵심 요약

관련 도구와 다음 경로