1. 요구공학(Requirement Engineering)의 정의 및 필요성
가. 요구공학의 정의
사용자의 요구사항을 식별하고, 분석하여 명세화하고 확인(Validation)하는 일련의 과정 및 이를 체계적으로 관리하는 공학적 접근 방법입니다.
비즈니스 목적을 기술적 사양으로 변환하여 개발자와 사용자 간의 의사소통 가교 역할을 수행합니다.
나. 요구공학의 필요성
프로젝트 성공 보장: 잘못된 요구사항 정의로 인한 재작업(Rework) 비용을 최소화합니다.
의사소통 오류 방지: 사용자-개발자 간의 이해 차이(Gap)를 줄여 신뢰성을 확보합니다.
변경 관리의 기준: 프로젝트 범위(Scope)를 명확히 하여 무분별한 요구사항 확장을 방지합니다.
품질 향상: 검증 가능한 요구사항을 통해 최종 산출물의 품질을 보증합니다.
2. 요구공학 절차 (Lifecycle)
요구공학은 크게 요구사항을 도출하고 개발하는 요구사항 개발 단계와, 이후 변경을 관리하는 요구사항 관리 단계로 나뉩니다.
| 단계 | 활동 내용 | 주요 기법/도구 |
| 요구 도출 (Elicitation) | 이해관계자의 잠재적 요구사항을 수집하는 단계 | 인터뷰, 설문조사, 브레인스토밍, 프로토타이핑 |
| 요구 분석 (Analysis) | 도출된 요구사항의 타당성을 조사하고 상충 관계를 해결 | 자료 흐름도(DFD), 유스케이스(Usecase), 가계도 |
| 요구 명세 (Specification) | 분석된 요구사항을 정형화된 문서로 작성하는 단계 | SRS(요구사항 명세서), 데이터 모델링, 정형 명세 |
| 요구 검증 (Validation) | 명세서가 사용자의 의도와 일치하는지 검토 | 인스펙션(Inspection), 워크스루, 베이스라인 설정 |
| 요구 관리 (Management) | 프로젝트 전반에 걸친 요구사항 변경 및 추적 관리 | RTM(요구사항 추적표), 변경통제위원회(CCB) |
3. 요구사항 명세서 (SRS; Software Requirement Specification)
가. 요구사항 명세서의 개념
시스템이 수행해야 할 기능, 성능, 제약사항 등을 구체적이고 명확하게 기록한 소프트웨어 개발의 기준 문서입니다.
나. 요구사항 명세서의 주요 구성 요소
기능적 요구사항 (Functional): 시스템이 무엇(What)을 해야 하는지에 대한 명세 (예: 로그인 기능, 결제 처리).
비기능적 요구사항 (Non-functional): 시스템의 품질 속성이나 제약사항 (예: 응답시간 1초 이내, 보안 표준 준수).
사용자 인터페이스(UI): 화면 구성 및 사용자 상호작용 방식.
외부 인터페이스: 타 시스템과의 연계 방식 및 데이터 규격.
다. 잘 작성된 명세서의 특징 (IEEE 830 기준)
무결성(Completeness): 모든 요구사항이 포함되어야 함.
명확성(Unambiguous): 한 가지 의미로만 해석되어야 함.
검증 가능성(Verifiable): 테스트를 통해 충족 여부를 확인할 수 있어야 함.
추적 가능성(Traceable): 요구사항의 기원과 관련 설계/코드를 추적할 수 있어야 함.
4. 기술사적 제언: 현대적 요구공학의 진화
최근의 소프트웨어 개발 환경은 Waterfall 방식에서 Agile 및 DevOps로 변화하고 있으며, 요구공학 또한 이에 맞춰 진화하고 있습니다.
User Story 중심: 긴 명세서 대신 사용자 관점의 짧은 이야기(As a user, I want...)를 통해 민첩성을 확보합니다.
Backlog Management: 요구사항을 백로그로 관리하여 비즈니스 우선순위에 따라 유연하게 배포합니다.
추적성 도구 활용: Jira, Redmine 등의 도구를 통해 요구사항부터 테스트 결과까지의 Traceability를 자동화하여 관리해야 합니다.
댓글 없음:
댓글 쓰기