1. 요구사항 명세서(SRS)의 개요
정의: 사용자 및 이해관계자의 요구사항을 분석하여 시스템이 무엇(What)을 수행해야 하는지를 구체적, 명확하게 기술한 공식 문서.
중요성: * 의사소통의 도구: 개발자, 설계자, 사용자 간의 합의된 기준 제공.
검증의 척도: 차후 설계, 구현 및 테스트 단계의 기준점(Baseline) 역할.
변경 관리의 기준: 프로젝트 범위 산정 및 일정 관리의 근거.
2. 요구사항 명세서(SRS)에 기술되어야 하는 주요 항목
IEEE 830 표준 및 현대적 애자일 환경을 고려한 주요 구성 항목은 다음과 같습니다.
| 구분 | 주요 기술 항목 | 세부 설명 및 포함 내용 |
| 1. 개요 (Introduction) | 목적 및 범위 | 시스템의 개발 배경, 목표, 기대 효과 및 적용 범위 기술 |
| 용어 정의 | 프로젝트 전반에서 사용되는 전문 용어 및 약어 설명 | |
| 2. 기능 요구사항 (Functional) | 시스템 기능 | 사용자가 시스템을 통해 수행하고자 하는 구체적인 동작 및 서비스 |
| 입출력 데이터 | 각 기능별 데이터 입력 형식과 처리 결과물(출력) 정의 | |
| 3. 비기능 요구사항 (Non-Functional) | 품질 특성 | 성능(응답 시간), 가용성(99.9%), 신뢰성, 보안성, 유지보수성 |
| 제약 사항 | 특정 하드웨어, OS, 개발 언어, 규제 준수 등 기술적/환경적 제약 | |
| 4. 인터페이스 요구사항 | 외부 연동 | 타 시스템(Legacy, API), 하드웨어, 사용자 인터페이스(UI) 연동 규격 |
| 통신 프로토콜 | 데이터 전송을 위한 통신 방식 및 보안 프로토콜 정의 | |
| 5. 데이터 요구사항 | 논리적 데이터 모델 | 주요 엔티티(Entity) 정의 및 데이터 간의 관계(ERD 등) |
| 데이터 무결성 | 데이터 저장 및 처리에 대한 규칙과 보안 요건 |
3. 요구사항 명세서의 품질 측정 기준 (좋은 SRS의 특징)
명세서 기술 시 다음의 8가지 특성을 준수하여 작성해야 합니다.
무결성(Completeness): 사용자가 원하는 모든 기능이 빠짐없이 포함되어야 함.
명확성(Unambiguous): 한 가지 의미로만 해석되어야 하며, 모호한 표현 지양.
일관성(Consistency): 요구사항 간의 충돌이나 모순이 없어야 함.
검증 가능성(Verifiable): 객관적인 테스트를 통해 구현 여부를 확인할 수 있어야 함.
추적 가능성(Traceable): 요구사항의 출처와 하위 설계 문서 간의 연결 고리(RTM) 확보.
수정 용이성(Modifiable): 요구사항 변경 시 관련 내용을 쉽게 수정할 수 있는 구조.
4. 요구사항 추적 매트릭스(RTM)와 연계 방안
개념: 요구사항 명세서의 각 항목이 설계, 소스 코드, 테스트 케이스와 어떻게 연결되는지 매핑한 표.
효과: 요구사항 누락 방지, 변경 영향도 분석(Impact Analysis) 용이, 프로젝트 진척도 파악.
5. 기술사적 제언: 현대적 요구사항 관리의 핵심 'Agile & Tool'
도구 기반 관리: 복잡한 시스템에서는 Word나 Excel 기반의 문서화 한계를 극복하기 위해 Jira, Redmine 등 ALM(Application Lifecycle Management) 도구를 활용한 실시간 형상 관리 권장.
애자일과의 조화: 폭포수 모델의 정적인 SRS에서 탈피하여, User Story와 Backlog를 통해 사용자 요구를 유연하게 수용하고 반복적으로 명세화하는 전략 필요.
결언: 요구사항 명세서는 프로젝트의 '헌법'임. 기술사는 기술적 구현 가능성을 검토하는 동시에 이해관계자의 숨은 의도까지 명확히 명세화하여 **'Scope Creep(범위 산정 오류)'**을 사전에 방지하는 역량을 발휘해야 함.
댓글 없음:
댓글 쓰기