27장. 요구사항 식별과 속성

요구사항을 안정된 ID와 속성·상태·버전으로 관리해 문장이 바뀌어도 의미와 결정 이력을 잃지 않게 한다.

이번 장에서 해결할 질문

학습 목표

• “요구마다 안정적인 ID와 필요한 속성을 어떻게 부여하고 유지하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
• 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.

핵심 개념

요구사항 문장은 프로젝트 동안 계속 바뀌지만 그 의미와 결정 이력은 잃어서는 안 된다. 제목이나 번호를 임의로 고치고 최신 파일만 남기면 설계·시험·변경 요청이 어느 내용을 참조하는지 알 수 없게 된다. 관리는 문서를 보관하는 일이 아니라 합의된 상태를 재현하는 일이다.

이 장에서는 안정된 식별자, 속성, 상태, 버전과 기준선으로 요구사항을 관리한다. 변경 전후의 의미와 승인 근거를 보존하고 저장소·대장·도구의 역할을 구분해, 여러 산출물이 같은 요구 버전을 참조하도록 통제하는 방법을 살펴본다.

1. 요구사항 ID

요구사항 관리는 검증·확인된 지식을 시간이 지나도 같은 대상으로 가리킬 수 있게 만드는 일에서 시작한다. 문장만 복사해 두면 비슷한 요구가 여러 문서에 생기고, 어느 버전을 검토·구현·시험했는지 알 수 없다. 요구사항 ID요구사항 ID문장이 바뀌어도 같은 요구를 안정적으로 식별하고 관계와 이력을 연결하는 고유 표식이다.는 사람이 읽기 좋은 제목과 달리 생명주기 동안 대상을 안정적으로 식별하는 키다.

ISO/IEC/IEEE 29148은 요구공학 절차와 그 과정에서 생성하는 정보 항목을 생명주기 전체에 걸쳐 다룬다. NASA의 형상관리 요구는 통제할 항목에 고유 식별자와 소유자, 기준선을 두도록 한다. 도구보다 먼저 조직이 식별 규칙과 변경 금지 원칙을 합의해야 한다.

좋은 ID는 다음 특성을 가진다.

• 하나의 관리 대상에 하나만 부여하고 재사용하지 않는다.
• 요구가 수정돼도 ID는 유지하고 버전과 이력으로 변화를 표현한다.
• 분류를 돕는 최소 접두어 외에 조직·기능·우선순위처럼 바뀔 의미를 과도하게 넣지 않는다.
• 삭제된 번호를 새 요구에 재사용하지 않고 폐기 상태로 보존한다.
• 문서, 모델, 이슈, 설계와 시험에서 같은 표기를 사용한다.

앞 장까지 사용한 FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다.은 “현재 학사 규칙과 강좌 상태로 신청을 판정하고 승인 ID 또는 거절 사유를 제공한다”는 요구 후보다. 이 원고에서는 FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다.을 정식 키로 유지한다. 기능 영역을 포함하는 ID 체계를 새 프로젝트에서 선택할 수는 있지만, 기존 항목의 번호를 바꾸려면 과거 링크를 보존하는 전환 매핑과 이후 영역 이동에도 ID를 유지하는 규칙이 먼저 필요하다.

이 사례의 ID 규칙 후보는 G, BR, UR, SR, FR, QR, DR, IR, RULE, ASM, ISS, DEC, CR 접두어와 증가 번호다. 접두어는 관리 종류를 알릴 뿐 문장의 내용이나 승인 상태를 보장하지 않는다. CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다.은 29장29장. 요구사항 변경 관리변경 요청의 이유·영향·결정·반영 결과를 어떻게 통제하는가?페이지로 이동에서 다룰 변경 요청이며, 번호가 있다는 사실만으로 승인된 변경은 아니다.

