15장. 좋은 요구사항을 작성하는 법

한 문장에 한 의무를 담고 주체·조건·행동·결과를 분명히 해 검토하고 시험할 수 있는 요구사항을 작성한다.

이번 장에서 해결할 질문

학습 목표

• “한 문장을 구현·시험·검토할 수 있는 요구사항으로 어떻게 작성하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
• 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.

핵심 개념

분석과 합의가 좋아도 요구사항 문장이 여러 뜻으로 읽히면 구현과 시험은 다시 갈라진다. 한 문장에 여러 의무가 섞이거나 주체·조건·결과가 빠지면 검토자는 각자의 상식으로 빈칸을 채운다. 자연스러운 문장과 검증 가능한 문장은 반드시 같지 않다.

이 장에서는 한 문장에 한 의무를 담고 주체·조건·행동·대상·결과를 분명히 하는 작성 원칙을 다룬다. 모호한 수식어와 해법 편향을 줄이고 용어와 예외를 일관되게 표현해, 설계자와 시험자가 같은 의미를 재현할 수 있는 요구사항을 만든다.

1. 하나의 요구사항에는 하나의 요구

4부에서는 요구 후보의 결함을 찾고 범위·관계·우선순위와 합의 상태를 정리했다. 이제 그 의미를 다른 사람이 같은 방식으로 읽고 검토할 수 있는 문장으로 옮겨야 한다. 좋은 문장은 예쁘거나 짧은 문장이 아니다. 어떤 조건에서 누가 무엇을 하며, 관찰할 결과와 판단 기준이 무엇인지 드러나는 문장이다.

첫 원칙은 한 요구사항에 하나의 핵심 의무를 담는 것이다. 다음 초안은 짧지만 원자적이지 않다.

시스템은 수강신청을 빠르고 정확하게 처리하고 학생에게 결과를 알리며 관리자가 이력을 조회할 수 있어야 한다.

여기에는 신청 판정, 성능, 정확성, 학생 통지, 관리자 조회라는 서로 다른 의무가 있다. 일부만 충족해도 전체 문장을 통과시킬지 결정할 수 없고, 변경·우선순위·검증 책임도 따로 관리할 수 없다. 12장12장. 요구사항을 구조화한다흩어진 요구를 목표·기능·규칙·데이터·품질과 관계로 어떻게 구조화하는가?페이지로 이동의 구조에 따라 최소한 FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다. 판정, QR-001QR-001 · 품질 요구합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다. 상태 조회 성능, UR-001UR-001 · 사용자 요구신청 가능 강좌와 결과·사유 확인 / 사용자. 결과·사유 확인, DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다. 판정 기록으로 나눈다.

의무를 하나씩 나눈다고 해서 문장을 무조건 짧게 자르라는 뜻은 아니다. 하나의 조건에서 하나의 동작이 여러 필수 결과를 함께 만들어야 한다면 같은 요구로 둘 수 있다. 예를 들어 “승인된 신청에는 신청 식별자와 승인 시각을 연결한다”에서 두 데이터가 하나의 승인 기록을 완성한다면 함께 검증할 수 있다. 반면 신청 승인과 거절 처리는 조건·결과가 달라 분리하는 편이 낫다.

분해 후보는 다음과 같다. 아직 정책 세부가 확인되지 않았으므로 승인 요구가 아니라 작성 예시다.

원자성원자성한 요구사항이 독립적으로 승인·변경·검증할 수 있는 하나의 의무만 담는 성질이다.을 판정할 때는 접속사 수보다 독립적인 승인·변경·시험 가능성을 본다. 문장의 일부가 바뀌어도 나머지를 그대로 승인할 수 있는가, 실패 원인과 책임자가 다른가, 서로 다른 우선순위가 가능한가를 묻는다. 그렇다면 나누고 상위 요구와 관계로 묶는다. 문장을 나눈 뒤에도 FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다.의 의미와 G-01G-01 · 목표목표가 필요를 유발, 효과는 측정 전.까지 추적되어야 한다.

요구 초안을 직접 작성하거나 동료와 검토할 때는 부록 B. 요구사항 문장 패턴요구사항 문장 패턴실무에서 바로 사용할 수 있는 기준과 예제를 확인한다.페이지로 이동의 조립 순서와 점검 카드를 활용할 수 있다. 패턴은 빠진 요소를 찾는 도구이지 실제 규칙과 근거를 대신하는 문장 생성 공식이 아니다.

2. 주체를 명확하게 작성한다

주체는 의무를 수행하고 결과에 책임지는 대상이다. “처리된다”, “제공되어야 한다”, “확인이 가능해야 한다” 같은 피동 표현은 누가 행동하는지 숨긴다. 학생, 교무 담당자, 수강신청 시스템, 외부 규칙 서비스 중 누가 무엇을 해야 하는지 구분해야 한다.

