2장. 요구사항이란 무엇인가

요구사항과 목표·정책·설계·시험 조건의 경계를 구분해 문장 모양이 아니라 출처와 결정 책임으로 대상을 판별한다.

이번 장에서 해결할 질문

학습 목표

• “필요·목표·요구사항·기능·제약·설계 결정을 어떻게 구분하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
• 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.

핵심 개념

프로젝트 회의에서는 요구, 요구사항, 목표, 기능, 정책, 제약, 설계라는 말이 자주 섞인다. “모바일 앱이 필요하다”는 문장을 누군가는 사용자 요구로, 누군가는 이미 결정된 범위로, 누군가는 해결책 후보로 받아들인다. 단어가 같아도 의미가 다르면 합의한 것처럼 보인 채 서로 다른 결정을 내리게 된다.

이 장에서는 용어를 외우기보다 경계를 판단하는 법을 익힌다. 문장이 무엇을 설명하는지, 누가 결정할 권한을 가졌는지, 대안이 남아 있는지, 무엇으로 충족 여부를 확인할지를 묻는다. 경계는 프로젝트 맥락에 따라 움직일 수 있지만, 분류한 이유와 근거는 언제나 설명할 수 있어야 한다.

1. 요구와 요구사항의 차이

요구는 이해관계자가 느끼는 필요나 원하는 상태에서 출발한다. 불편, 위험, 기회, 의무처럼 아직 정확한 해결 조건으로 정리되지 않은 경우가 많다. 요구사항은 그 필요를 관련자가 공유하고 분석·구현·확인할 수 있는 형태로 표현한 것이다. IIBA의 The Business Analysis Standard는 요구사항을 필요의 사용 가능한 표현으로, 설계를 해결책의 사용 가능한 표현으로 구분한다.

IREB CPRE 온라인 용어집은 ‘requirement’에 이해관계자가 인식한 필요, 시스템이 가져야 할 능력이나 속성, 그리고 그 문서화된 표현이라는 여러 의미가 있음을 보여 준다. 체계마다 용어의 포함 범위가 조금씩 다르므로 이 책에서는 실무 대화를 분명하게 하기 위해 ‘요구’를 아직 충분히 구조화하지 않은 필요, ‘요구사항’을 출처와 맥락을 갖고 검토 가능한 형태로 표현한 조건으로 구분한다. 이것은 다른 표준의 정의를 틀렸다고 보는 것이 아니라 책 안에서 사용할 작업 규칙이다.

수강신청 사례의 “학생들이 편하게 수강신청하고 싶다”는 요구다. 불편이 있다는 사실은 전하지만 어떤 학생이 어떤 상황에서 무엇을 할 수 있어야 하는지는 정하지 않았다. 다음과 같이 바꾸면 요구사항 후보에 가까워진다.

UR-001UR-001 · 사용자 요구신청 가능 강좌와 결과·사유 확인 / 사용자. 학생은 정해진 수강신청 기간에 자신이 신청할 수 있는 강좌를 확인하고, 신청 또는 거절 결과와 이유를 알 수 있어야 한다.

이 문장도 완성된 요구사항은 아니다. ‘신청할 수 있는’ 조건, 결과를 알려야 하는 시간, 예외 상황과 책임자를 더 확인해야 한다. 다만 대상과 기대 결과가 드러났고, 하위 요구와 확인 시나리오를 논의할 출발점이 생겼다.

요구를 요구사항으로 바꿀 때는 말을 그럴듯하게 다듬는 데 그치지 않는다. 누가 필요를 제기했는지, 어떤 문제와 목표를 뒷받침하는지, 적용 범위와 예외는 무엇인지, 충족 여부를 어떤 증거로 확인할지를 붙여야 한다. 표현이 정교해져도 실제 필요와 연결되지 않으면 잘못된 요구사항을 정확하게 쓴 것에 불과하다.

이 책에서 사용하는 핵심 용어와 혼동하기 쉬운 표현은 부록 A. 요구사항 용어사전요구사항 용어사전실무에서 바로 사용할 수 있는 기준과 예제를 확인한다.페이지로 이동에서 한꺼번에 확인할 수 있다. 실제 프로젝트에서는 부록의 정의를 그대로 강제하지 말고 조직의 공식 용어와 차이를 기록한다.

2. 문제와 해결책의 차이

문제는 현재 상태와 바람직한 상태 사이의 의미 있는 차이다. 해결책은 그 차이를 줄이기 위해 선택하는 변화다. 문제를 해결책의 부재로 표현하면 대안을 너무 일찍 닫게 된다. “모바일 앱이 없다”를 문제라고 쓰면 결론은 이미 앱 개발로 정해진다. 하지만 실제 문제는 신청 시작 시점에 사용자가 접속 결과를 알지 못해 반복 요청하고, 교무처가 실패 건을 수작업으로 처리하는 것일 수 있다.

