이해관계자·문제·요구사항
같은 민원 시스템도 시민은 짧은 대기와 쉬운 안내를, 담당자는 정확한 분류를, 감사자는 처리근거를 원한다. 한 사람의 요청만 제품 요구로 옮기면 다른 사람의 권리나 운영책임을 놓친다. 요구사항은 원하는 화면 목록이 아니라 이해관계자의 필요와 계약·법령·정책·설계 제약에서 나온, 시스템이 충족해야 할 검증 가능한 조건…
기능을 말하기 전에 누구의 어떤 문제가 있는지 묻는다
같은 민원 시스템도 시민은 짧은 대기와 쉬운 안내를, 담당자는 정확한 분류를, 감사자는 처리근거를 원한다. 한 사람의 요청만 제품 요구로 옮기면 다른 사람의 권리나 운영책임을 놓친다. 요구사항은 원하는 화면 목록이 아니라 이해관계자의 필요와 계약·법령·정책·설계 제약에서 나온, 시스템이 충족해야 할 검증 가능한 조건이나 능력이다.
먼저 되짚기: 시스템 목적
시스템 목적은 시스템이 만들어야 하는 가치와 관찰 가능한 성공상태다. 이해관계자를 찾는 이유는 이 목적이 누구의 어떤 문제와 가치에 연결되는지 확인하기 위해서다.
요구로 바꾸기 전에 이해관계자와 필요의 경계를 고정한다
이해관계자는 시스템의 결정·운영·결과에 영향을 주거나 그 영향을 받는 개인·집단·조직이고, 필요는 현재 상태와 바라는 결과 사이에서 해소해야 할 차이다. 시스템 목적이 성공상태를 말한다면 이해관계자와 필요는 그 성공이 누구에게 어떤 가치와 문제해결로 나타나야 하는지를 구체화한다.
다시 연결하기: 필요에서 요구사항으로
이해관계자와 필요는 요구의 출처와 이유를 설명한다. 요구사항은 이 필요와 외부 의무를 만족하는지 검증할 수 있는 조건이나 능력으로 바꾼 약속이다.
이해관계자와 필요
이해관계자(stakeholder)는 시스템의 결정·운영·결과에 영향을 주거나 그 영향을 받는 개인, 집단 또는 조직이다. 필요(need)는 현재 상태와 바라는 결과 사이에서 해소해야 할 차이다. 요구사항(requirement)은 이해관계자의 필요, 계약, 법령·정책 또는 설계 제약이 부과하여 시스템이나 구성요소가 충족해야 하는 검증 가능한 조건 또는 능력이다. 이해관계자의 말은 중요한 입력이지만 곧바로 확정 요구사항은 아니다.
무엇이면 약속을 지켰다고 판단할까
수용기준(acceptance criteria)은 이해관계자가 결과물을 받아들일 수 있도록 그 결과물이 만족해야 하는 판정 조건이다. 수용조건도 같은 뜻으로 사용한다. 예를 들어 가상의 민원 접수 요구가 “필수 항목이 갖춰진 요청을 접수한다”라면, “필수 항목을 모두 채운 요청에 접수번호를 발급하고, 빠진 요청에는 누락 항목을 안내하며 접수하지 않는다”가 수용기준의 예다. 조건을 적어 두었다는 것과 실제 결과가 그 조건을 만족했다는 것은 다르다.
요구의 출처와 이유, 적용범위, 수용기준, 충돌과 우선순위를 검토하고 권한 있는 주체가 승인하면, 합의한 요구의 특정 버전을 이후 변경 판단의 기준으로 삼는다. 뒤에서 말하는 ‘승인된 요구 기준선’은 이 기준 버전을 가리킨다. 그 뒤의 변경은 무엇에 영향을 주는지 분석하고 다시 승인받는 절차를 거친다.
목소리를 검증 가능한 요구로 바꾸기
먼저 사용자·운영자·책임자·외부기관처럼 결과와 위험을 가진 주체를 찾는다. 각 주체가 겪는 현재 문제, 원하는 결과, 손실과 제약을 분리한다. 빨라야 한다는 말은 평일 혼잡시간에도 민원 접수의 대부분을 정한 시간 안에 완료처럼 조건·대상·측정값으로 바꾸고, 다른 주체의 요구와 충돌하면 우선순위와 결정권자를 기록한다.
목소리가 큰 사람만 보면 생기는 실패
구매자만 이해관계자로 보면 실제 사용자와 운영자의 비용이 빠지고, 현재 불만만 모으면 미래 목표와 규제책임이 빠진다. 모두의 희망을 그대로 합치면 서로 양립할 수 없는 요구가 된다. 영향·권리·전문성·의사결정 책임을 기준으로 참여방식을 정하고, 합의되지 않은 충돌을 명시적으로 남겨야 한다.
목소리에서 통제된 기준선까지
상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.
인터뷰 입력을 요구 기준선으로 바로 취급하지 않는다. 후보를 검토·승인한 뒤 설계·구현과 시험·인수까지 추적한다. 운영 결과나 환경 변화는 영향분석·재승인을 거쳐 새 기준선으로 반영한다.
이 흐름에서 인터뷰 기록은 입력이고 승인된 요구 기준선은 통제 대상이다. 둘을 구분해야 새로운 의견 하나가 기존 설계와 시험을 몰래 바꾸지 않는다. 각 요구에는 출처, 책임자, 수용기준, 연결된 설계·시험과 변경 이력이 따라야 한다.
사람의 말과 시스템의 의무를 구분한다
| 구분 | 답하는 질문 | 민원 서비스 예 | 다음 확인 |
|---|---|---|---|
| 이해관계자 | 누가 영향·권리·책임을 가지는가 | 시민, 상담원, 기관 책임자, 감사기관 | 대표성과 결정권 |
| 필요 | 현재와 원하는 결과의 차이는 무엇인가 | 방문하지 않고 접수하고 싶다 | 실제 문제와 기대효과 |
| 요청·선호 | 당사자가 제안한 해법은 무엇인가 | 모바일 앱을 만들어 달라 | 다른 해법 가능성 |
| 후보 요구사항 | 무엇을 검증 가능하게 충족해야 하나 | 원격으로 본인 민원을 접수할 수 있어야 한다 | 출처·범위·수용기준 |
| 승인된 기준선 | 어떤 요구 집합을 만들기로 통제하는가 | 승인된 기능·품질·법적 조건 목록 | 버전·승인자·변경절차 |
선호한 해결책과 근본 필요가 다를 수 있다. 모바일 앱은 한 대안이고 원격 접수는 필요한 능력이다. 해결책을 너무 일찍 고정하면 더 단순한 웹 접근이나 기존 채널 개선을 비교할 기회를 잃는다.
충돌은 다수결보다 근거와 책임으로 푼다
요구가 충돌하면 먼저 법령·안전·권리처럼 반드시 지켜야 할 조건을 분리한다. 그다음 조직 목표와 사용자 가치, 실패 피해, 대상 규모, 비용·일정, 되돌리기 어려움을 같은 기준으로 비교한다. 예를 들어 시민의 간편 접속과 감사자의 강한 본인확인이 충돌하면 둘 중 하나를 지우지 말고 위험이 높은 행위에서만 추가 확인을 요구하는 대안을 검토한다.
최종 결정에는 채택·보류·기각 결과와 근거, 결정권자, 영향을 받는 집단, 보완 통제와 재검토 조건을 남긴다. 의견 수가 많다는 이유만으로 소수자의 법적 권리나 치명적 운영위험을 희생하지 않는다. 합의가 되지 않아도 결정 사실과 남은 반대·위험을 숨기지 않는 것이 통제다.
세 문장을 요구사항으로 다듬어 보기
민원 서비스에서 시민은 “기다리지 않게 해 달라”, 담당자는 “아무나 내용을 바꾸면 안 된다”, 법무 담당자는 “처리 근거를 남겨야 한다”고 말했다고 하자.
- 시민의 말은 “평일 업무시간에 서버 경계가 수신한 유효 민원 제출 시도의 90%에 대해 수신부터 3분 안에 접수번호 응답을 내보내야 한다”로 바꾼다. 대상·기간·비율·시간이 있어 시험할 수 있다.
- 담당자의 말은 “권한을 승인받은 담당자만 배정된 민원의 상태를 변경할 수 있어야 한다”로 바꾸고 정상·거부 시험을 붙인다.
- 법무 담당자의 말은 적용 법령과 보존기간을 확인한 뒤 “상태 변경의 행위자·시각·변경 전후 값을 정한 기간 보존해야 한다”로 바꾼다.
세 요구에는 각각 필요 또는 법적 출처, 수용기준, 우선순위와 책임자를 붙인다. 검토에서 충돌과 구현 가능성을 확인하고 승인한 버전을 기준선으로 삼는다. 이 과정을 거치면 모호한 희망, 통제 조건과 검증 증거가 구분된다.
이 예의 시간 요구는 다음과 같이 고정한다. 시험 업무시간에 서버 경계가 수신한 중복 제거 후 유효 민원 제출 시도 100건을 분모로 하고, 요청 수신시각부터 접수번호 응답이 같은 서버 경계를 나갈 때까지를 잰다. 유효성 실패는 별도 집계하되, 유효 요청의 내부 오류·시간초과·번호 미발급은 분모에서 제거하지 않고 시간 목표 실패로 센다. 90건이 3분 이내, 7건이 초과, 3건이 번호 미발급이면 90/100=90%로 이 요구의 경계값을 만족한다. “접수 성공 97건 중 90건”으로 분모를 바꾸지 않는다. 사용자 단말에서 보이는 시간은 별도 종단 지표로 확인한다.
자체 10점 문제
이해관계자의 필요를 요구사항 기준선으로 전환하는 절차와 충돌·변경 통제방안을 설명하시오.
요구어는 전환, 설명, 통제다. 이해관계자·필요·요구사항·기준선을 구분하고 식별 → 필요 분석 → 검증 가능한 명세 → 충돌 조정 → 검토·승인 → 추적·변경의 흐름으로 답한다.
10점 풀이 방향과 모범답안 보기
답안 목차
- 이해관계자·필요·요구사항·기준선의 정의와 관계
- 이해관계자 식별과 영향·권리·책임 분석
- 필요·외부 의무를 검증 가능한 조건·능력으로 전환
- 충돌·우선순위 평가와 권한 있는 검토·승인
- 요구–설계–시험 추적, 기준선 버전과 변경 통제
- 대표성·모호성·해결책 고정 실패와 개선 통제
답안에 넣을 핵심 도식
기준선 환류 그림을 답안에 연결한다. 이해관계자의 영향·권리·책임에서 필요와 외부 의무의 출처·근거를 찾고, 후보 요구에 수용기준을 붙인다. 충돌·우선순위 검토와 승인 뒤에 설계·시험 증거를 추적하며, 운영·변경 영향은 분석·재승인 경로로 기준선에 돌아간다.
도식 아래에는 “입력 의견을 그대로 확정하지 않고 승인된 기준선을 설계와 시험까지 추적하며, 운영 변화는 영향분석 후 새 기준선으로 통제한다”라고 해석을 붙인다.
모범답안
이해관계자는 시스템에 영향을 주거나 받는 주체이고, 필요는 현재와 원하는 결과 사이의 차이다. 요구사항은 이해관계자 필요, 계약, 법령·정책 또는 설계 제약이 부과한 검증 가능한 조건이나 능력이다. 후보 요구는 검토·승인을 거쳐 통제되는 기준선이 되므로 단순한 의견 합의와 구분해야 한다.
전환 절차는 다음과 같다. 첫째, 사용자·운영자·책임자·외부기관을 식별하고 영향·권리·책임을 분석한다. 둘째 현재 문제, 원하는 결과, 외부 의무와 제약을 수집하고 숨은 목적을 확인한다. 셋째 기능·품질·제약을 대상·조건·측정값·수용기준이 있는 문장으로 바꾼다. 넷째 법적 의무, 업무가치, 실패 피해, 비용과 되돌리기 어려움으로 충돌과 우선순위를 판단한다. 다섯째 권한 있는 주체가 범위와 수용기준을 검토·승인하고 버전 기준선을 만든다.
승인 뒤에는 요구를 설계결정과 시험 증거에 연결해 추적하고 변경 요청마다 영향, 비용, 위험과 관련 요구를 분석해 재승인한다. 대표성 없는 의견 수집, 제안 해법의 조기 고정, 모호한 수용기준과 무단 변경을 방지하려면 출처·결정근거·반대의견·잔여위험과 재검토 조건을 남겨야 한다.
자체 25점 문제
시민·담당자·법무 담당자의 상충하는 필요를 검증 가능한 요구사항으로 전환하고 기준선·추적·변경 통제 절차를 설계하시오.
요구어는 전환과 설계다. 발언을 그대로 요구로 복사하지 않고 출처·필요·수용기준·우선순위·승인·변경 영향을 하나의 폐쇄루프로 연결한다.
25점 풀이 방향과 모범답안 보기
25점 답안 목차
- 시스템 목적과 이해관계자 식별
- 필요·권리·외부 의무 수집
- 기능·품질·제약 후보 요구
- 수용기준과 측정조건
- 충돌·우선순위와 결정권
- 검토·승인과 기준선 버전
- 요구–설계–시험 추적
- 변경영향·재승인·잔여위험
25점 답안 도식
| 목적에서 기준선으로 연결 | 통제할 근거·증거 |
|---|---|
| 목적 → 이해관계자 → 필요·의무 | 누가 어떤 가치·권리·책임을 가지는가 |
| 후보 요구 → 승인 기준선 | 검증 가능성·수용기준·충돌·우선순위 |
| 기준선 → 설계 → 시험 증거 | 요구 식별자로 누락과 영향을 추적 |
| 운영·변경 영향 → 재승인 | 영향분석 뒤 새 기준선으로 반영 |
앞의 승인·변경 그림에 아래 v1/v2 민원 선택 결과를 대입한다.
25점 모범답안
먼저 민원 서비스의 목적을 정하고 시민·업무 담당자·책임자·법무·운영자처럼 결과에 영향을 주거나 받는 이해관계자를 식별한다. 각 주체의 현재 문제, 원하는 결과, 권리·책임과 계약·법령·정책 같은 외부 의무를 구분해 수집한다. 모호한 요청은 업무시간·대상·비율·시간 같은 수용기준을 붙여 검증 가능한 요구로 바꾼다.
후보 요구는 법적 의무와 실패 피해, 업무가치, 비용, 되돌리기 어려움으로 충돌과 우선순위를 판단한다. 결정권자가 범위·수용기준·예외를 검토하고 승인한 버전을 기준선으로 삼으며 요구 식별자와 출처·결정근거를 남긴다.
승인 뒤에는 요구를 설계결정과 시험 증거에 연결해 추적한다. 변경 요청이 오면 영향받는 요구·설계·시험·운영 절차와 비용·위험을 분석해 재승인하고 새 기준선을 만든다. 대표성 없는 의견, 특정 해법의 조기 고정, 모호한 수용기준과 무단 변경은 반대의견·잔여위험·재검토 조건까지 기록해 통제한다.
자체 기준선 v1의 선택 결과는 다음과 같다.
| 주체·요구 | 수용시험·책임 |
|---|---|
| 시민 R1: 유효 제출의 90%에 서버 경계시간 3분 이내 번호 응답 | 운영 담당이 100건의 수신·응답/실패 로그 대조 |
| 업무담당자 R2: 승인된 담당자만 배정 민원 변경 | 보안 담당이 본인 배정 허용·타인 배정/미승인 거부 시험 |
| 기록담당자 R3: 상태변경 행위자·시각·전후값 추적 | 기록 담당이 허용 변경·거부 시도별 기록 시험; 보존기간은 적용근거 확인 후 확정 |
시민 편의를 이유로 모든 직원에게 변경권을 주자는 대안은 R2 위반으로 기각하고 본인 배정 조회·변경만 허용한다. 서비스 책임자가 R1/R2와 R3의 기록필드를 v1로 승인하되, 법적 보존기간 확인 전에는 그 부분을 승인 완료로 표시하지 않는다. 3분→2분 변경은 부하·비용·시험 영향을 검토한 뒤 v2로 별도 승인한다.
출처와 적용 경계
이해관계자·필요·요구사항·기준선·추적성은 안정된 요구공학 기초개념이다. 민원 사례와 수치 예는 검증가능성·충돌통제를 연습하기 위한 자체 예이며 특정 기관의 실제 SLA나 법적 보존기간을 뜻하지 않는다.
자기교정과 조건 변경
| 잘못 쓴 답 | 수정 | 복습 |
|---|---|---|
| 이해관계자의 말은 그대로 요구사항이다 | 필요·의무를 검증 가능한 조건·능력으로 전환한다 | 정의 |
| 가장 큰 목소리를 우선하면 된다 | 권리·실패피해·가치·의무·비용과 결정권으로 충돌을 조정한다 | 충돌 |
| 빠르게 해 달라는 말도 충분히 시험할 수 있다 | 대상·환경·측정값·수용수준을 붙인다 | 사례 |
| 승인 뒤 요구는 바뀌면 안 된다 | 변경영향 분석과 재승인으로 새 기준선을 만든다 | 도식 |
| 요구 문서만 있으면 추적이 끝난다 | 설계결정·시험증거·운영변경까지 연결한다 | 모범답안 |
민원 처리시간 목표가 3분에서 1분으로 바뀌면? 설계·용량·시험·운영지표 영향과 비용을 분석하고 수용기준을 재승인한다.
새 외부기관이 감사권한을 가지게 되면? 이해관계자 목록, 권리·증거 요구와 접근통제를 갱신하고 영향받는 요구를 추적한다.
시민 만족도는 높지만 법적 기록요건을 충족하지 못하면? 만족도와 법적 의무를 상쇄하지 않고 필수 제약을 충족한 뒤 다른 품질목표를 최적화한다.
한 번에 되찾기
이해관계자는 시스템에 영향을 주거나 받는 주체이고 필요는 현재와 바라는 결과의 차이다. 요구사항은 필요와 계약·법령·정책·설계 제약이 부과한 검증 가능한 조건 또는 능력이다. 검토·승인된 요구는 기준선으로 통제하며 출처·수용기준·충돌·변경 이력을 함께 기록한다.