다음 문장을 보자.

신청 결과가 즉시 표시되어야 한다.

표시 주체가 학생 앱인지 수강신청 시스템인지, 외부 알림 서비스인지 알 수 없다. “학생은 신청 결과를 확인할 수 있어야 한다”로 바꾸면 사용자 요구 UR-001UR-001 · 사용자 요구신청 가능 강좌와 결과·사유 확인 / 사용자.이 된다. “수강신청 시스템은 인증된 학생에게 해당 신청의 현재 상태와 사유를 제공해야 한다”로 바꾸면 시스템 책임을 표현한다. 두 문장은 추상 수준이 다르므로 중복이 아니라 추적 관계다.

사람을 주체로 쓸 때 권한과 시스템 의무를 섞지 않는다.

관리자는 잘못된 신청을 수정한다.

이 문장은 현행 업무 사실인지, 관리자의 권한 요구인지, 시스템 기능 요구인지 불분명하다. 다음처럼 질문을 나눈다.

• 어떤 역할이 어떤 상태의 신청을 수정할 권한이 있는가?
• 어느 조건에서 원래 판정을 바꿀 수 있는가?
• 시스템은 권한을 확인하고 어떤 변경·사유·승인자를 기록해야 하는가?
• 학생과 운영자는 변경 결과를 어떻게 알게 되는가?

시스템 요구에서는 조직이 합의한 관심 시스템 이름을 일관되게 쓴다. 11장11장. 범위를 정의한다제품과 프로젝트가 책임질 범위와 경계 밖의 일을 어떻게 합의하는가?페이지로 이동에서 경계를 정한 이름은 수강신청 제품 또는 문맥상 수강신청 시스템이다. 서비스, 플랫폼, 서버, 프로그램을 근거 없이 번갈아 쓰면 책임 범위가 흔들린다. 외부 인증·학사정보·알림 서비스는 별도 주체로 적고, “시스템”이 어느 쪽인지 모호하지 않게 한다.

주체 검토 질문은 세 가지다. 이 행동을 실제로 수행하는가, 결과에 책임지는 경계 안의 대상인가, 같은 이름이 문서 전체에서 같은 대상을 뜻하는가? 답이 갈리면 문장을 고치기 전에 11장11장. 범위를 정의한다제품과 프로젝트가 책임질 범위와 경계 밖의 일을 어떻게 합의하는가?페이지로 이동의 시스템 경계와 책임표를 다시 확인한다.

3. 조건을 명확하게 작성한다

조건은 요구가 적용되거나 동작이 시작되는 상황이다. 조건이 없으면 요구가 항상 적용되는 것처럼 읽히거나, 구현자마다 정상 상황만 상상한다. 시간, 상태, 입력의 유효성, 역할, 업무 사건과 실패가 대표적인 조건이다.

FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다.을 “시스템은 선수과목을 확인해야 한다”라고만 쓰면 언제 확인하는지 알 수 없다. 강좌 조회 때인지, 신청 제출 때인지, 승인 직전인지, 학적 변경 뒤 재평가 때인지에 따라 결과가 다르다. 후보 문장은 다음처럼 바뀐다.

본 신청 기간에 인증된 학생이 신청 가능한 상태의 강좌를 제출하면, 수강신청 시스템은 해당 요청에 적용되는 선수과목 규칙을 평가해야 한다.

그러나 이 문장도 신청 가능한 상태, 적용되는 규칙, 기준 시점이 정의되어야 완전하다. 조건을 길게 넣어 모든 예외를 한 문장에 몰지 않는다. 공통 조건은 용어·업무 규칙이나 상위 범위로 정의하고, 결과가 달라지는 예외는 별도 요구로 분리한다.

조건은 다음 유형으로 점검할 수 있다.

조건은 구현 순서가 아니라 업무 의미를 먼저 표현한다. “API 호출이 성공하면”보다 “권한 있는 학사 규칙을 유효하게 평가할 수 있으면”이 필요에 가깝다. API 선택은 설계 대안일 수 있다. 조건의 최소 증거는 정책·상태 모델·인터페이스 계약·실제 사례다. 근거가 없으면 확정 조건으로 쓰지 말고 ASM-002ASM-002 · 가정규칙 버전 제공 여부 미확인., ASM-003ASM-003 · 가정처리 보류가 좌석을 점유하는가?과 같은 가정 또는 쟁점으로 되돌린다.

4. 동작을 명확하게 작성한다

동작은 주체가 수행할 관찰 가능한 행위다. 지원한다, 관리한다, 처리한다, 고려한다, 대응한다는 넓은 동사라 무엇을 해야 완료인지 말해 주지 못한다. 명사형도 행동을 흐린다. “신청 상태 관리를 제공한다”보다 평가한다, 기록한다, 변경한다, 반환한다, 거절한다, 보류한다처럼 업무 결과를 만드는 동사를 쓴다.

