요구공학과 요구사항 관리

1. 요구공학의 목적

요구공학은 이해관계자가 원하는 문제와 시스템이 제공해야 할 기능·품질·제약을 식별하고 합의 가능한 형태로 관리하는 활동이다.

이해관계자·업무 문제
        │
        ▼
     요구 도출
        ▼
     요구 분석
        ▼
     요구 명세
        ▼
     요구 검증
        │
        └──────────────┐
                       ▼
                 요구 변경관리
                       │
                       └─ 추적성 유지

개발 초기에 요구 오류를 발견하면 설계·구현 이후 발견하는 것보다 수정 비용과 파급을 줄일 수 있다.

2. 이해관계자와 요구 수준

이해관계자는 시스템에 영향을 주거나 영향을 받는 사람·조직·외부 시스템이다.

• 최종 사용자
• 업무 담당자·관리자
• 발주자·운영자·보안 담당자
• 개발·테스트 조직
• 규제기관·외부 연계 시스템

요구는 수준에 따라 다음처럼 구분할 수 있다.

비즈니스 요구
   └─ 사용자 요구
       └─ 시스템 요구
           ├─ 기능 요구
           ├─ 비기능 요구
           └─ 인터페이스·제약조건

3. 기능 요구와 비기능 요구

“빠르게 처리한다”보다 측정 가능한 수치와 조건을 포함해야 검증할 수 있다.

4. 요구사항 도출 기법

• 인터뷰
• 설문
• 관찰·업무 현장 조사
• 워크숍·JAD
• 브레인스토밍
• 기존 문서·시스템 분석
• 프로토타입
• 유스케이스·사용자 스토리

기법 하나로 모든 요구를 찾기 어렵다. 사용자가 말하는 요구와 실제 업무 관찰 결과가 다를 수 있으므로 여러 방법을 결합한다.

5. 요구 분석

분석 단계에서는 요구를 분류하고 충돌·중복·누락·모호성을 해결한다.

원시 요구 목록
   ├─ 중복 제거
   ├─ 충돌 조정
   ├─ 범위 밖 요구 분리
   ├─ 우선순위 결정
   ├─ 모델 작성
   └─ 수용 기준 정의

대표 우선순위 기법인 MoSCoW는 Must, Should, Could, Won't for now로 구분한다. 우선순위는 중요도뿐 아니라 비용, 위험, 의존성, 법적 의무를 함께 고려한다.

6. 요구사항 명세

좋은 요구사항은 다음 성질을 지향한다.

• 정확성
• 명확성·비모호성
• 완전성
• 일관성
• 실현 가능성
• 검증 가능성
• 추적 가능성
• 고유 식별 가능성

예시:

나쁜 요구:
- 시스템은 빠르게 검색해야 한다.

개선 요구:
- 데이터 100만 건 조건에서 일반 검색 요청의 95백분위 응답시간은
  정상 부하 시 2초 이하여야 한다.

SRS는 시스템 요구사항을 구조적으로 기록한 문서이다. 조직과 프로젝트에 따라 형식은 달라질 수 있으나 범위, 기능, 품질, 인터페이스, 제약조건, 수용 기준을 포함한다.

7. 유스케이스와 사용자 스토리

유스케이스는 액터가 목표를 달성하기 위해 시스템과 상호작용하는 흐름을 기술한다.

유스케이스: 비밀번호 재설정
액터: 회원
사전조건: 등록된 계정이 존재함

기본 흐름
1. 회원이 재설정을 요청한다.
2. 시스템이 본인확인 수단을 전송한다.
3. 회원이 유효한 확인값을 입력한다.
4. 회원이 새 비밀번호를 입력한다.
5. 시스템이 정책을 검사하고 비밀번호를 변경한다.

대안·예외 흐름
- 확인값이 만료됨
- 시도 횟수를 초과함
- 새 비밀번호가 정책을 만족하지 않음

사용자 스토리는 보통 사용자·목표·가치를 간결하게 표현하고 수용 기준을 별도로 둔다.

8. 요구 검증

요구 검증은 작성된 요구가 실제 필요와 품질 기준을 충족하는지 확인한다.

• 리뷰·워크스루
• 프로토타입 확인
• 테스트 케이스 사전 작성
• 모델 일관성 검사
• 이해관계자 승인
• 법·표준·인터페이스 검토