ID를 부여하는 시점도 정한다. 인터뷰에서 나온 모든 문장을 즉시 요구 ID로 만들면 중복과 미확인 의견이 요구 목록을 채운다. 먼저 도출 메모나 발견 항목으로 기록한 뒤, 독립적으로 관리할 필요가 있고 다른 요구와 구분되며 출처를 가리킬 수 있을 때 ID를 부여한다. 반대로 승인 직전까지 번호를 미루면 검토 의견과 결정 근거를 같은 대상으로 모을 수 없다.

ID 생성 권한과 중복 검사도 관리한다. 여러 팀이 중앙 번호를 기다리느라 일을 멈추지 않도록 범위별 번호 공간이나 자동 발급을 사용할 수 있지만, 병합할 때 유일성을 검사한다. 표시 형식에서 앞자리 0의 개수, 대소문자, 하이픈을 통일하고 스프레드시트가 ID를 숫자나 날짜로 바꾸지 않게 문자열로 보관한다.

ID·버전·상태·근거·책임을 함께 관리할 필드와 예시는 부록 F. 요구사항 관리대장 예제요구사항 관리대장 예제실무에서 바로 사용할 수 있는 기준과 예제를 확인한다.페이지로 이동에서 확인할 수 있다. 대장은 요구 본문의 대체물이 아니라 기준 원문과 결정 이력을 찾는 색인으로 사용한다.

2. 제목

제목은 목록과 회의에서 요구를 빠르게 구별하는 짧은 이름이다. ID를 대신하지 않고, 요구 전체를 압축해 법적 효력을 가진 문장처럼 사용하지도 않는다. 제목은 바뀔 수 있으므로 링크의 키로 쓰지 않는다.

FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다.의 제목 후보는 학사 규칙 기반 신청 판정이다. “수강신청 기능”처럼 너무 넓으면 FR-002FR-002 · 기능 요구인증·대상·신청 기간과 요청 형식을 확인해 신청 의도를 고유 식별자로 접수하고 접수 결과를 제공한다는 기능 요구다. 접수나 FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다. 결과 조회와 구분되지 않는다. 반대로 “선수과목·시간표·학점·수용량·우선순위 검사 후 승인 식별자 또는 거절 사유 반환”처럼 길면 설명을 제목에 중복한다.

제목 검토 질문은 세 가지다.

1. 같은 목록의 다른 요구와 구별되는가?
2. 구현 방식보다 기대 결과를 드러내는가?
3. 제목만 읽고 세부 조건을 추측하게 만들지 않는가?

화면, 보고서와 변경 회의에서는 FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다. 학사 규칙 기반 신청 판정처럼 ID와 제목을 함께 표시한다. 제목이 바뀌어도 이력과 관계는 ID로 이어진다.

3. 설명

설명은 관리대장에서 요구의 의도와 범위를 빠르게 이해하게 하는 요약이다. 규범적인 요구 문장, 모델, 수용 조건과 원전 자료를 모두 복사하지 않는다. 짧은 설명이 원문과 다르면 원문과 다른 기준이 하나 더 생기므로 기준 본문의 링크와 버전을 함께 둔다.

FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다.의 관리용 설명 후보는 다음과 같다.

유효하게 접수된 신청에 기준 시점의 학사 규칙과 강좌 상태를 적용해 승인·거절·보류 중 허용된 결과와 사유를 생성한다. 세부 규칙, 실패 처리와 기록 항목은 연결된 RULE, IR, DR 요구를 따른다.

이 설명은 전체 요구를 새로 쓰지 않고 판정의 목적과 관련 항목을 알려 준다. “AI가 최적 판단한다”거나 “실시간으로 무조건 승인한다”처럼 합의되지 않은 설계·품질을 넣지 않는다. 설명을 수정할 때는 규범 문장의 의미가 바뀌었는지 검토한다. 의미가 바뀌었다면 단순 편집이 아니라 버전 변경 또는 변경 요청이다.

4. 출처

출처는 요구가 누구의 필요, 어떤 정책·규정, 관찰 자료나 상위 요구에서 나왔는지를 보여 준다. 회의 참석자 이름 하나만 적으면 나중에 원문과 권한, 유효 시점을 확인할 수 없다. 출처에는 유형, 식별자, 소유 조직, 문서·자료 버전, 발효일 또는 관찰 기간과 인용 위치를 둔다.

FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다.의 출처는 SR-001SR-001 · 시스템 요구멱등 처리 항목.과 관련 업무 규칙이다. 그러나 RULE-001–RULE-005RULE-001–RULE-005RULE-001: 신청자가 적용되는 선수과목의 동시 이수·대체·면제·성적 시점 조건을 충족해야 한다는 업무 규칙 후보다. · RULE-002: 승인으로 계산되는 학점 합계가 학생에게 적용되는 최대 신청 학점을 넘지 않아야 한다는 업무 규칙 후보다. · RULE-003: 시간 충돌 판정. · RULE-004: 분반의 승인된 수강 등록 수가 적용되는 정원을 넘지 않아야 한다는 업무 규칙이다. · RULE-005: 우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다.는 출처·예외가 모두 확인되지 않았다. 따라서 출처 속성은 “정책 확인 전” 상태와 정책 책임자를 함께 가리켜야 한다. 링크가 있다고 출처의 신뢰성이 생기지는 않는다.

인터뷰 발언이 출처라면 녹취 전체보다 확인된 요약과 동의 범위, 서로 다른 의견을 남긴다. 개인정보가 포함된 원자료는 최소 접근으로 분리하고 관리대장에는 안전한 참조만 둔다. 정책이 개정되면 이전 출처를 덮어쓰지 않고 새 버전과 영향받는 요구를 연결한다.

5. 담당자

담당자는 요구의 내용을 혼자 결정하는 사람이 아니라 생명주기 동안 정확성·상태·관계를 유지하고 필요한 결정을 추적하는 책임자다. 업무 정책 결정권자, 요구 관리 책임자, 구현 책임자와 검증 책임자를 한 “담당자” 칸에 섞지 않는다.

FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다.의 요구 소유자는 학사 정책 책임 조직이어야 하지만 실제 이름과 위임 범위는 아직 확인되지 않았다. 빈칸을 임의의 직책으로 채우지 않고 “학사 정책 소유자 지정 필요”로 관리한다. IR-001IR-001 · 인터페이스 요구자격·운영 흐름.의 외부 장애 대응에는 규칙 서비스 책임자와 수강신청 운영 책임자가 함께 관여하지만 최종 보류 정책의 결정권은 따로 확인해야 한다.

사람 이름만 쓰면 인사이동 때 책임이 사라진다. 기본은 역할·조직으로 두고 현재 수행자와 대리자를 연결한다. 담당자가 바뀌어도 요구 ID와 결정 이력은 유지한다.

6. 우선순위

우선순위는 “중요함”의 감상적 순위가 아니라 제한된 자원과 시점에서 무엇을 먼저 결정·구현·검증할지 선택하는 정보다. 가치, 긴급성, 위험 감소, 법적 의무, 의존성, 비용과 기회비용을 함께 본다. IIBA 요구사항 생명주기 관리는 추적·유지와 함께 우선순위, 변경평가, 승인을 연속 관리 활동으로 제시한다.

우선순위 속성에는 방법과 시점을 함께 기록한다.

FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다.의 안전한 판정과 QR-003QR-003 · 품질 요구동시 신청 경쟁.의 수용량 초과 방지는 높은 중요도를 가질 가능성이 크다. 하지만 “필수”라고 쓰려면 정책·안전·업무 연속성 근거가 있어야 한다. RULE-005RULE-005 · 업무 규칙우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다.의 우선순위 배정 정책과 요구 개발 우선순위는 다른 개념이다. 이름이 같아도 하나는 학생 신청을 배정하는 업무 규칙이고, 다른 하나는 팀의 자원 배분 결정이다.

우선순위는 고정 낙인이 아니다. 범위, 위험, 의존성과 기준선이 바뀌면 권한 있는 사람이 다시 평가하고 이유를 남긴다. 모든 요구를 최상위로 분류하면 실제 선택을 숨긴다.

