요구 도출·분석·명세·검증·추적

1. 취소 버튼은 있는데, 취소할 수 있는지는 아무도 정하지 않았다

앞에서 다뤘던 동네 공방이 전화 예약을 웹으로 옮기고 있다. 고객은 “쉽게 취소하게 해 주세요”라고 하고 강사는 “재료를 준비한 뒤에는 취소를 막아 주세요”라고 한다. 개발자는 취소 버튼을 만들었지만, 수업 하루 전 정확히 같은 시각에 눌렀을 때 허용할지, 이미 취소된 예약에 다시 눌렀을 때 무슨 결과를 보여 줄지는 아직 정하지 않았다.

버튼이 없어서 생긴 문제가 아니다. 사람들의 말을 함께 실행할 수 있는 조건으로 만들지 않은 것이 원인이다. 이 절에서는 공방의 한 취소 규칙을 끝까지 따라가며, 근거를 모으고 뜻을 맞추고 시험할 문장으로 쓰고 변경 이력까지 잇는 과정을 읽는다. 수업당 정원 8명과 수업 시작 24시간 전까지의 일반 취소 허용은 이 절의 가상 설명값이며, 실제 업종의 법적 취소·환불 기준을 뜻하지 않는다.

이미 배운 약속에서 출발한다

이해관계자는 결정에 영향을 주거나 받는 주체이며, 요구사항은 필요·계약·제약 등에서 나와 시스템이 충족해야 하는 검증 가능한 조건이었다(이해관계자·문제·요구사항). 기능·품질·제약은 각각 행동, 수행 수준, 선택 경계를 묻는다(기능·품질속성·제약). 여기서는 그 정의를 다시 만들지 않고 여러 요구를 함께 다듬고 유지하는 일로 넓힌다.

방법론 안에서 이번 활동의 위치를 찾는다

개발 방법론은 목표와 제약에 맞춰 활동·역할·산출물·검토와 변경 규칙을 조직하는 체계였다(예측형·반복형·점증형·애자일). 형상 기준선은 그 체계에서 변경을 통제할 산출물의 특정 버전을 뜻했다(예측형·반복형·점증형·애자일). 이제 그 안에서 무엇을 만들기로 할지와 그 약속의 변경을 다룬다.

요구공학은 문서 작성부터 시작하는 일이 아니다

요구공학(Requirements Engineering, RE)은 필요한 시스템을 함께 이해하기 위해 요구의 근거를 찾고 분석·명세·확인하며, 합의된 요구와 관련 산출물의 추적·변경을 체계적으로 관리하는 활동이다. 여기서 목표는 문장 수가 아니라 필요한 것을 잘못 만들 위험을 줄이는 데 있다. 요구를 문서로 남기는 일은 중요하지만, 빠진 당사자와 모순된 조건을 그대로 두고 예쁘게 정리하면 목표를 이루지 못한다.

공방에서는 고객의 편의, 강사의 준비 비용, 운영자의 처리 책임이 입력이다. 결과는 “쉽게 취소”라는 녹취 한 줄이 아니라 허용 조건·거부 결과·책임자·수용 증거가 연결된 약속이다. 개발 방법론은 일을 조직하는 더 넓은 체계이고, 요구공학은 그 안에서 무엇을 만들고 바꿀지를 책임지는 활동이라는 차이를 유지한다.

쉽게 말하면: 같은 약속을 만들고 바뀐 이유를 잃지 않는다

사람마다 원하는 것을 먼저 듣고, 서로 다른 뜻을 맞춘 뒤, 무엇이면 약속을 지킨 것인지 함께 정한다. 만든 결과가 그 약속과 맞는지 찾아갈 수 있게 하고, 약속을 고칠 때에는 다른 사람과 결과에 미칠 영향도 확인한다. 공방의 취소 버튼보다 취소할 수 있는 조건과 결과를 먼저 합의하는 이유가 여기에 있다.

이 절의 길: 말에서 근거 있는 판단까지

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

요구 문서의 연결은 통과 증거가 아니다. 원천에서 조건을 도출하고 충돌을 분석하여 특정 판본을 합의한 뒤, 설계·시험 증거를 연결한다. 변경되면 영향받는 판본과 합의를 다시 확인한다.

도출·확인·변경의 연결을 말로 확인하기

그림의 순서를 다시 읽으면 사람·문서·현재 업무에서 후보 요구를 도출하고, 뜻·범위·우선순위를 분석하여 명세와 수용조건을 만든다. 검토 후 승인한 특정 버전을 설계·구현·확인 증거에 연결하며, 변경 영향이 생기면 승인 판단으로 돌아온다.

화살표는 한 번만 진행하는 일정표가 아니다. 검토하다가 취소 시각의 기준이 빠졌음을 발견하면 당사자에게 되묻고 명세를 고친다. 요구에서 설계·시험으로 내려가는 관계뿐 아니라 결과에서 그 근거 요구로 돌아오는 관계도 유지해야, 변경할 때 어느 약속과 증거가 영향을 받는지 찾을 수 있다.

요구 도출: 말하지 않은 조건도 찾는다

요구 도출(requirements elicitation)은 사람·문서·기존 시스템과 관찰에서 요구의 근거를 찾아 드러내고 정리하는 활동이다. 이미 적힌 목록을 복사하는 수집보다 넓다. 당사자가 너무 당연하게 여겨 말하지 않은 조건을 찾아 묻거나, 서로 다른 해법을 살피며 새로운 필요를 구체화할 수도 있다.

고객에게 “취소 버튼이 필요하세요?”만 물으면 대부분 그렇다고 답한다. “지난번 취소하려던 때 어떤 일이 있었나요?”라고 물으면 강의 시작 시각을 잘못 봤거나 전화 연결이 되지 않았다는 사실이 나온다. 원하는 버튼과 해결하려는 문제를 나눠 기록해야 안내 개선·온라인 취소·운영 지원이라는 대안을 비교할 수 있다.

연락하기 쉬운 사람보다 빠졌을 때 손해 보는 사람을 찾는다

공방의 요구 담당자는 고객 한 명과 사장만 만나고 끝내지 않는다. 예약을 변경하는 고객, 재료를 준비하는 강사, 예외 요청을 처리하는 운영자, 외부 결제 연계 담당자에게 각각 다른 질문을 한다. 화면 이용이 어려운 고객이나 야간 문의를 처리하는 사람의 경험도 대표자를 통해 확인할 필요가 있다.

명단에는 역할·관심사·영향·필요한 전문성·결정할 수 있는 범위와 확인 시점을 적는다. 의견을 제공하는 사람과 정책을 승인하는 사람은 같지 않을 수 있다. 개인정보를 많이 수집하는 명단이 좋은 명단은 아니며, 연락·참여에 필요한 범위와 접근 책임도 정한다.

예를 들어 강사는 재료 준비 시점을 설명할 수 있지만 계약상 환불 의무를 혼자 면제할 수 없다. 의견이 아직 확인되지 않은 집단은 “의견 없음”으로 채우지 않고 미확인 이유·대체 자료·확인 책임자를 남긴다.

기법은 알고 싶은 사실에 맞춰 섞는다

한 기법이 모든 질문에 답하지 못한다. 인터뷰는 말의 이유를 깊이 묻기 좋지만 기억에 의존하고, 관찰은 평소 말하지 않던 행동을 보게 하지만 짧은 관찰에서 드문 사건이 안 보일 수 있다. 그래서 같은 결론을 다른 종류의 자료로 대조한다.