필요한 요구인가?
서로 충돌하지 않는가?
빠진 예외 흐름은 없는가?
구현 가능한가?
테스트로 확인 가능한가?
출처와 설계·테스트 결과를 추적할 수 있는가?

9. 추적성

추적성은 요구의 출처부터 설계·코드·테스트·배포까지 연결 관계를 유지하는 성질이다.

업무 목표
   ↓
요구사항
   ↓
분석·설계
   ↓
구현
   ↓
테스트
   ↓
운영 변경

10. 요구 변경관리

변경 요청 등록
   ↓
변경 사유·범위 확인
   ↓
영향 분석: 비용·일정·품질·보안·테스트
   ↓
승인 또는 거절
   ↓
요구 기준선·문서·추적표 갱신
   ↓
설계·구현·테스트 반영 후 확인

요구가 바뀌는 것 자체가 실패는 아니다. 통제 없이 변경되어 범위·일정·품질이 무너지는 것이 문제이다.

11. 검증과 확인, 파생 요구사항

Verification: 요구 문서를 올바르게 작성했는가?
- 명확성, 일관성, 완전성, 추적성, 형식 준수

Validation: 올바른 문제와 사용자 필요를 요구로 잡았는가?
- 실제 업무 적합성, 이해관계자 목표, 수용 가능성

상위 시스템 요구·법규·아키텍처 결정에서 새로 도출되는 요구를 파생 요구사항이라 한다. 예를 들어 “결제 승인 후 2초 안에 응답”이라는 시스템 성능 요구로부터 API 타임아웃, 큐 지연, DB 조회시간 예산이 파생될 수 있다.

12. 품질속성 시나리오

비기능 요구는 다음 요소로 구체화하면 검증과 테스트에 연결하기 쉽다.

Source      : 누가 또는 무엇이 자극을 발생시키는가
Stimulus    : 어떤 사건인가
Environment : 정상·과부하·장애 등 어떤 조건인가
Artifact    : 어느 시스템 요소가 대상인가
Response    : 시스템이 어떻게 반응하는가
Measure     : 수치로 무엇을 확인하는가

예: “정상 운영 중 외부 결제망이 30초 동안 응답하지 않으면 결제 서비스는 2초 이내에 타임아웃을 반환하고 중복 결제가 발생하지 않아야 한다.”

13. 수용 기준과 Given-When-Then

Given  등록된 회원과 유효한 인증 토큰이 있고
When   회원이 비밀번호 변경을 요청하면
Then   정책을 만족하는 경우 변경되고 기존 세션은 5분 안에 폐기된다.

수용 기준은 구현 방법이 아니라 관찰 가능한 결과와 경계·예외 조건을 명시한다.

14. 추적성 지표와 누락 탐지

요구 테스트 연결률 = 테스트가 연결된 요구 수 / 전체 요구 수 × 100

• 요구에 테스트가 없으면 검증 누락 가능성이 있다.
• 테스트에 요구·위험 근거가 없으면 불필요 테스트나 숨은 요구 가능성이 있다.
• 폐기된 요구에 연결된 설계·코드·테스트는 영향 분석 대상이다.

추적 링크 수가 많다고 품질이 자동으로 높아지는 것은 아니다. 링크의 최신성·방향·근거를 함께 관리한다.

15. 변경 영향 그래프

REQ-12 변경
 ├─ 유스케이스 UC-04
 ├─ API 계약 API-07
 ├─ 모듈 PaymentService
 ├─ DB 스키마 PAY_TX
 ├─ 테스트 TC-81~96
 └─ 운영 매뉴얼 OPS-03

변경 승인 전에는 직접 영향뿐 아니라 인터페이스, 데이터 마이그레이션, 보안, 회귀 테스트, 일정·비용을 확인한다. 승인 후에는 기준선과 추적표를 같은 변경 식별자로 갱신한다.

확인 문제

1. 요구 문서의 명확성·일관성을 검사하는 활동은 verification과 validation 중 무엇인가?
2. 상위 요구나 설계 제약에서 새로 도출되는 요구를 무엇이라 하는가?
3. 품질속성 시나리오에서 응답시간 2초는 어느 요소에 해당하는가?
4. 전체 요구 40개 중 테스트가 연결된 요구가 36개라면 연결률은 얼마인가?
5. 변경 영향 분석에서 요구와 직접 연결된 코드만 확인하면 충분한가?