7. 상태

상태는 요구가 현재 어느 합의·통제 단계에 있고 어떤 행동이 허용되는지 나타낸다. 작성 진척률, 개발 작업 상태, 시험 결과와 섞지 않는다. 상세 생명주기는 30장30장. 요구사항 상태와 생명주기요구의 제안·분석·승인·구현·검증·폐기 상태와 이력을 어떻게 관리하는가?페이지로 이동에서 다루며 이 장에서는 관리대장에 상태 코드, 상태 진입일, 결정자와 근거를 함께 둔다는 원칙을 세운다.

현재 사례의 요구들은 교육용 후보이며 실제 이해관계자 승인과 기준선 지정이 수행되지 않았다. 25장25장. 요구사항 검증요구사항 문서 자체의 결함을 구현 전에 어떻게 찾아내는가?페이지로 이동과 26장26장. 요구사항 확인작성된 요구가 실제 이해관계자의 필요와 사용 맥락에 맞는지 어떻게 확인하는가?페이지로 이동에서 검증·확인 방법과 예시 기록을 만들었지만 실제 공식 검토를 했다는 뜻은 아니다. 따라서 FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다.을 “승인”이나 “완료”로 올리지 않는다.

상태 값 후보는 제안, 분석 중, 검토 준비, 검토됨, 승인, 구현 중, 충족 검증, 완료, 변경 분석, 보류, 폐기다. 이름만 두지 않고 각 상태의 진입·종료 조건을 정의한다. 하나의 요구가 동시에 “승인”과 “폐기”일 수 없게 단일 현재 상태를 두고, 구현·시험 진행은 별도 연결 항목에서 본다.

8. 버전

버전은 같은 요구 ID가 시간에 따라 어떤 내용을 가졌는지 구별한다. ID는 대상을 가리키고 버전은 그 시점의 내용을 가리킨다. 문장 수정, 속성 변경, 관계 수정 가운데 무엇이 버전을 올리는지 규칙을 정해야 한다.

FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다. v0.3처럼 승인 전 초안을 반복할 수 있고, 승인된 첫 기준선을 v1.0으로 정할 수 있다. 숫자 방식 자체보다 어떤 변화가 어떤 검토를 다시 요구하는지가 중요하다. 버전만 올리고 근거·작성자·시간·차이를 남기지 않으면 이력을 복원할 수 없다.

문서 버전과 개별 요구 버전도 구분한다. 한 명세서 SRS v1.4 안에 변경되지 않은 FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다. v1.0과 새로 수정된 FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다. v1.2가 함께 있을 수 있다. 기준선은 포함한 각 항목과 버전을 명시해야 한다.

9. 근거

근거는 이 요구가 왜 필요하고 왜 이런 조건·값·우선순위를 선택했는지 설명하는 결정 지식이다. 출처가 “어디서 왔는가”라면 근거는 “그 자료에서 왜 이 요구와 표현이 도출됐는가”에 답한다.

FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다.의 근거 후보는 G-01G-01 · 목표목표가 필요를 유발, 효과는 측정 전.의 반복 제출·수동 재처리 문제를 줄이려면 일관된 판정과 설명 가능한 결과가 필요하다는 것이다. 그러나 ASM-001ASM-001 · 가정결과를 알 수 없는 상태에서 발생하는 반복 제출이 수동 재처리 증가에 유의미하게 기여한다는 미확인 가정이다.의 인과관계가 아직 확인되지 않았으므로 효과를 확정해서 쓰지 않는다. “상태와 사유 제공이 반복 제출 감소에 기여하는지 로그·사용자 확인으로 검증한다”는 불확실성까지 기록한다.

근거에는 고려한 대안과 배제 이유도 유용하다. 규칙 서비스 실패 때 자동 승인, 즉시 거절, 안전 보류를 비교하고 IR-001IR-001 · 인터페이스 요구자격·운영 흐름.은 잘못된 승인 위험을 피하기 위해 보류를 후보로 선택했다. 보류가 운영 적체를 만들 수 있다는 반대 영향과 종료 정책 미결도 함께 둔다.