설문은 많은 사람에게 같은 질문을 비교할 때 유용하지만, 무엇을 물어야 할지조차 모르면 빠진 질문을 발견하기 어렵다. 공동 검토 전에 당사자별 이야기를 듣고, 마지막에 같은 시각 사례를 함께 판정하게 하면 묻기·관찰·자료 확인이 서로 보완된다. 표는 이 공방을 위해 구성한 판단 예이며 기법의 고정 서열이 아니다.

기록에서 규칙으로 건너뛸 때의 주의

데이터 요구 분석에서는 실제 기록과 자료를 대조하되, 현재 데이터에 반례가 없다고 미래의 업무규칙까지 증명한 것은 아니라고 배웠다(데이터 요구사항·업무규칙·용어: 무엇을 사실로 남길 것인가). 같은 원칙을 공방의 기존 취소 장부에도 적용한다.

현재 장부의 흔적을 미래 규칙으로 바꾸지 않는다

운영자가 “지금까지 취소는 하루에 한 번 몰아서 처리했어요”라고 설명했다고 하자. 이것은 현재 업무의 사실이지 새 시스템도 반드시 하루 한 번만 처리해야 한다는 의무가 아니다. 전화로만 받던 사정 때문인지, 결제회사의 처리 제약 때문인지, 검토가 필요한 예외 때문인지 원인을 나눠 묻는다.

여기서도 한 달의 처리 기록에 기한 이후 취소가 없다는 사실만으로 기한 이후 고객 문의를 시스템에서 없애도 된다고 결정할 수 없다. 일반 취소와 예외 상담의 책임을 나눠 확인해야 한다.

2. 필요한 것·이미 제한된 것·아직 모르는 것을 나눈다

기능·품질·제약의 구분은 앞에서 배운 세 질문을 실제 후보 목록에 적용하는 일이다. “고객이 내 예약을 취소한다”는 기능 후보이고, “혼잡 중에도 결과를 정한 시간 안에 받는다”는 품질 후보다. “이미 계약한 결제 연계 규격을 따라야 한다”는 근거가 확인되면 제약이며, “특정 화면 라이브러리를 쓰면 편할 것 같다”는 개발자의 대안이다.

분류표의 칸은 절대적인 벽이 아니다. 고객의 예약 정보 보호라는 품질 목표에서 “본인 소유가 아닌 예약의 취소를 거부한다”는 구체적인 기능 요구가 나온다. 서로 연관된 요구에 관계를 붙이지 않고 기능·비기능을 따로 보관하면 보안 목표를 지키는 실제 행동이 빠질 수 있다.

가정은 확인 전의 믿음이고, 미결 항목은 남은 질문이다

요구의 가정(assumption)은 요구를 해석하거나 실현할 때 사실이라고 잠정적으로 두지만 아직 확인이 필요한 조건이다. “기존 결제회사는 취소 결과를 다시 조회할 수 있다”는 가정에 근거가 없으면, 성공 응답을 못 받은 상황의 요구와 설계도 불안정하다. 가정에는 확인 책임자·기한·확인 자료와 틀렸을 때 영향을 받는 요구를 붙인다.

미결 항목(open issue)은 합의하거나 조사해야 할 질문이 아직 닫히지 않은 상태로 기록된 항목이다. 공방의 “수업 하루 전까지”는 어느 시각·시간대·경계 포함 여부를 뜻하는지 미결일 수 있다. “추후 협의”를 삭제한다고 문제가 해결되지 않으며, 임의의 숫자로 빈칸을 채우면 미확인을 확정 사실로 바꾸는 더 큰 문제가 된다.

형상 기준선의 변경 통제 의미는 앞에서 배웠다(예측형·반복형·점증형·애자일). 확인 전 가정에 기대는 요구를 개발 약속으로 삼을 때는 의존성과 허용 위험을 드러내야 한다. 기본은 중요한 가정을 확인한 뒤 기준선으로 삼는 것이며, 확인할 수 없으면 범위·일정·해법을 다시 결정한다.

충돌의 원인이 다르면 해결도 달라진다

요구 충돌(requirements conflict)은 여러 요구를 함께 만족할 수 없거나 관련 당사자가 같은 요구의 해석·채택에 동의하지 않는 상태다. 고객은 “24시간 전이면 취소 가능”이라고 읽고 강사는 “하루 전 0시부터 취소 불가”라고 읽었다면 먼저 의미를 맞춘다. 같은 말의 해석이 다를 뿐인데 편의를 몇 점으로 채점해도 문제가 풀리지 않는다.

뜻을 맞춘 뒤에도 고객은 더 늦은 취소를, 강사는 더 이른 준비 확정을 원할 수 있다. 이때는 실제 재료 손실, 다른 고객의 예약 기회, 처리 비용과 계약상 의무를 확인하고 일반 취소·예외 상담을 나누는 대안을 비교한다. 적용 의무는 임의의 점수나 다수결로 지울 수 없고, 허용된 선택 범위 안에서 권한 있는 책임자가 근거와 남은 반대를 기록한다.

우선순위는 중요도와 이번 전달 순서를 함께 보되 섞지 않는다

요구 우선순위(requirements priority)는 정한 목표·위험·제약 안에서 요구를 상대적으로 먼저 다루거나 전달할 순서를 판단한 결과다. 고객의 예약 목적에 꼭 필요한 기능이면서 선행 결제 연계 확인이 필요한 요구라면, 가치가 높다는 이유만으로 준비 없이 먼저 개통할 수는 없다. 업무 가치, 실패 피해, 기한, 비용과 선행 의존성을 함께 본다.

공방은 정원 초과 방지와 취소 결과의 정확한 안내를 개통 전 필수로 두고, 고객 취향에 따른 수업 추천은 뒤로 미룬다. 모두에게 1순위를 주면 제한된 기간 안에 무엇을 포기할지 결정할 수 없다. 반대로 구현하기 쉬운 기능부터 채우면 추천 화면은 멋진데 예약 약속은 깨지는 제품이 된다.

결정 장부에는 채택·보류·기각, 비교 기준, 근거, 결정권자와 다시 볼 조건을 남긴다. 보류는 삭제가 아니고 요구의 필요성 판단과 이번 전달 범위 판단도 구분한다. 새로운 의무나 위험이 확인되면 이전의 낮은 우선순위도 재평가한다.

같은 예약 한 건으로 해석의 차이를 끝낸다

이 절의 가상 수업 W101은 한국 표준시 9월 20일 14시 시작이다. 운영 책임자가 확인한 일반 취소 규칙을 “요청접수시각 ≤ (수업시작시각−24시간)이면 허용”으로 정했다고 하자. 즉 마감시각과 같거나 이르면 허용한다. 그러면 9월 19일 14시 정각은 허용이고 14시 00분 01초는 일반 취소 거부다.

여기서 확인한 것은 정책 경계이지 서버 한 대의 구현이 아니다. 고객 휴대전화 시계와 서버의 판단 시각이 다를 수 있으므로 화면 안내와 판정 시각도 함께 정해야 한다. 결제 처리나 법적 예외까지 이 두 시각 예로 증명하지 않으며, 별도로 확인할 요구에 연결한다.

요구 분석은 후보를 작은 질문으로 다시 나누는 일이다

요구 분석(requirements analysis)은 도출한 요구의 뜻·필요성·관계·충돌·실현 가능성을 살펴 일관된 이해와 결정으로 다듬는 활동이다. 도출과 분석은 실제로 오간다. 분석 중 “취소 완료”가 좌석 반환인지 결제 환불까지인지 모호하면 다시 담당자와 연계 자료를 확인한다.