문제를 찾을 때는 증상도 구분해야 한다. 서버 CPU 사용률이 높다는 것은 관찰된 현상이다. 반복 클릭이 많다는 것도 현상이다. 그 원인은 처리 상태를 알려 주지 않는 화면, 느린 조회, 잘못된 재시도 정책, 용량 부족처럼 여러 가지일 수 있다. 증상 하나를 보고 바로 서버 증설을 선택하면 더 싼 해결책이나 근본 원인을 놓칠 수 있다.

수강신청 사례를 다음처럼 나누어 보자.

해결책을 말해서는 안 된다는 뜻은 아니다. 프로토타입이나 기술 실험은 문제를 더 잘 이해하게 해 준다. 다만 해결책 후보를 요구처럼 고정하지 말고 어떤 문제와 판단 기준 때문에 선택했는지 연결해야 한다. 대안이 사라지는 시점에는 권한 있는 사람이 근거를 검토하고 결정했다는 기록이 필요하다.

3. 목표와 요구사항의 차이

목표는 이해관계자가 도달하려는 바람직한 상태다. IREB 용어집도 목표를 이해관계자가 이루고자 하는 상태로 설명한다. 목표는 방향과 성공의 의미를 제공하지만 시스템이 어떤 조건을 만족해야 하는지 모두 말해 주지는 않는다. 요구사항은 목표를 달성하는 데 필요한 능력, 속성, 제약을 구체화한다.

예를 들어 대학의 목표가 “수강신청 시작 시점의 혼란과 수작업 복구를 줄인다”라면 다음 단계에서 기준값과 목표값을 정해야 한다. 직전 학기 첫 30분 동안 발생한 중복 요청, 학생 문의, 수동 정정 건수를 측정하고 어느 정도까지 줄일지 합의할 수 있다. 이 수치는 사례를 설명하기 위한 가정이며 실제 프로젝트에서는 운영 기록으로 검증해야 한다.

목표와 요구사항은 일대일로 대응하지 않는다. 하나의 목표를 위해 여러 요구사항이 필요하고, 하나의 요구사항이 여러 목표를 지원할 수 있다.

목표를 요구사항처럼 쓰면 “혼란을 줄여야 한다”처럼 구현과 확인이 어려운 문장이 된다. 반대로 요구사항만 모으고 목표를 잊으면 필요 없는 기능을 버리지 못한다. 각 요구사항에 “이 항목이 없으면 어떤 목표가 위험해지는가?”라고 물었을 때 답할 수 있어야 한다. 답이 없다면 범위에서 제외할 후보이거나 아직 근거를 찾지 못한 항목이다.

판단 기준은 간단하다. 목표는 왜 변화해야 하는지와 성공의 방향을 말한다. 요구사항은 그 목표를 지원하기 위해 무엇이 참이어야 하는지를 말한다. 목표 달성도는 여러 지표를 종합해 평가할 수 있고, 개별 요구사항은 정해진 조건과 증거로 충족 여부를 판단한다.

4. 요구사항과 설계의 경계

요구사항은 충족해야 할 필요와 조건을 표현하고, 설계는 그것을 어떻게 실현할지 표현한다. IIBA는 요구사항과 설계가 목적은 다르지만 서로 독립된 직선 단계는 아니라고 설명한다. 설계를 탐색하다 새로운 필요나 제약을 발견할 수 있고, 요구가 바뀌면 설계도 다시 선택해야 한다. 경계를 구분하되 피드백은 열어 두어야 한다.

“학생은 장소와 관계없이 신청 결과를 확인할 수 있어야 한다”는 요구사항 후보다. “네이티브 모바일 앱의 푸시 알림으로 결과를 전달한다”는 대체로 설계안이다. 반응형 웹, 문자, 이메일, 앱 알림 등 다른 방식으로도 상위 필요를 만족할 수 있기 때문이다. 설계안을 요구사항으로 오인하면 비용·접근성·운영 조건을 비교하기 전에 한 대안에 묶인다.

그렇다고 기술을 언급한 문장이 언제나 설계인 것은 아니다. 대학의 보안 정책이나 계약이 특정 인증 체계 사용을 의무화할 수 있다. 외부 학사 시스템이 정해진 프로토콜만 제공할 수도 있다. 상위 조직이 승인한 기술 선택은 하위 팀이 반드시 만족해야 할 제약 요구사항이 된다. 전체 프로젝트에서는 설계 결정이었던 것이 구성요소 팀에는 요구사항으로 전달될 수 있다.

