[SRS]사용자 요구사항 정의서

소프트웨어 개발 단계

1. RFP(Request For Proposal)를 통해 제안요청
2. SRS(Software requirements specification)를 통해 프로젝트의 큰 그림 설계. 관리자는 인력, 시간, 돈의 관점에서 성공적인 프로젝트를 수행할 수 있게 전략적으로 접근 - 기획의 범주
3. 개발할 소프트웨어를 분석하는 과정

• 분석 - 사용자 요구사항 정의서, 유스 케이스 명세서, 요구사항 추적표와 같은 문서 작성
• 설계 - SRS 기반. 클래스 설계서, 사용자 인터페이스 설계서, 컴포넌트 설계서, 인터페이스 설계서, 아키텍처 설계서, 총괄시험 계획서, 시스템시험 시나리오, 엔티티 관계 모형 기술서, 데이터베이스 설계서, 통합시험 시나리오, 단위시험 케이스, 데이터 전환 및 초기데이터 설계서 같은 문서
• 구현 - 실제 개발 작업. 프로그램 코드, 단위시험 결과서, DB 생성 스크립트 등을 문서화 하여 개발의 진행 정도를 알 수 있게 가시화
• 시험 - 통합시험 결과서, 시스템시험 결과서, 사용자 지침서, 운영자 지침서, 시스템 설치 결과서, 인수시험 시나리오, 인수시험 결과서와 같은 문서. 사용자, 운영자를 위한 지침서(매뉴얼) 작성

---

사용자 요구사항 정의서

1. 작성 목적

   • 시스템의 요구사항 도출, 발주자와 내용 합의

   • 하나의 업무 단위로서 가치를 가지고 수행될 수 있는 업무 도출하여 업무 내용 기술

     • NIA(한국정보화진흥원)의 정의
       • 고객의 요청 사항을 기반으로 SRS의 협의 내용을 적용하고 실제 개발에 적용할 수 있는 수준으로 요구사항을 재정의 하라는 의미입니다. 문서의 제목 그대로를 이해하는것이 개념을 잡는데 유리할 수 있습니다.

2. 작성 방법

   • 산출물 양식의 표
   • 해당 항목에 기술하며 이해하기 쉽고 구체적인 언어표현 사용

   • 기능적 요구사항과 비기능 요구사항 그룹핑, 별도의 표로 작성

     • 기능적 요구사항 - ‘현금 입출금 시스템’을 만든다고 가정했을 때 ‘현금 출금 기능’과 같은 동작을 수행하는 모든 행위
     • 비기능 요구사항이란 ‘시스템 관리자가 조직 변경에 따른 권한 변경이 있을 경우, 이를 1분 이내에 적용할 수 있어야 한다’ 와 같은 성능적인 측면이나 다른 의미의 비기능적인 항목

3. 항목 설명

   • 요구사항 ID - 요구사항별로 유일한 ID를 부여하여 기입

   • 요구사항명 - 도출된 요구사항을 요약할 수 있는 명칭을 기입

   • 구분 - 도출된 요구사항을 기능 / 성능 / 품질 / 인터페이스 / 데이터 / 운영 / 제약사항 중에서 선택하여 기재

   • 요구사항 설명 - 사용자 요구사항을 구체적이고 상세하게 기술

   • 중요도 - 해당 요구사항의 전체 시스템 구현 측면에서의 중요도를 기술(상, 중, 하)

   • 비고 - 항목에 포함되지 않으나, 고려해야 할 사항이 있으면 기술