공방의 “취소하면 바로 끝난다”는 말을 예약 상태 변경, 좌석 재사용, 결제 취소 요청, 결과 안내라는 서로 확인할 수 있는 질문으로 나눈다. 각 결과의 책임과 실패 상태를 정하되, 데이터 저장구조나 외부 결제 성공을 임의로 가정하지 않는다. 사람의 업무와 소프트웨어의 책임, 외부 시스템과의 경계가 드러나면 다음 모델링 절에서 기능·정보·상태를 표현할 입력이 된다.

여기까지의 결론: 후보 목록은 출발점이다

도출은 숨은 조건을 찾아내고, 분석은 서로 다른 뜻·이익·가정을 실행 가능한 약속으로 다듬는다. 중요한 것은 기법 이름의 개수가 아니라 누가 빠졌는지, 무엇이 미확인인지, 어떤 근거로 누가 결정했는지를 드러내는 것이다. 이제 이 결정을 다른 사람이 같은 뜻으로 읽고 확인할 수 있는 문장으로 바꾼다.

명세는 남이 읽고 같은 판정을 내릴 수 있게 쓰는 일이다

요구 명세(requirements specification)는 요구를 정해진 기준에 맞게 체계적으로 표현한 결과이며, 문맥에 따라 그렇게 표현하는 활동도 뜻한다. 이 절에서는 활동을 “명세한다”, 기록한 결과를 “요구 명세”로 구분한다. 소프트웨어의 기능·품질·외부 연결·제약을 묶어 기록한 소프트웨어 요구 명세서(Software Requirements Specification, SRS)는 소프트웨어가 충족해야 할 요구를 조직해 놓은 산출물이다. 파일 이름이나 특정 양식을 썼다는 사실만으로 충분한 명세가 되지는 않는다.

명세할 때는 판단할 의무를 구분하고, 대상·발생 조건·기대 결과·경계를 적는다. 이유는 요구 문장과 연결하되 의무와 뒤섞지 않는다. 공방의 “취소가 편해야 한다” 대신 “본인 소유의 확정 예약에 대해 허용 기한 안에 취소 요청을 받으면, 시스템은 해당 예약을 취소 상태로 바꾸어야 한다”라고 쓰면 판정할 행동이 드러난다.

취소 규칙을 작은 명세 네 개로 만든다

이 사례에서 “요청 수신”은 서버가 요청을 받은 시각이고 모든 표시 시각은 한국 표준시다. “확정”과 “취소”는 공방 예약의 상태이며, 이 절에서 취소 상태가 결제 환불 완료까지 뜻하지는 않는다. 아래 문장들은 일반 취소만 다루는 가상 정책 v1의 일부다.

1. R-CAN-01 허용: 시스템은 본인 소유의 확정 예약에 대해 요청접수시각 ≤ (수업시작시각−24시간)인 취소 요청을 받으면, 해당 예약을 취소 상태로 바꾸어야 한다.
2. R-CAN-02 기한 거부: 시스템은 본인 소유의 확정 예약에 대해 수업 시작 24시간 전보다 늦게 일반 취소 요청을 받으면, 예약 상태를 유지하고 기한 경과와 운영자 문의 방법을 알려야 한다.
3. R-CAN-03 반복 요청: 시스템은 이미 취소된 본인 예약에 다시 일반 취소 요청을 받으면, 예약과 좌석 수를 다시 변경하지 않고 기존 취소 결과를 알려야 한다.
4. R-CAN-04 권한 거부: 시스템은 다른 고객 소유 예약에 대한 취소 요청을 받으면, 그 예약을 변경하지 않고 접근 거부 결과를 알려야 한다.

한 요구의 거부 결과에는 상태 유지와 안내가 함께 필요하므로 무조건 동사 하나로만 자르는 것은 목표가 아니다. 독립적으로 바뀌고 확인할 의무는 나누되, 같은 거부 행위의 결과가 흩어져 의미를 잃지 않게 한다. 예약 취소에 따라 좌석을 다시 쓸 수 있게 하는 요구와 외부 결제 처리 요구는 별도 식별자로 연결하며 “취소 완료” 한 문장에 몰래 포함하지 않는다.

품질 문장은 분모와 실패도 드러내야 한다

조회 속도는 취소 기능과 다른 조건으로 적는다. 공방은 예시 시험 환경 E1을 “고정한 소프트웨어 버전·서버 자원·예약 데이터 1만 건·동시 조회 사용자 100명·정상 외부 연결”로 정하고, 측정 구간 동안 시험기가 보낸 유효한 예약 조회 요청 1,000건을 분모로 삼기로 했다고 하자. 시작은 시험기가 요청을 보낸 때, 끝은 올바른 결과 전체를 받은 때다.

품질 요구 Q-01을 “E1에서 그 1,000건 중 95% 이상이 2초 이내에 올바른 조회 결과를 받아야 한다”로 정한다. 시간 초과·오류·결과 불일치는 분모에 남고 성공 분자에는 넣지 않는다. 940건만 2초 안에 올바르게 끝나고 40건은 지연, 20건은 시간 초과라면 충족률은 940/1,000=94%이므로 미달이다.

시간 초과 20건을 빼서 940/980≈95.92%로 보고하면 같은 실패를 성공처럼 보이게 한다. 이 숫자는 가상 읽기 예이며 실제 성능 시험 결과가 아니다. 부하·측정 위치·데이터·네트워크 조건이 바뀌면 별도 범위를 확인해야 하고, 이 한 시험으로 모든 운영시간의 서비스 수준이나 무결함을 보장하지 않는다.

식별자 옆에 판단에 필요한 맥락을 붙인다

요구 속성(requirements attribute)은 요구의 문장 외에 그 요구를 구분·판단·관리하기 위해 붙이는 설명 정보다. 예를 들어 R-CAN-01에는 문구뿐 아니라 버전, 제안 출처, 이유, 담당자, 상태, 우선순위, 수용조건, 관련 요구와 변경 이력이 붙는다. 수업 정원 8명처럼 사례에서 선택한 값도 숫자의 근거와 변경 책임을 잃지 않아야 한다.

출처는 “회의”가 아니라 어느 일자의 어떤 결정인지 찾아갈 수 있어야 한다. “승인됨”도 누가 어떤 버전과 범위를 승인했는지 없으면 다음 사람이 재현할 수 없다. 반면 모든 조직의 모든 항목을 복사하면 실제 유지하지 않는 빈칸이 늘어나므로, 필요한 판단과 추적에 쓰는 속성을 정하고 관리 책임을 둔다.

짧은 사용자 이야기와 자세한 명세는 대체재만은 아니다

사용자 스토리(user story)는 사용자의 관점에서 필요한 능력과 그 이유를 짧게 표현하여 협의를 이어 가는 요구 표현이다. “예약 고객으로서 전화가 안 되는 시간에도 내 예약을 취소하고 결과를 알고 싶다”는 공방의 이야기다. 왜 필요한지 기억하기 좋지만, 이 문장 하나에 기한·권한·중복 요청·결제 실패의 판정까지 들어 있지는 않다.

짧은 이야기에는 관련 명세와 수용조건을 연결하고, 상세 기록은 이름과 버전을 가진 하나의 기준으로 관리한다. 자연어는 업무 담당자가 읽기 쉽고, 정해진 문장 틀은 빠진 조건을 찾기 좋으며, 모델은 관계나 상태 흐름을 한눈에 보게 한다. 그러나 빈칸을 채웠다고 내용이 맞는 것은 아니고 그림만으로 모든 품질·제약을 설명할 수도 없다.