다음 초안을 비교해 보자.

시스템은 졸업 예정자 우선순위를 고려한다.

고려한다는 판정 결과가 없어 검증할 수 없다. 무엇을 기준으로 후보를 분류하고, 같은 순위와 좌석 부족에서 어떻게 배정하며, 결과와 근거를 무엇으로 남기는지 정책이 필요하다. RULE-005RULE-005 · 업무 규칙우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다.가 확정되지 않은 현재는 임의 문장으로 고치지 않고 다음 질문을 정책 결정에 보낸다.

• 우선순위 대상은 어떤 데이터와 기준 시점으로 결정하는가?
• 우선순위는 예약 정원, 배정 순서, 예외 승인 중 무엇을 바꾸는가?
• 동률일 때 어느 사건·기준으로 결과를 결정하는가?
• 대상 판정 불가와 정책 충돌 때 어떤 상태를 만드는가?
• 학생과 담당자에게 어떤 사유를 제공하고 무엇을 기록하는가?

정책이 합의되면 하나의 넓은 동작을 분류·정렬·배정·기록 같은 원자적 요구로 표현한다. 단, 알고리즘 내부 단계를 요구사항에 그대로 쓰지는 않는다. 구현자가 선택할 수 있어야 하는 계산 방식과 이해관계자가 관찰해야 하는 결과를 분리한다.

동작 검토에서는 주 동사가 하나의 핵심 의무를 나타내는지, 행위가 결과로 관찰되는지, 동일 동사를 용어집에서 같은 뜻으로 쓰는지, 구현 세부를 강제하지 않는지를 본다. 검증한다도 무엇과 대조해 어떤 판정을 내리는지 없으면 모호하다.

5. 결과를 명확하게 작성한다

동작을 적었어도 이후 상태와 출력이 없으면 완료를 판단할 수 없다. 결과는 사용자나 다른 시스템이 관찰할 수 있는 상태 변화, 정보, 반환값, 기록 또는 허용·거부된 행동이다. 성공만 아니라 실패·판정 불가·부분 성공의 결과도 필요하다.

“신청을 처리한다”를 결과별로 살펴본다.

이 나무는 결과 후보를 보여 주며, 하나의 거대한 요구 문장으로 합치라는 뜻이 아니다. 특히 정원 반영과 상태 변경의 원자성, 보류의 좌석 점유 ASM-003ASM-003 · 가정처리 보류가 좌석을 점유하는가?, 복수 거절 사유의 표현은 아직 합의해야 한다.

결과 문장은 단순히 화면 문구를 지정하기보다 사용자가 얻어야 할 의미를 먼저 적는다. “초록색 토스트를 표시한다”는 설계 제안이고, “학생에게 해당 신청의 현재 상태, 판정 사유와 가능한 다음 행동을 제공한다”는 사용자 결과에 가깝다. 색상·위치·채널은 접근성·디자인과 함께 결정할 수 있다.

결과를 검토할 때 상태 모델과 데이터 요구를 대조한다. 이전 상태에서 허용되는 변화인지, 식별자·시각·사유·규칙 버전이 DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다.과 일치하는지, 같은 요청을 반복해도 모순된 최종 결과가 생기지 않는지 묻는다. 결과를 누가 어느 경계에서 관찰하는지도 시험 설계의 입력으로 남긴다.

취소 요구도 같은 방식으로 작성한다. “학생은 언제든 수강신청을 취소할 수 있다”는 문장은 기간·상태·권한·후속 결과가 빠져 있다. 작성 후보는 “취소 가능 기간에 인증된 학생이 자신이 승인받은 신청의 취소를 제출하면, 수강신청 시스템은 해당 신청을 취소 상태로 변경하고 취소 시각을 판정 이력에 기록해야 한다”처럼 만들 수 있다. 그러나 취소가 정원을 언제 반환하는지, 대기명단이 있으면 누가 다음 대상이 되는지, 취소 불가 상태에서 어떤 사유를 제공하는지는 별도 요구와 정책으로 남는다. 취소 한 문장만 매끄럽게 만드는 것으로 신청 집합의 결과가 완전해지지는 않는다.

조회·신청·취소 문장은 서로 독립적으로 검토하면서도 같은 상태 이름과 식별자를 사용해야 한다. 조회가 승인을 보여 주는데 취소 요구는 등록 완료만 대상으로 삼는다면 두 용어가 같은 상태인지 확인할 수 없다. 결과를 명확히 쓴다는 것은 출력 필드를 늘리는 일이 아니라 업무 상태와 관찰 가능한 의미를 일치시키는 일이다.

