1. 요구사항 관리의 중요성과 비즈니스 가치
정의: 사용자가 직면한 문제를 해결하거나 특정 목적을 달성하기 위해 소프트웨어가 갖추어야 할 조건이나 능력.
중요성: 불명확한 요구사항은 프로젝트 후반부의 재작업(Rework) 비용을 기하급수적으로 증가시키며, 고객 만족도 저하의 주요 원인이 됨.
2. 1) 소프트웨어(SW) 요구사항 품질속성
좋은 요구사항 정의서가 갖추어야 할 주요 속성은 IEEE 830 표준 등에서 제시하는 기준을 따릅니다.
| 속성 | 주요 내용 | 세부 설명 |
| 명확성 (Ambiguity) | 한 가지 의미로 해석 | 용어를 통일하고 모호한 표현(최대한, 신속히 등)을 배제 |
| 완전성 (Completeness) | 누락 없는 기술 | 사용자가 기대하는 기능을 빠짐없이 포함 |
| 일관성 (Consistency) | 요구사항 간 충돌 방지 | 동일 기능에 대해 서로 다른 정의나 모순이 없어야 함 |
| 추적성 (Traceability) | 출처 및 하위 단계 연결 | 요구사항의 기원과 설계/구현/테스트 단계 간 연결성 확보 |
| 검증 가능성 (Verifiability) | 테스트를 통한 확인 | 객관적인 기준에 의해 요구사항 충족 여부를 확인 가능해야 함 |
| 수정 용이성 (Modifiability) | 변경에 대한 유연성 | 구조적으로 잘 정리되어 영향도 분석과 수정이 쉬워야 함 |
3. 2) 요구사항 도출(Elicitation) 기법
이해관계자로부터 숨겨진 요구사항을 이끌어내기 위해 다양한 정성적·정량적 기법을 혼합하여 사용합니다.
인터뷰 (Interview): 이해관계자와 직접 대화하여 정보 수집. 개별적인 깊이 있는 요구사항 파악에 용이.
브레인스토밍 (Brainstorming): 자유로운 분위기에서 아이디어를 발산하여 창의적인 요구사항 도출.
설문조사 (Questionnaire): 다수의 사용자로부터 공통적인 요구사항을 저비용으로 수집할 때 효과적.
워크숍 (JAD/Joint Application Design): 분석가와 사용자가 한자리에 모여 집중적으로 토의하여 의사결정 가속화.
관찰 (Observation): 사용자의 실제 업무 환경을 관찰하여 명문화되지 않은 잠재적 요구사항(Tacit Knowledge) 발굴.
프로토타이핑 (Prototyping): 견본품을 만들어 시각화함으로써 사용자의 피드백을 조기에 확보.
4. 3) 요구사항 개발 프로세스 (Requirements Development Process)
요구사항 공학(Requirements Engineering) 관점에서 체계적인 단계를 거쳐 명세화합니다.
도출 (Elicitation): 이해관계자 식별 및 요구사항 수집. (Who, What 파악)
분석 (Analysis): 상충하는 요구사항 중재, 범위 확정, 모델링(UML 등)을 통한 논리적 구조화.
명세 (Specification): 분석된 내용을 바탕으로 요구사항 정의서(SRS) 작성. (문서화 단계)
확인 및 검증 (Validation): 이해관계자 검토(Review), 인스펙션(Inspection)을 통해 요구사항이 사용자의 의도와 일치하는지 확인 및 승인.
5. 기술사적 제언: 요구사항 변경관리와 추적성 관리(RTM)
변경 관리 체계(CCB): 프로젝트 진행 중 발생하는 요구사항 변경은 불가피하므로, 변경 영향도를 분석하고 공식적으로 승인하는 변경제어위원회(CCB) 운영이 필수적임.
요구사항 추적표(RTM): 요구사항이 설계(SD) - 소스코드(CD) - 테스트 케이스(TC)까지 어떻게 반영되었는지 추적하여 품질 누락을 방지해야 함.
결언: 요구사항 개발은 기술적인 영역보다 **'소통과 협상'**의 영역임. 기술사는 다양한 이해관계자의 상충하는 니즈를 조율하고, 비즈니스 가치를 극대화할 수 있는 **'요구사항 거버넌스'**를 구축해야 함.
댓글 없음:
댓글 쓰기