근거를 요구 문장에 모두 넣으면 문장이 무거워진다. 별도 속성으로 연결하되 요구가 바뀌면 근거가 여전히 유효한지 다시 검사한다. “고객 요청”이나 “회의 결정”만 적지 않고 요청한 목적과 증거, 권한을 남긴다.

10. 위험

위험 속성은 요구가 잘못되거나 누락되거나 늦게 결정됐을 때, 또는 그대로 구현했을 때 생길 수 있는 불확실한 영향을 관리한다. 결함 상태와 위험을 구분한다. 출처가 없다는 것은 현재 결함이고, 그 결과 잘못된 정책을 구현해 공정성 문제가 생길 가능성은 위험이다.

위험 속성은 단순 높음·중간·낮음보다 원인, 불확실 사건, 영향, 현재 통제, 소유자와 재검토 시점을 둔다. 위험이 높으면 요구 우선순위나 검토 강도, 증거 수준이 달라질 수 있다. 위험이 실현되면 문제·결함 기록으로 전환하고 요구와 연결한다.

11. 관련 항목

관련 항목은 요구를 고립된 문장이 아니라 목표·규칙·데이터·인터페이스·설계·시험·변경과 연결된 관리 단위로 만든다. 모든 링크를 “관련” 하나로 저장하면 방향과 의미를 알 수 없으므로 관계 유형을 구분한다. 28장28장. 요구사항 추적성필요에서 요구·설계·코드·시험까지 관계를 어떻게 추적하고 활용하는가?페이지로 이동에서 이를 양방향 추적으로 확장한다.

FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다. 관리대장 후보를 한 행으로 묶으면 다음과 같다.

속성 사전에는 각 속성의 정의, 자료형, 허용값, 필수 시점, 작성·승인 역할, 변경 규칙과 예를 둔다. 프로젝트가 실제로 검색·결정·감사에 쓰지 않는 속성은 넣지 않는다. 속성이 많을수록 품질이 좋아지는 것이 아니라 최신 상태를 유지할 비용과 오류 표면이 커진다.

관리대장은 요구 작성 때 한 번 채우고 끝나는 표가 아니다. 도출 때 ID·제목·출처를 만들고, 분석하면서 설명·관계·위험을 보강하며, 검토 때 결함과 상태를 연결한다. 승인 때 버전과 기준선을 고정하고, 구현·시험 중 하위 추적과 결과를 추가하며, 변경·폐기 뒤에도 이전 값을 복원할 수 있게 이력을 남긴다. 각 단계에서 필수 속성이 달라지므로 모든 빈칸을 초기부터 억지로 채우지 않는다.

속성 품질은 정기적으로 다음을 검사한다.

• 허용값 밖의 상태·우선순위나 형식이 다른 ID가 있는가?
• 담당자가 떠났거나 출처 문서가 폐기된 항목이 있는가?
• 본문 버전과 관리대장 버전, 기준선 포함 버전이 같은가?
• 관계 대상이 존재하며 폐기·대체 상태를 올바르게 따라가는가?
• 후보 숫자와 가정이 승인된 값처럼 표시되지 않았는가?
• 민감한 원자료가 관리대장에 불필요하게 복제되지 않았는가?

이 장에서 정리한 결과는 ID 규칙, 속성 사전, 요구사항 관리대장이다. 검토할 때는 중복·재사용 ID, 의미를 과도하게 담은 ID, 신뢰할 수 없는 출처, 소유자 없는 요구, 근거 없는 최우선 등급, 실제보다 앞선 상태와 끊어진 관계를 찾는다. 이 관리대장의 안정된 키와 속성을 다음 장의 추적 관계에 사용한다.

수강신청 사례에 적용

판단 기준과 흔한 오류

직접 해보는 실습

핵심 요약

관련 도구와 다음 경로