6. 측정 가능한 기준을 사용한다

측정 가능한 기준은 요구의 충족 여부를 합의된 방법으로 판정하게 한다. 숫자가 들어갔다고 자동으로 측정 가능한 것은 아니다. 대상, 단위, 관측 지점, 운영 조건, 표본, 시간 구간과 합격 규칙이 함께 있어야 한다.

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

마지막 문장도 완성본은 아니다. 합의된 부하 시험 환경에 동시 사용자, 요청률, 데이터 규모·분포, 워밍업, 캐시 상태, 측정 시작·끝과 오류율이 정의되어야 한다. 95백분위는 관측된 응답시간을 작은 값부터 정렬했을 때 적어도 95%가 기준 이내라는 뜻으로 사용한다. 표본 수와 계산 규칙이 다르면 경계 값이 달라질 수 있으므로 시험 계획에 명시한다.

비율·횟수·시간 외에도 열거된 상태, 참조 규칙, 입력·출력 일치, 금지된 결과로 검증할 수 있다. IR-001IR-001 · 인터페이스 요구자격·운영 흐름.의 “자동 승인하지 않는다”는 안전 속성은 실패 조건에서 승인 상태가 생성되지 않았음을 검사할 수 있다. 정성적 품질도 사용 맥락, 사용자 집단, 과업과 성공 기준을 정하면 평가 가능해진다.

수치는 이해관계자가 즉석에서 고르는 장식이 아니다. BR-001BR-001 · 업무 요구목표값과 투자 범위. 사업 후원자·교무 책임자.의 50%와 QR-001QR-001 · 품질 요구합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다.의 2초는 사례용 목표 후보이며 기준선·가치·비용·위험 검토와 결정권자의 승인이 필요하다. 측정 방법을 쓸 수 없거나 데이터가 없으면 ‘검증 불가’ 결함 또는 실현 가능성 위험으로 표시한다.

7. 모호한 표현을 제거한다

자연어는 사람이 읽기 쉽지만 단어·문장·문맥의 여러 해석을 피하기 어렵다. IREB CPRE Foundation Level 자료는 개별 요구를 위한 구문 템플릿을 다루며, 조건·주체·행동·대상·제약을 채우는 구조를 소개한다. IREB 용어집은 비모호성을 서로 다른 사람이 다르게 이해할 수 없도록 표현된 정도로 설명한다. 템플릿은 빠진 자리를 보이게 하지만 의미를 자동으로 올바르게 만들지는 않는다.

이 장에서 사용할 기본 구조는 다음과 같다.

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

한국어에서는 “–해야 한다”를 의무 요구에 쓰고, 권고·허용·사실 문장은 별도 표기 규칙을 정한다. 영어의 shall·should·may를 기계적으로 섞지 않는다. 프로젝트 용어 규칙에 합의하고 문서 전체에서 일관되게 사용한다. ISO/IEC/IEEE 29148은 요구사항 공학 프로세스와 정보 항목·형식 지침을 제공하는 현재 발행본이며, 2026년 현재 개정 예정이므로 조직에서 채택할 때 판본의 상태를 확인한다.

다음 표현은 삭제만 하지 말고 질문으로 바꾼다.

문장 전후 비교를 정리하면 다음과 같다.

검토자는 템플릿 칸이 찼는지만 보지 않는다. 두 사람이 각 문장을 독립적으로 읽고 적용 조건, 예상 결과와 합격 시험을 적은 뒤 비교한다. 다르면 어느 단어·전제·참조가 해석 차이를 만들었는지 기록한다. 이것이 “누가 읽어도 같은 의미”에 가까워졌는지 확인하는 재현 가능한 방법이다.

이 장에서 정리한 결과는 문장 구조 템플릿, 모호성 신호표, 전후 비교와 각 문장의 남은 확인 항목이다. FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다., UR-001UR-001 · 사용자 요구신청 가능 강좌와 결과·사유 확인 / 사용자., QR-001QR-001 · 품질 요구합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다., DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다., IR-001IR-001 · 인터페이스 요구자격·운영 흐름.의 ID와 4부 관계는 유지했고, 정책·수치가 미확정인 부분을 확정형으로 바꾸지 않았다. 다음 장에서는 잘 쓴 것처럼 보이는 문장을 필요성·정확성·명확성·완전성·일관성·실행 가능성·검증 가능성·추적 가능성·원자성·구현 독립성으로 다시 판정한다. 남은 핵심 질문은 하나다. 개별 문장이 좋아도 요구 집합 전체가 빠짐없고 서로 맞는지를 어떻게 같은 기준으로 검토할 것인가?

수강신청 사례에 적용

판단 기준과 흔한 오류

직접 해보는 실습

핵심 요약

관련 도구와 다음 경로