애자일에서 짧은 대화와 반복 확인을 쓴다는 이유로 요구 명세나 변경 기록이 사라지지 않는다. 반대로 모든 화면의 위치까지 처음부터 고정하면 확인되지 않은 설계안을 약속으로 굳힐 수 있다. 피드백을 얻는 속도, 계약·위험, 다른 팀에 인계해야 할 정도에 맞춰 상세 수준을 정한다.

검사할 것은 문장과 제품, 두 층위에 있다

검증은 정해진 명세·설계·표준 충족을, 확인은 실제 필요 충족을 묻는다는 구분은 검증·확인·운영 피드백에서 배웠다. 여기서는 제품이 나오기 전 요구 자체도 실제 필요와 비교하며, 구현 뒤에는 그 요구의 충족 증거를 다시 본다. 두 활동의 대상과 판단기준을 적어 두어 같은 “검증”이라는 말을 썼다고 같은 일을 했다고 보지 않는다.

3. 잘 쓴 문장과 필요한 제품을 함께 확인한다

요구 타당성 확인(requirements validation)은 요구와 관련 산출물이 실제 필요를 적절하게 표현하고 정한 품질 기준을 만족하는지 확인하는 활동이다. 요구공학 문헌에서 이 표현은 요구 문장의 명확성·일관성·검증 가능성 점검까지 넓게 포함한다. 이 절은 문서의 품질을 살피는 일과 필요의 적절성을 살피는 일을 모두 수행하되, 앞에서 배운 제품 검증·확인의 판단기준을 바꾸지 않는다.

R-CAN-01이 시각과 상태를 명확하게 써도 공방의 실제 운영·권리 조건과 맞지 않으면 잘못된 요구다. 반대로 모두 원하는 취소 기능이라도 “적절히 빨리”라는 문구만 있으면 충족 여부를 판정할 수 없다. 그래서 업무 담당자는 필요·정책·예외를, 개발·운영 담당자는 실현 가능성과 영향·관찰 방법을, 시험 담당자는 구체적인 입력·판정 기준을 다른 관점에서 검토한다.

한 문장과 요구 집합에는 서로 다른 질문을 한다

문장 하나가 완전하다는 말과 제품 범위가 완전하다는 말은 다르다. R-CAN-01의 허용 조건을 정확하게 써도 권한 거부나 기한 경과가 목록에 없으면 요구 집합에 누락이 있다. 반대로 목록이 길어도 같은 취소 시각을 서로 다르게 적으면 일관되지 않다.

누락 확인에는 사용자 종류, 입력·출력, 정상·예외·장애, 시간 경계, 보안·성능·운영·외부 연계처럼 범위를 바꿔 가며 질문한다. 어떤 목록도 아직 발견하지 못한 모든 요구가 없다는 수학적 증명이 되지는 않는다. 조사한 범위와 미결 조건을 명시하고 새로운 근거가 나오면 다시 연다.

검토는 참석자 명단이 아니라 결함을 닫은 기록을 남긴다

워크스루(walkthrough)는 작성자가 산출물의 사례와 흐름을 설명하면서 참여자가 문제를 찾는 검토 방식이다. 공방에서는 고객의 요청 시각을 바꾸어 가며 취소 결과를 함께 읽는다. 인스펙션(inspection)은 관련 전문가들이 정해진 판정 기준과 공식 절차에 따라 산출물을 체계적으로 검사하는 검토 방식이다. 역할·사전 준비·결함 기록·후속 조치도 절차 안에서 정한다. 이름보다 실제 수행 규칙과 남은 결함을 확인하는 것이 중요하다.

작성자의 설명을 따라가면 빠르게 맥락을 공유할 수 있지만, 설명에 없는 모호함이 가려질 수 있다. 그래서 관련자가 문구를 먼저 독립적으로 읽은 뒤 서로 다른 해석을 비교하고, 결함을 찾는 시간과 해결안을 정하는 시간을 구분한다. 수정 뒤에는 지적한 사람이 의도대로 고쳐졌는지 확인하고 영향받은 다른 요구도 다시 본다.

시제품은 날짜 안내나 취소 결과를 고객이 어떻게 이해하는지 보여 주지만, 보기 좋았다는 반응이 성능·보안·전체 예외를 증명하지는 않는다. 정적 검토, 작은 사례 평가와 구현 뒤 시험을 각각 어떤 질문의 증거로 사용할지 정한다.

수용조건과 인수 결정은 시험 이름과 다르다

앞서 배운 수용기준, 곧 수용조건은 결과를 받아들일 판정 조건이었다(이해관계자·문제·요구사항). 여기서는 그 조건과 실제로 받아들이는 판단을 구분한다. 인수(acceptance)는 합의한 범위와 조건에 대한 증거를 바탕으로 권한 있는 이해관계자가 결과물을 받아들일지 결정하는 활동이다. 이 절에서 인수는 소프트웨어 결과 수용이며 함수가 받는 인수나 기업 인수와는 다른 뜻이다.

R-CAN-01의 수용조건에는 본인 소유·확정 상태·경계 시각의 입력과 기대 상태가 필요하다. 그러나 이 항목 하나가 통과했다고 전체 서비스를 인수할 수는 없다. 계약 범위, 다른 기능과 품질·제약, 운영 준비, 남은 결함과 예외 승인 범위를 함께 판단해야 한다.

“시험을 작성했다”, “시험을 실행했다”, “통과했다”, “권한자가 인수했다”는 서로 다른 상태다. 증거가 없으면 통과로 세지 않고, 조건부 수용이 허용되는 경우에도 남은 항목·책임·기한·제한을 기록한다. 법적 의무나 안전 한계를 내부 승인만으로 면제할 수는 없다.

취소 요구의 읽기 시험표

다음은 실제 실행 결과가 아니라, 무엇을 관찰해야 할지 미리 작성한 가상 판정표다. 모두 W101 수업 시작 9월 20일 14시를 기준으로 하고, 각 행은 독립된 초기 상태에서 시작한다.

T-01의 성공 화면만 확인해서는 실제 상태 변경을 확인했다고 할 수 없다. T-03도 같은 안내가 나왔다는 이유만으로 좌석 수가 두 번 늘지 않았음을 단정할 수 없다. 결과 화면과 상태 기록 등 요구가 말한 결과에 맞는 증거를 함께 확인하며, 외부 결제 처리의 중복 여부는 관련 요구와 별도 증거로 이어야 한다.

기준선은 고칠 수 없는 문서가 아니었다

형상 기준선은 검토 뒤 변경을 통제하기로 한 산출물 집합의 특정 버전이었다(예측형·반복형·점증형·애자일). 요구 집합에도 이 원리를 적용하면 어떤 요구와 판정 기준을 만들기로 했는지 고정하고 이후 차이를 추적할 수 있다. 기준선을 바꾸는 것은 가능하지만, 예전 내용을 몰래 덮어쓰는 것과는 다르다.

4. 연결은 요구의 생애 동안 유지한다

요구 관리(requirements management)는 요구와 관련 산출물의 저장·상태·버전·추적·변경을 유지하는 활동이다. 요구를 처음 정한 날부터 시작하며 개발 완료 뒤에도 운영 변경에 이어진다. 공방에서는 제안, 검토 중, 승인된 특정 버전, 구현·확인 상태를 구분해 “문서에 있다”를 “만들기로 승인했다”나 “작동을 확인했다”로 읽지 않게 한다.

승인 범위를 정할 때에는 요구 문장뿐 아니라 연결된 용어·가정·판정 조건·미결 항목의 처리도 함께 검토한다. 상태 이름과 허용 전환·권한은 프로젝트가 명시하고, 요구 승인과 실행 결과의 상태를 구별한다. 중요한 미결 조건이 남으면 담당자와 기한을 표시하거나 영향을 받는 범위의 승격을 보류하며, 이름만 승인으로 바꾸어 결함을 숨기지 않는다.

