요구사항 분석·명세·확인·추적성
요구사항 분석·명세·확인 과정과 품질 기준, 추적성을 활용한 변경 관리 방법을 익힌다.
분석·명세·확인의 관계
- 분석: 요구를 분류·분해하고 관계·충돌·우선순위·타당성을 검토한다.
- 명세: 합의된 요구를 문장·표·모델 등으로 정확히 기록한다.
- 확인: 명세된 요구가 이해관계자의 실제 필요와 맞고 품질 기준을 만족하는지 점검한다.
- 관리: 요구의 상태·버전·출처·변경·추적 관계를 유지한다.
요구사항 분석
분석에서는 다음을 수행한다.
- 기능·비기능·제약으로 분류
- 상위 요구를 구현·검증 가능한 단위로 분해
- 요구 간 의존·중복·충돌 확인
- 모델을 이용해 흐름·구조·상호작용 표현
- 기술·비용·일정 측면의 실현 가능성 검토
- 중요도·위험·의존성을 고려한 우선순위 결정
요구와 해결책을 구분해야 한다. “주문 상태를 실시간으로 알고 싶다”는 필요이고, “특정 실시간 통신 기술을 사용한다”는 설계 대안이다.
요구사항 명세
| 방식 | 특징 | 장점·주의점 |
|---|---|---|
| 비정형 명세 | 자연어 중심 | 이해하기 쉽지만 모호성·중의성 가능 |
| 반정형 명세 | 표, 다이어그램, 정해진 양식 | 구조화와 검토가 쉬움 |
| 정형 명세 | 수학적 기호와 엄밀한 규칙 | 정확성이 높지만 전문성·비용 필요 |
실무에서는 자연어, 표, UML, 상태·흐름 모델 등을 위험과 독자에 맞게 함께 쓸 수 있다.
좋은 개별 요구사항
- 한 문장에 하나의 중심 요구를 담는다.
- 주체·조건·행동·결과를 분명히 한다.
- “적절히”, “가능한 빨리” 같은 모호한 표현을 피한다.
- 측정·관찰 가능한 검증 기준을 둔다.
- 다른 요구와 모순되지 않게 한다.
- 고유 식별자를 부여한다.
요구사항 품질 기준
| 기준 | 확인 질문 |
|---|---|
| 완전성 | 필요한 기능·조건·예외가 빠지지 않았는가? |
| 일관성 | 다른 요구와 충돌하지 않는가? |
| 명확성 | 하나의 의미로 해석되는가? |
| 실현 가능성 | 기술·비용·일정 안에서 구현 가능한가? |
| 검증 가능성 | 시험이나 검토로 충족 여부를 판정할 수 있는가? |
| 추적 가능성 | 출처와 후속 산출물에 연결되는가? |
| 수정 용이성 | 변경 위치와 영향이 식별되는가? |
Verification과 Validation
- Verification: 요구사항을 규칙과 형식에 맞게 올바르게 명세했는가?
- Validation: 올바른 요구사항, 즉 사용자가 실제 필요로 하는 것을 명세했는가?
문헌에서 ‘검증·확인’ 번역이 뒤바뀌기도 하므로 영문 용어와 질문을 함께 본다.
검토 기법
| 기법 | 대표 특징 |
|---|---|
| 동료 검토(Peer Review) | 동료가 결함과 개선점을 검토하는 일반적 활동 |
| 워크스루(Walkthrough) | 작성자가 설명하며 참여자가 질문·의견을 제시 |
| 인스펙션(Inspection) | 역할·절차·체크리스트가 정해진 공식적 검토 |
| 프로토타입 평가 | 실제 상호작용을 보여 요구의 적합성을 확인 |
| 인수 기준 검토 | 충족 여부를 판정할 수 있는 기준인지 확인 |
추적성과 변경 관리
요구사항 추적 매트릭스 예시
추적 방향
- 정방향 추적: 요구사항 → 설계 → 구현 → 시험
- 역방향 추적: 시험·구현 → 근거 요구사항
- 출처 추적: 요구사항 → 이해관계자·법규·업무 문서
- 요구 간 추적: 상위·하위 요구, 의존·충돌 관계
양방향 추적은 “모든 요구가 구현·시험되었는가”와 “불필요한 구현은 없는가”를 함께 확인하게 한다.
기준선과 변경
기준선(Baseline)은 검토·승인되어 변경 통제의 기준이 된 상태다. 변경이 금지된 문서가 아니라, 승인된 절차를 통해 변경해야 하는 문서다.
변경 요청이 들어오면 영향받는 요구·설계·코드·시험·일정을 추적하고, 승인 후 버전과 관계를 갱신한다. 요구사항 관리 도구는 이력·상태·링크 관리를 지원하지만 합의 자체를 대신하지 않는다.