PE Notes · 사업관리
요구사항명세서 SRS
SRS를 계약과 설계·시험의 기준선으로 두고, IEEE 29148 감각의 서론·전체 설명·특정 요구 구조와 기능·비기능, 과업기술서와의 자리를 정리합니다.
말로 합의하면 개발자마다 다른 시스템을 그립니다. 는 기능·비기능·제약을 한 문서로 고정한 소프트웨어 요구 명세입니다. 발주와 수행이 같은 문장을 보고, 설계와 시험이 그 문장을 기준으로 삼습니다. 옛 IEEE 830의 뼈대를 ISO/IEC/IEEE 29148이 이었습니다. 두꺼운 책이 목적이 아니라, 한 가지로만 읽히는 기준선이 목적입니다.
품질과 세 덩어리
좋은 요구는 빠짐이 없고, 서로 안 싸우며, 해석이 하나입니다. 시험으로 맞는지 볼 수 있고, 출처와 설계·시험으로 이어지며, 고치기 쉬운 구조이고, 우선이 보입니다. “빠르고 안전해야 한다”는 명세가 아닙니다. “동시 1,000명에서 응답 2초를 99% 유지한다”가 명세입니다.
29148 감각의 큰 칸은 셋입니다. 서론은 목적·범위·용어·참고·개요입니다. 전체 설명은 제품이 놓인 자리, 기능 요약, 사용자 특성, 기술·법 제약, 가정과 의존입니다. 특정 요구가 본론입니다. 기능 하나하나, 성능·보안·가용성 같은 비기능, 화면·API·하드웨어 인터페이스를 여기서 닫습니다.
| 품질 | 한 줄 |
|---|---|
| 완전 | 빠진 요구가 없다 |
| 일관 | 요구끼리 모순이 없다 |
| 명확 | 해석이 하나다 |
| 검증 | 시험으로 판정한다 |
| 추적 | 출처·설계·시험으로 잇는다 |
| 수정 | 한 곳을 고쳐도 무너지지 않는다 |
| 우선 | 무엇부터인지를 표시한다 |
기능과 비기능
기능은 시스템이 하는 일입니다. 로그인, 결제, 조회입니다. 나 스토리로 적되, 입력·처리·출력·예외가 보이게 합니다. 비기능은 얼마나·어떻게입니다. 응답, 가용성, 암호화, 접근성입니다. 의 품질 특성이 비기능 칸의 이름표가 됩니다. 기능 시험만 통과하고 부하·보안이 비면 인수가 서지 않습니다.
| 비교축 | 기능 | 비기능 |
|---|---|---|
| 질문 | 무엇을 하는가 | 얼마나·어떻게 |
| 표현 | 유스케이스, 스토리 | 성능·보안·가용성 숫자 |
| 검증 | 기능 시험 | 성능·보안·운영 시험 |
은 글로 안 잡히는 화면을 합의하는 수단입니다. 껍데기를 SRS 대신으로 두면 기준선이 사라집니다. 애자일은 스토리와 얇은 명세를 같이 가되, 규제·인터페이스는 시스템 사이 문장을 SRS에 남깁니다.
과업·수집·WBS
과업기술서·는 발주가 무엇을 살지 고르는 계약 문장입니다. SRS는 그 구매를 공학으로 풀어 쓴 상세입니다. 작성 주체도 다릅니다. 발주 과업은 기관이, SRS는 분석·개발이 닫습니다. 와 수집 기법이 입구이고, 추적표가 설계·모듈·시험으로 잇고, 가 작업 패키지로 내립니다. 마다 비밀 요구가 있으면 일관성이 먼저 깨집니다.
공공은 검사 기준이 SRS 문장과 같아야 합니다. 금융은 규제 조항을 비기능에 번호로 남깁니다. 답안은 정의(기준선), 품질 일곱, 세 덩어리, 기능≠비기능, 과업≠SRS, RTM·WBS 연결을 한 장에 닫습니다.