양방향 추적은 링크 개수가 아니라 이유와 증거의 연결이다

요구 추적성(requirements traceability)은 요구의 출처와 관련 요구·설계·구현·확인 증거 사이 관계를 찾아갈 수 있는 성질이다. 양방향 추적성(bidirectional traceability)은 상위 필요에서 하위 요구와 실현·확인 결과로 내려가고, 그 결과에서 근거 요구와 필요로 거슬러 올라갈 수 있는 성질이다. 개인정보 책임추적성이나 분산 요청의 실행 경로 추적과 대상이 다르다.

요구 추적 행렬(Requirements Traceability Matrix, RTM)은 요구와 관련 산출물의 연결을 행과 열로 나타낸 기록이다. 도구의 모양보다 요구 ID·버전, 연결 대상과 관계 의미가 중요하다. “관련 있음”만 수백 개 붙이기보다 무엇을 실현하고 무엇을 확인하는지 좁게 연결한다.

공방의 필요 N-01에서 취소 요구 R-CAN-01로 내려가고, 그 요구가 취소 판정 설계 D-01과 T-01의 기대 결과로 이어진다면 왜 이 판정이 있는지 되짚을 수 있다. T-01이 R-CAN-01을 확인한다는 링크만으로는 시험의 내용이나 실행 성공을 증명하지 못한다. 추적 관계의 적절성과 실제 증거의 충족 상태는 따로 검토한다.

네 줄을 연결하면 빠진 책임이 보인다

이 절에서 D-01은 취소 허용 판정을 맡을 설계 책임, D-02는 거부 안내, D-03은 반복 처리, D-04는 소유자 접근 판정을 맡을 책임의 식별자다. 구체적인 기능 모델이나 클래스 구조를 설계한 결과가 아니라, 다음 설계에서 반드시 배정할 요구 책임이다. I-01부터 I-04는 그 책임을 구현하는 산출물을 연결할 자리이며 아직 코드가 작성됐다는 뜻이 아니다.

N-03처럼 조사와 위험 분석에서 추가로 도출된 필요도 근거와 담당자가 확인해야 한다. 인터뷰 문장과 일대일 대응하지 않는다는 이유로 무조건 삭제하지 않으며, 반대로 설계자가 붙인 기능을 근거 없는 상태로 승인하지도 않는다. 상위 필요를 여러 하위 요구가 함께 충족한다면 부분 기여를 적고 모두 합쳐 빠짐없이 충족하는지 본다.

추적률 100%가 필요 충족률 100%는 아니다

표의 승인 대상 요구 4개 모두에 설계 책임과 작성된 확인 조건이 연결되었다면 “설계·확인 조건 연결률”은 4/4=100%다. 하지만 현재 실행하여 통과한 증거는 없으므로 “실행 증거 충족률”을 100%로 보고할 수 없다. 분모의 대상·버전·범위와 분자의 상태를 지표 이름 옆에 적어야 한다.

요구가 개정되었는데 예전 시험을 그대로 연결하거나 엉뚱한 시험 하나를 모든 요구에 연결해도 표는 가득 찰 수 있다. 반대로 연결 없는 시험은 필요한 새 위험 확인인지 불필요한 검사인지 판단하고, 근거 없는 구현 기능은 상위 필요나 정당한 파생 이유를 찾아 검토한다. 행의 존재, 의미 있는 연결, 실행한 증거, 인수 결정이라는 서로 다른 층위를 섞지 않는다.

변경 영향 분석: 바꿀 것과 바꾸지 않을 것의 근거를 찾는다

요구 변경 영향 분석(change impact analysis)은 제안한 요구 변경이 다른 요구·설계·구현·시험·운영·일정·비용·위험에 주는 영향을 확인하여 변경 판단의 근거를 만드는 활동이다. 바뀐 문장만 읽지 않고 양방향 추적과 담당자의 지식을 함께 사용한다. 연결 장부가 빠졌을 수 있으므로 링크 밖의 외부 연계·과거 데이터·고객 안내도 점검한다.

변경 요청에는 이유와 목표, 대상 요구·현재 버전, 원하는 차이, 미변경 시의 피해, 대안, 영향과 책임자를 적는다. 검토 권한을 가진 주체가 승인·보류·기각하고, 승인된 경우 요구와 관련 산출물의 새 버전을 반영해 다시 확인한다. 결정 통지와 실제 반영·증거 확인까지 추적해야 승인 메일만 있고 운영은 옛 규칙인 상태를 막을 수 있다.

취소 기한을 24시간에서 12시간으로 바꾸려 한다면

공방이 변경 요청 CH-07을 받아 일반 취소를 수업 시작 12시간 전까지 넓히려 한다고 하자. 먼저 허용 R-CAN-01과 거부 R-CAN-02가 함께 영향을 받으며, 안내문·운영자 처리 절차·관련 설계 D-01/D-02·구현 I-01/I-02·시험 T-01/T-02도 바뀐다. 반복 요청과 소유자 보호 요구가 그대로라는 판단도 자동으로 하지 않고 새 흐름에서 계속 지켜지는지 확인한다.

정책 v2를 한국 표준시 9월 15일 00시 이상에 새로 확정한 예약에만 적용하고 이전 예약은 v1을 유지하기로 가상 결정했다면, 예약마다 적용 정책 버전을 알아야 한다. 수업 W101에 속한 예약 R501은 9월 14일 10시에 확정해 v1을 적용하고, 같은 수업의 예약 R502는 9월 16일 10시에 확정해 v2를 적용했다고 하자. R501은 원래의 9월 19일 14시 경계가 유지되고, R502는 9월 20일 02시가 12시간 경계다. 따라서 정책 숫자 하나를 공통 설정에서 바꾸는 것으로 끝낼 수 없다.

이는 특정한 법적 변경 방식의 권고가 아니라, 적용 대상을 정하지 않은 정책 변경이 왜 과거 약속을 바꾸는지 보여 주는 예다. 실제 효력·고지·동의·예외는 적용 계약과 법령을 담당자가 확인해야 하며, 이 사례는 그 의무를 충족했다고 주장하지 않는다.

변경의 일부만 직접 완성해 보자. R501과 R502가 모두 아직 확정 상태이고 각 소유자가 9월 19일 20시에 요청했다면 어느 예약을 허용할까? 먼저 예약의 적용 버전을 읽는다. R501의 v1 마감 9월 19일 14시는 이미 6시간 지났으므로 상태를 유지하고 기한 경과를 알린다. R502의 v2 마감 9월 20일 02시는 아직 6시간 남았으므로 취소로 바꾼다. 두 예약을 모두 허용했다면 수업이 같다는 사실을 정책 버전이 같다는 뜻으로 잘못 바꾼 것이다. 같은 예약 한 건으로 해석의 차이를 끝낸다의 경계 비교와 취소 기한을 24시간에서 12시간으로 바꾸려 한다면의 적용 대상 구분을 복습하고, 새 시험표에는 예약·정책 버전·요청시각·기대 상태를 함께 적는다. 승인 기록만 갱신하거나 시간값 하나만 바꾸면 이 차이를 재확인할 수 없다.

바꾸지 않는 것도 비용이고, 모두 적는 것도 비용이다