경계를 판단할 때 다음을 확인한다.

• 상위 목적을 만족하는 다른 대안이 실제로 존재하는가?
• 이 문장의 출처는 업무 필요·정책·계약인가, 기술팀의 선택인가?
• 결정을 바꿀 권한이 누구에게 있는가?
• 대안을 바꾸면 수용 기준도 바뀌는가?
• 이 선택의 이유와 비교한 대안이 기록되어 있는가?

요구사항에서 설계 정보를 무조건 삭제하는 것도 옳지 않다. 설계 제약이 정당하다면 출처와 이유를 붙여 보존해야 한다. 근거가 없는 제약이라면 요구사항으로 위장한 선호일 수 있으므로 대안을 다시 열어야 한다. 경계의 목적은 문장을 단속하는 것이 아니라 필요한 결정이 알맞은 권한과 근거로 이루어지게 하는 데 있다.

5. 요구사항과 기능의 차이

기능은 시스템이 제공하는 동작이나 능력이다. 요구사항은 기능을 포함할 수 있지만 기능 목록과 같지 않다. “강좌 검색”, “수강 신청”, “신청 취소”는 기능 이름이다. 누가 어떤 조건에서 기능을 사용하며 어떤 결과가 나와야 하는지, 오류일 때 무엇을 해야 하는지는 알려 주지 않는다.

하나의 기능에는 여러 종류의 요구사항이 결합된다. 수강 신청 기능을 예로 들면 다음과 같다.

• 기능 요구: 학생의 요청을 받아 신청 가능 조건을 판정하고 승인 또는 거절한다.
• 품질 요구: 신청 시작 시점의 예상 부하에서도 합의한 응답시간과 가용성을 만족한다.
• 데이터 요구: 판정에 사용한 학생, 강좌, 정책 버전, 결과와 사유를 기록한다.
• 인터페이스 요구: 학사 규칙 서비스와 인증 서비스의 요청·응답 및 장애 동작을 정의한다.
• 제약: 개인정보 저장 위치와 접근 권한에 관한 대학 정책을 지킨다.

기능은 제품을 탐색하고 범위를 논의하는 데 유용하다. 그러나 기능 이름만 승인하면 가장 중요한 예외와 품질이 개발자의 가정으로 남는다. 반대로 모든 요구사항을 기능 아래에 억지로 넣으면 데이터 보존, 보안, 운영, 전환 같은 가로지르는 요구가 사라진다.

기능 목록을 볼 때는 “이 기능이 있다”에서 멈추지 말고 네 가지를 묻는다. 어떤 목표와 사용자의 과업을 지원하는가, 시작 조건과 정상 결과는 무엇인가, 거절·실패·복구 상황은 무엇인가, 기능이 존재하는 것 외에 어느 수준의 품질을 만족해야 하는가. 답이 있어야 기능을 검토 가능한 요구사항 집합으로 발전시킬 수 있다.

6. 요구사항과 정책의 차이

정책은 조직이나 권한 있는 기관이 반복되는 의사결정에 적용하도록 정한 원칙과 규칙이다. 요구사항은 정책이 대상 시스템과 업무에 미치는 영향을 표현한다. 정책 원문을 그대로 복사하는 것만으로는 시스템이 무엇을 해야 하는지 충분히 알기 어렵고, 요구사항만 적고 정책 출처를 버리면 변경 이유와 해석 권한을 잃는다.

“졸업예정자는 전공필수 강좌 신청에서 우선권을 가진다”는 대학 정책이 있다고 하자. 시스템 요구사항으로 옮기려면 적용 대상, 우선권의 시점과 범위, 같은 우선순위 안의 정렬 규칙, 예외 승인자, 정책 시행일을 확인해야 한다. 다음 문장은 정책과 시스템 동작을 연결한 후보가 된다.

수강신청 시스템은 우선 배정 기간에 학사 시스템이 졸업예정자로 확인한 학생의 전공필수 신청을 일반 신청보다 먼저 평가해야 한다.

여전히 “먼저 평가”의 구체적인 알고리즘과 동률 처리, 외부 시스템 오류가 남아 있다. 중요한 점은 요구사항이 정책을 임의로 재해석하지 않는 것이다. 정책 책임자가 의미를 승인하고, 요구사항에는 정책 문서 식별자와 판본, 시행일을 출처로 연결해야 한다.

정책과 요구사항의 수명도 다를 수 있다. 정책이 개정되면 여러 요구사항과 설계, 데이터, 시험이 한꺼번에 영향을 받는다. 반대로 시스템 제약 때문에 정책을 그대로 자동화할 수 없다면 업무 절차나 예외 승인을 포함한 대안을 협상해야 한다. 정책은 요구사항의 강한 근거지만, 구현 문장을 자동으로 제공하는 것은 아니다.