변경을 금지하면 잘못된 요구나 새로 확인한 필요를 유지할 수 있고, 아무 요청이나 즉시 반영하면 일정·일관성·시험 근거가 무너질 수 있다. 비용·위험이 큰 변경은 근거와 영향 확인을 더 두텁게 하고, 범위가 좁아도 요구 버전과 판정 기준의 연결은 잃지 않는다. 반복 개발에서는 가까운 전달 범위를 더 구체화하면서 같은 통제를 짧게 반복할 수 있다.

추적도 모든 문장과 파일을 서로 연결하는 방식이면 유지 비용이 너무 커진다. 중요한 약속, 변경 경계와 확인 증거를 구분하는 식별 단위를 정하고 중복 원문 대신 기준 위치를 참조한다. 자동 연결은 후보를 찾는 데 도움이 되지만, 단어가 같다는 이유로 의미 일치·필요성·시험 통과를 승인할 수는 없다.

실패가 보이면 요구의 어느 부분을 다시 열지 정한다

개통 직전에 고객 안내는 24시간, 서버는 12시간으로 바뀌었다면 단순 오타로 치부하지 않는다. 적용 대상과 변경 버전을 확인하고, 영향받은 요구·구현·안내·시험을 맞춘 뒤 다시 검토한다. 이미 고객 약속에 영향을 주었다면 운영 책임자가 적용 범위·조치·고객 안내와 필요한 검토를 따로 결정해야 한다.

운영에서 취소 실패가 증가해도 요구가 틀렸는지, 구현이 명세를 어겼는지, 결제회사 연결이 바뀌었는지는 원인별로 다르다. 사건의 조건과 증거를 모아 필요·가정·요구·설계 중 바꿀 대상을 정한다. 숫자를 좋게 만들려고 실패 요청을 보고에서 빼거나 요구를 뒤늦게 낮춰 과거 실패를 통과로 바꾸면 개선의 근거가 사라진다.

다음 모델링 절에 넘길 것은 그림 이름이 아니라 결정된 뜻이다

이 절에서 정리한 요구는 다음 절의 기능모델·정적모델 설계에 입력이 된다. 공방의 요구에서 누가 어떤 입력에 어떤 결과를 얻는지, 어떤 정보와 규칙이 필요한지, 상태·시간·권한 조건이 어디서 달라지는지를 찾아 정리했다. 다음 절은 이 내용을 기능·구조·동작의 모델로 표현하고 서로 맞는지 확인한다.

예를 들어 R-CAN-01은 취소 요청과 결과라는 기능 책임을 요구하고, R-CAN-04는 고객과 예약의 소유 관계를 구분할 정보를 요구한다. 두 요구를 같은 “예약 처리” 상자에 넣는 것만으로 각각의 조건을 모델에 반영했다고 할 수 없다. 여기서 준비한 책임 식별자와 문장 연결은 모델 설계의 입력이며, 다음 절의 실제 기능·정적 모델 설계가 끝났다는 증거는 아니다.

독립 연습 — 같은 수업의 두 예약을 같은 규칙으로 판정해도 될까

다음은 본문 사례의 조건을 적용하거나 바꾼 자체 연습이다. 먼저 판단과 근거를 적고 풀이를 펼친다.

본문의 W101·R501·R502와 정책 적용 조건을 그대로 사용한다. 두 예약은 각각 본인 소유이며 아직 확정 상태다. 각 소유자의 요청이 한국 표준시 9 월 20 일 02 시 정각에 서버에 접수되었다. 추적표에는 두 요구와 시험조건 링크가 있지만 시험은 아직 실행하지 않았다.

• 예약별 정책·마감·시각 비교·기대 상태를 네 칸으로 쓰라.
• 시험 링크가 있다는 사실로 보고할 수 있는 것과 보고할 수 없는 것을 구분하라.

풀이와 오답 교정 보기

R501은 v1이며 마감이 9 월 19 일 14 시이므로 이미 12 시간 경과했다. 확정을 유지하고 기한 경과와 문의 방법을 알린다. R502는 v2이며 마감이 9 월 20 일 02 시로 요청시각과 같으므로 경계 포함 규칙에 따라 취소한다. 같은 W101을 가리켜도 적용 정책이 다르다. 추적표의 링크는 관계와 작성된 조건의 존재를 보여 주며 실행 성공이나 전체 인수를 보여 주지는 않는다.

두 예약을 같은 결과로 썼다면 정책 적용 대상, 정각을 거부했다면 경계 포함 규칙, 링크를 통과로 썼다면 연결률의 한계를 다시 대조한다.

5. 10점 문제: 정의 뒤에는 실제 판단기준을 쓴다

요구공학의 개념을 설명하고, 요구 명세의 품질 기준과 양방향 추적성의 관리상 의미를 제시하시오.

이 문제는 교재가 자체 작성한 10점 연습문제이며 실제 기출 원문이 아니다. “개념”, “품질 기준”, “관리상 의미”의 세 요구를 모두 다루어야 한다. 활동 이름만 나열하지 말고, 개별 문장과 요구 집합의 품질 차이 및 추적 링크가 통과 증거는 아니라는 경계를 짧게 붙인다.

10점 풀이와 답안 구성 보기

10점 답안의 실제 목차

1. 요구공학의 목적과 도출·분석·명세·확인·관리의 관계
2. 개별 요구와 요구 집합의 품질 기준 및 취소 시각 사례
3. 양방향 추적의 출처–요구–설계–확인 관계와 변경·누락 통제
4. 추적 연결과 실행 증거·인수 판단의 구별

10점 도식: 같은 약속의 근거와 결과를 잇는다

화살표의 방향과 조건을 따라 연결을 읽습니다.

양방향 선은 양쪽에서 추적할 수 있는 연결이다. 자료를 주고받는 실행 순서나 시험 통과를 뜻하지 않는다. 각 문장의 품질과 요구 집합의 누락·모순을 함께 점검한다.

양방향 추적선은 관계를 양쪽에서 찾아간다는 뜻이다. 요구가 바뀌면 관련 결과를 재검토하지만, 연결선이 있다는 사실만으로 구현이나 시험이 성공한 것은 아니다.

10점 모범답안

1. 개념

요구공학은 필요한 시스템을 함께 이해하도록 요구의 근거를 도출하고 분석·명세·확인하며, 요구와 관련 산출물의 추적·변경을 관리하는 활동이다. 이해관계자의 말을 그대로 구현하는 것이 아니라 필요·조건·충돌을 검증 가능한 약속으로 전환하여 잘못된 제품을 만들 위험을 줄인다.

2. 명세 품질

개별 요구는 필요한 내용인지, 주체·조건·결과가 명확한지, 실현 가능하고 충족 여부를 판정할 수 있는지 확인한다. 요구 집합은 누락·모순·중복과 관련 산출물 사이 용어·버전 일관성을 점검한다. 예를 들어 “하루 전 취소”는 요청접수시각과 마감시각의 비교 및 경계 포함 여부를 명시하고, 허용뿐 아니라 기한·권한 거부와 반복 요청 결과도 정한다.

3. 양방향 추적

출처·상위 필요에서 요구의 특정 버전, 설계·구현과 확인 조건으로 내려가고 결과에서 근거로 거슬러 올라가도록 연결한다. 변경 시 관련 요구·설계·시험·운영 영향을 찾고, 연결 없는 필요나 구현·검사를 검토하여 누락과 근거 없는 추가를 통제한다.

4. 판단 경계

추적표의 연결은 그 관계가 존재한다는 기록이며 실제 실행·통과·인수의 증거와 구별한다. 요구 버전, 관계의 적절성, 실행 결과와 권한자의 수용 판단을 따로 확인해야 링크 수만 높은 형식적 관리가 되지 않는다.

25점 문제: 한 변경을 끝까지 관리한다

공방 예약 서비스를 개발하려 한다. 고객과 강사가 취소 기한을 다르게 해석하고, 운영 중 일반 취소 기한을 24시간 전에서 12시간 전으로 변경하려는 요청도 예상된다. 요구 도출부터 분석·명세·타당성 확인·변경 관리까지의 절차를 설명하고, 양방향 추적과 인수 근거를 포함한 관리방안을 제시하시오.

이 문제는 교재가 자체 작성한 25점 연습문제다. 단계 설명과 사례 적용, 변경 관리와 인수 근거를 모두 요구한다. 모델 이름을 나열해 요구의 누락을 채운 척하지 않고, 누가 어떤 자료와 조건으로 결정하고 그 결과를 어떻게 이어 확인하는지를 보여 준다.

25점 풀이와 답안 구성 보기

25점 답안의 실제 목차

1. 목표·이해관계자·업무 및 외부 의무의 범위와 도출 자료
2. 기능·품질·제약·가정 분리, 의미·이익 충돌 분석과 우선순위 결정
3. 취소 시각·정상·거부·반복 조건의 명세, 속성·버전과 품질 분모 및 모델 설계의 입력
4. 필요 적절성·문장 및 집합 품질 검토, 수용조건과 인수 증거
5. 필요–요구–설계·구현–확인 조건의 양방향 추적과 담당 책임
6. 24시간→12시간 변경의 영향·적용 대상·새 버전·재확인·통지
7. 누락·미결·버전 불일치 및 연결률을 통과율로 오인하는 실패 통제

25점 도식: 기한 변경은 여러 약속을 건드린다

화살표의 방향과 조건을 따라 연결을 읽습니다.

선은 변경 검토의 근거·영향·결정 연결이다. CH-07의 대상·권한·결정이 있어야 새 예약 v2 / 기존 예약 v1의 경계를 정하며, 반영·재확인·통지 뒤 실행 증거와 인수 판단을 따로 확인한다.

v1과 v2를 나누는 상자는 이 사례에서 결정한 정책 적용 대상이다. 모든 변경이 반드시 이런 방식이어야 한다는 뜻이 아니라, 적용 대상을 결정하지 않으면 같은 예약에 상충하는 규칙이 생긴다는 점을 보여 준다.

25점 모범답안

1. 범위와 도출

요구공학의 목표는 공방의 취소 필요와 준비·운영 책임을 검증 가능한 약속으로 전환하고 그 변경을 관리하는 것이다. 고객·강사·운영자·외부 연계 담당자의 역할과 결정권을 식별하고 인터뷰, 실제 처리 관찰, 안내문·계약·기존 기록과 작은 시제품을 대조한다. 기록된 관행을 곧바로 의무로 삼지 않고 미확인 집단과 자료의 한계를 남긴다.

2. 분석과 의사결정

취소 행동, 응답·보호 수준, 외부 연계·계약 제약과 미확인 가정을 분리한다. “하루 전”이 24시간 전인지 전날 0시인지 먼저 의미를 맞춘 뒤, 고객 편의와 강사 준비 손실의 충돌을 대안별로 평가한다. 적용 의무를 우선 확인하고 가치·실패 피해·기한·비용·선행 의존성으로 전달 순서를 정하며 결정권자·보류·반대와 재검토 조건을 기록한다.

3. 명세와 측정 조건

일반 취소 v1은 요청접수시각 ≤ (수업시작시각−24시간)이라는 시각 경계를 명시한다. 본인 확정 예약의 허용, 기한 경과·권한 거부, 이미 취소된 예약의 반복 요청을 분리하고 예약 상태와 결제 결과를 혼동하지 않는다. 이 조건은 취소 입력·판정·결과라는 기능 책임과 고객–예약의 소유 관계를 표현할 정보의 입력이며, 기능·정적 모델의 실제 설계는 별도로 수행한다. 요구마다 식별자·이유·출처·책임·버전·수용조건을 붙이며 품질 요구에는 환경·부하·측정 위치·분모와 시간 초과·오류의 처리 기준을 정한다.

4. 확인과 인수 준비

업무 담당자는 필요·정책·예외, 개발·운영 담당자는 실현 가능성·영향, 시험 담당자는 구체적 입력과 결과를 검토한다. 개별 문장의 명확성·검증 가능성과 집합의 누락·모순·중복을 나누어 보고, 경계 정각·직후·반복·타인 예약을 수용조건에 연결한다. 요구 문서의 타당성 확인과 구현 뒤의 실행 증거, 전체 범위에 대한 권한자의 인수는 다른 판단이며, 미실행 시험을 통과로 표시하지 않는다.

5. 양방향 추적

필요–요구 특정 버전–설계·구현 책임–확인 조건·실행 결과를 연결해 양쪽에서 찾아가게 한다. 한 필요를 여러 요구가 충족하면 각각의 기여와 전체 충족을 검토한다. 근거 없는 구현·시험, 연결되지 않은 필요와 오래된 시험 기준을 찾아 수정하며, 연결이 있다는 사실과 연결 내용이 요구를 실제로 확인한다는 사실을 구별한다.

6. 변경 영향과 반영

24시간을 12시간으로 바꾸는 CH-07은 허용·거부 요구뿐 아니라 안내·운영 절차·설계·구현·시험을 함께 분석한다. 기존 예약은 v1, 적용일 이후 새 예약은 v2로 정한다면 예약별 적용 정책을 식별하고 옛 예약의 약속도 유지한다. 계약·법령상 효력과 필요한 절차는 따로 확인하며, 권한 있는 결정 뒤 새 버전 반영·재확인·담당자 통지까지 추적한다.

7. 실패 통제와 결론

미결 가정이나 빠진 집단을 숨기지 않고, 요구가 바뀌면 관련 증거를 다시 검토한다. 연결률 4/4가 100%여도 미실행 시험의 성공률로 보고하지 않으며, 품질 실패를 분모에서 빼지 않는다. 요구의 뜻·적용 버전·실행 증거·결정 책임을 함께 유지해야 변경을 수용하면서도 고객과 운영의 약속을 지킬 수 있다.

출처와 이 절에서 확인한 범위

기준일은 2026-09-05다. 요구 도출과 검토·변경·추적의 안정적인 원리는 NASA의 공개 이해관계자 기대 정의, 기술 요구 정의, 좋은 요구 작성 점검, 요구 관리 본문에서 대조했다. NASA 프로젝트의 단계·위원회·의무 문구를 모든 조직의 법적 의무로 옮기지 않았다.

용어와 기법의 범위는 IREB가 공개한 CPRE Foundation Level Syllabus 3.3.0, 2026-04-01와 Martin Glinz의 Glossary 2.2.0, 2025-10-01의 관련 절·정의를 대조했다. Syllabus의 저자는 Stan Bühne, Martin Glinz, Hans van Loenhoud, Stefan Staal이며 저작권과 출처 소유는 해당 저자·IREB e.V.에 있다. Glossary는 © IREB e.V. 및 Martin Glinz이고, 두 문서의 이용조건은 출처를 밝힌 책·글의 기반 사용과 원문 재배포를 구별한다.

문헌의 표·그림·문장을 복제하지 않고 공방의 가상 사례, 한국어 설명·표·도식을 새로 구성했다. IREB의 로그인 요구 Handbook과 유료 ISO/IEC/IEEE 29148의 전체 본문은 열람 근거에 포함하지 않는다. 실제 사용자·업무 담당자가 이 사례를 승인했거나 시험을 실행한 것은 아니며, 출처의 접근 성공도 독립 사람 검수·공개 배포 권리 검토의 완료를 뜻하지 않는다.