7. 요구사항과 제약사항의 차이

제약사항제약사항해법이 반드시 지켜야 하는 기술·정책·법·환경상의 제한이다.은 가능한 해결책의 범위를 제한한다. IREB 용어집은 RE에서의 제약을 기능과 품질 요구를 만족하는 데 필요한 범위를 넘어 해결 공간을 제한하는 요구사항으로 설명한다. 즉 제약사항은 요구사항과 대립하는 별도 세계가 아니라 요구사항의 한 종류로 다룰 수 있다. 다만 “무엇을 제공해야 하는가”보다 “어떤 선택은 할 수 없는가”에 초점을 둔다.

수강신청 프로젝트에는 여러 제약이 있을 수 있다.

• 개인정보는 대학이 승인한 지역과 저장소에 보관해야 한다.
• 기존 학사 시스템의 학생·강좌 식별자를 변경할 수 없다.
• 확정된 학사 일정 전에 데이터 전환을 마쳐야 한다.
• 접근 권한은 대학의 인증·권한 체계를 사용해야 한다.
• 관련 법령과 대학 규정을 준수해야 한다.

모든 제약이 정당한 것은 아니다. “우리는 늘 이 데이터베이스를 썼다”, “담당자가 이 프레임워크에 익숙하다”는 말은 고려할 요소일 수 있지만 곧바로 요구사항이 되지는 않는다. 비용, 일정, 운영 역량 때문에 실제 선택 조건이 된다면 권한 있는 책임자가 근거와 기간을 승인해야 한다. 습관이나 선호를 제약으로 포장하면 더 적합한 대안을 검토할 기회를 잃는다.

제약을 검토할 때는 출처의 공식성, 적용 범위, 유효 기간, 위반 시 결과, 예외 승인 절차를 확인한다. 또한 제약끼리 충돌할 수 있다. 데이터의 국내 저장 의무와 해외 SaaS 사용 지시가 동시에 주어지면 개발자가 임의로 하나를 선택할 문제가 아니다. 정책·계약·기술 책임자가 해결해야 할 요구사항 충돌이다.

8. 요구사항과 시험 조건의 차이

요구사항은 시스템이 만족해야 할 상태, 능력, 속성이나 제약을 말한다. 시험 조건은 그 요구사항의 충족 여부를 확인하려면 어떤 상황과 관찰 지점을 다뤄야 하는지 정한다. 시험 조건에는 입력, 사전 상태, 수행 사건, 기대 결과와 필요한 환경이 포함될 수 있다. 요구사항이 이유와 기대를 제공한다면 시험 조건은 관찰 가능한 증거를 설계한다.

다음 예를 보자.

시험 조건이 요구사항을 대신할 수는 없다. 몇 개의 예시만 있으면 그 사이에 적용되는 일반 규칙과 존재 이유를 알기 어렵다. 반대로 시험 조건을 만들 수 없는 요구사항은 모호하거나 관찰할 수 없는 경우가 많다. 둘은 서로를 검토하는 관계다. 요구사항에서 시험 조건을 만들며 누락된 경계값과 오류 상황을 찾고, 시험 결과에서 요구와 구현의 불일치를 발견한다.

요구사항과 시험 조건을 구분할 때는 “무엇이 참이어야 하는가”와 “그 사실을 어떤 조건에서 어떤 결과로 관찰할 것인가”를 나누어 묻는다. 시험 데이터나 특정 도구는 대체로 시험 설계에 속한다. 다만 규제나 계약이 검증 방법을 지정한다면 그 방법 자체가 프로젝트에 주어진 제약이 될 수 있다.

이 장에서 사용한 경계를 한 문장씩 정리하면 다음과 같다. 요구는 필요의 출발점이고, 목표는 도달하려는 상태이며, 요구사항은 필요를 검토 가능한 조건으로 표현한 것이다. 기능은 시스템이 제공하는 능력이고, 정책은 권한 있는 주체가 정한 의사결정 규칙이며, 제약은 해결 공간을 제한한다. 설계는 요구를 실현할 방법을 표현하고, 시험 조건은 충족 여부를 관찰할 상황을 정한다. 다음 장에서는 이 구분을 바탕으로 요구사항을 비즈니스·이해관계자·사용자·시스템·소프트웨어 수준과 기능·품질·데이터·인터페이스 유형으로 구조화한다.

수강신청 사례에 적용

판단 기준과 흔한 오류

직접 해보는 실습

핵심 요약

관련 도구와 다음 경로