본문의 설명·예제·도식은 AI가 작성한 교재 내용이며 NASA나 IREB의 검토·승인·보증을 받은 결과물이 아니다.

30초 정리

요구공학은 사람의 말을 받아 적는 일이 아니라, 필요한 것과 제약·가정을 구분하고 같은 의미의 검증 가능한 약속으로 만드는 일이다. 좋은 문장뿐 아니라 집합의 누락·모순과 실제 필요를 확인하고, 출처에서 요구의 특정 버전·실현·확인 증거까지 양방향으로 연결한다. 변경은 영향·적용 대상·권한·재확인까지 관리하며, 다음 모델링 절에서는 그 약속을 기능·구조·동작으로 표현한다.

직접 연습: 조건의 겹침, 성공의 분자, 증거의 버전을 구별한다.

아래는 앞의 공방 정책을 적용하는 별도 가상 사례다. 각 판정에서 입력 조건과 기대 결과를 함께 적고, 계산한 비율의 이름과 분모를 밝힌다.

1. RE-C. v1 취소 경계는 9월 19일 14:00:00 KST다. 네 독립 요청의 조건은 ① 타인의 이미 취소된 예약·경계 1초 뒤, ② 본인의 이미 취소된 예약·경계 1초 뒤, ③ 본인의 확정 예약·경계 정각, ④ 본인의 확정 예약·경계 1초 뒤다. 각 요청에 R-CAN-01~04 중 어떤 요구를 적용하며 예약 상태·자리 수를 바꾸는지 설명하라. 구현자가 모든 요청에 기한 검사부터 적용하거나 ≤를 <로 바꾸면 어느 결과가 달라지는가? 기한 1초 전·1초 뒤만 시험해서 이 두 비교 연산자가 같다고 판단해도 되는가?
2. RE-Q. Q-01의 동일한 E1 환경에서 유효 조회 1,000건을 측정했다. 정확한 완결 응답을 2초 이내 받은 요청 940건, 잘못된 결과를 2초 이내 받은 요청 30건, 정확한 완결 응답이 2초를 넘긴 요청 20건, 시간 초과 10건이다. 2초 이내 응답을 받은 건수와 Q-01 성공 건수·비율을 각각 구하고 수용 여부를 판단하라. 다른 건수는 그대로이고 일부 빠른 오답을 빠른 정답으로 고칠 수 있다면 성공 기준에 도달하기 위한 최소 건수는 얼마인가?
3. RE-V. CH-07 뒤 현재 승인 범위는 R-CAN-01 v2, R-CAN-02 v2, R-CAN-03 v1, R-CAN-04 v1 네 요구다. 네 행 모두 시험 기록 링크가 있지만, 앞의 두 기록은 v1의 24시간 경계만 실행했다. 뒤의 두 기록은 영향 검토를 거쳤고 현재 대상·관련 조건에도 유효한 성공 증거라고 확인되었다. 이 문제에서 행에 어떤 시험 기록 링크든 있는 비율과 현재 요구를 확인하는 유효 성공 증거가 있는 비율을 각각 계산하라. 앞의 두 v1 시험 성공을 현재 네 요구 전체의 통과로 보고할 수 있는가? 추가로 확인할 적용 대상과 경계 입력을 설명하라.

권한·상태·경계, 품질 성공 집계, 변경 후 증거의 버전 풀이

1. RE-C — 같은 시각에도 권한과 현재 상태가 다르면 결과가 다르다. ①은 R-CAN-04의 권한 거부다. 타인에게 이전 취소 결과를 돌려주는 반복 요청으로 취급하지 않으며 예약 상태·자리 수를 바꾸지 않는다. ②는 R-CAN-03이다. 이미 취소된 본인 예약이므로 이전 결과를 반환하고 자리를 다시 늘리지 않는다. ③은 R-CAN-01이다. 본인 확정 예약이며 정각은 요청접수시각 ≤ 경계를 만족하므로 취소한다. 다만 취소 상태 변경만으로 자리 반환·외부 환불의 완료까지 단정하지 않고 그 책임의 별도 요구와 실행 결과를 확인한다. ④는 R-CAN-02로 기한 경과 안내를 하고 확정 상태를 유지한다.

기한 검사를 모든 상태보다 먼저 끝내면 ①의 권한 거부와 ②의 이전 결과 반환을 기한 경과 결과로 잘못 바꿀 수 있다. ≤를 <로 바꾸면 ③의 정각 요청을 거부한다. 1초 전에는 두 연산자 모두 허용하고 1초 뒤에는 모두 거부하므로 이 두 시험만으로는 오류를 찾지 못한다. 정각 요청과 기대 취소 결과를 추가해야 이 차이를 확인할 수 있다. 이 판정은 본문의 두 상태인 확정·취소에 한정한다. 다른 상태가 가능하다면 그 상태의 요구를 먼저 확인하며 임의로 이 규칙에 끼워 넣지 않는다.

2. RE-Q — 빠른 오답은 정확하고 빠른 응답의 성공이 아니다. 2초 이내 응답을 받은 건수는 940+30=970건, 그 비율은 97%다. Q-01 성공은 정확한 완결 응답까지 요구하므로 940건이고, 분모는 처음의 유효 조회 1,000건이다. 성공률은 940/1,000=94%여서 95% 이상 기준에 미달한다. 빠른 오답 30건·늦은 정답 20건·시간 초과 10건을 모두 이 기준의 실패로 유지한다. 시간 초과를 분모에서 빼거나 오답을 성공에 더하면 요구와 다른 값을 보고하게 된다.

95%에 필요한 성공은 1,000×0.95=950건이다. 다른 조건이 그대로라면 빠른 오답 중 최소 950−940=10건을 빠른 정답으로 고쳐야 한다. 늦은 정답을 단지 정확하다고 성공에 넣을 수는 없다. 94%는 이 부하·측정 위치·기간에서 만든 사례의 결과이며, 다른 환경의 응답 수준이나 실제 시험 완료를 보증하지 않는다.

3. RE-V — 시험의 옛 성공과 현재 약속의 성공을 나누어 적는다. 문제에서 정의한 링크 존재 비율은 4/4=100%다. 그러나 현재 요구를 확인하는 유효 성공 증거는 뒤의 두 행뿐이므로 그 비율은 2/4=50%다. 링크의 내용·버전이 적절하다는 판단은 링크가 존재한다는 계산에 포함되지 않았다. 앞의 두 v1 성공으로 현재 요구 전체를 통과 처리할 수 없다.

새 예약에는 승인된 v2의 12시간 경계 정각·직후와, v1에서는 거부하지만 v2에서는 허용하는 중간 시각의 기대 결과를 확인한다. 기존 예약에는 v1이 유지되는지와 그 24시간 경계를 확인한다. 예를 들어 본문의 R502가 9월 19일 20:00에 접수한 본인 확정 예약 취소는 v1만 적용하면 거부하지만 v2에서는 허용된다. 정책 적용 대상을 구별하지 않은 옛 시험은 이 차이를 보여 주지 못한다.

변경과 무관한 증거까지 무조건 폐기하는 것도 아니다. 뒤의 두 행처럼 영향·대상·관련 조건과 결과가 현재에도 유효한지 확인하고, 재사용 근거를 기록한다. 바뀐 두 행은 새 요구 버전·구현 대상·기대 결과와 실행 증거를 연결한 뒤 현재 상태를 갱신한다. 네 요구에 대한 이 비율이 고객 필요 전체의 충족이나 전체 인수 권한자의 결정까지 대신하지는 않는다.