시스템 요구사항 정의서 - siseutem yogusahang jeong-uiseo

요구사항 정의서(=요구사항 기술서)는 말그대로 고객의 요구를 정리하는 문서다. 요구분류, 요구사항ID, 요구사항명, 요구사항내용, 수용여부, 우선순위, 요구적용일자 등으로 구성된다. 이 밖에도 다양한 컬럼들이 있지만 개인적으로 필요한 컬럼만 명시하였다.

시스템 요구사항 정의서 - siseutem yogusahang jeong-uiseo

1. 요구분류

 (예시) "신규", "기능개선", "결함수정", "유지" 
해당 요구사항의 성격을 규정한다. 만약 새로운 시스템을 구축한다면, 요구분류 항목은 모두 "신규"일 것이다. 하지만 모든 개발 프로젝트가 새로운 시스템을 구축하는 것은 아니기 때문에 이러한 항목이 필요하다.

2. 요구사항ID

요구사항을 관리하기 용이하도록 요구사항마다 ID를 부여한다. 요구사항 코드를 이용하거나 기능적으로 구분 (FR:기능, NFR:비기능) 하는 등의 기준에 맞춰서 작성한다.

3. 요구사항명

 (예시) 메인의 글검색 기능, 메인의 로그인 기능
요구사항을 가시적으로 명확히 하기 위해 요구사항 이름이 필요하며 대/중/소에서 "소"분류 수준이다.

4. 요구사항 내용

 (예시) 제목, 내용으로 글검색이 가능하다.

해당 요구사항에 대한 부연 설명을 달아둔다.

5. 수용여부

 (예시) "수용", "보류", "기각"
해당 요구사항을 수용했는지에 대한 여부이다.

6. 우선순위

 (예시) "최상", "상", "중", "하"
해당 요구사항의 우선순위를 규정한다.

7. 요구적용일자

구축 예정날짜 또는 적용 예정날짜이다.

요구사항+기술서+샘플.xlsx

0.01MB

2017. 12. 28. 13:29

서비스를 구현하기 위해 다양한 요구사항이 거론되는데, 이를 명확하게 정리해야 할 필요가 있습니다. 요구사항 명세서는 요구사항을 분석하여 명확하고 완전하게 기록하는 것을 말합니다. 소프트웨어 시스템이 수행해야 할 모든 기능과 구현상의 제약 조건에 대해 개발자와 관련자(클라이언트, 기획자, 경영진 등)가 합의한 스펙에 대한 사항을 명세합니다.

요구사항 명세서(SRS, Software Requirements Specification)은 요구사항 정의서, 요구사항 기술서도 같은 의미로 봐도 무방합니다. 주로 외주 형태에서 작성되는 문서였으나, 스타트업에서도 내부 의견을 정리하기 위해 작성하는 것이 좋습니다.

왜 작성할까요?

작성된 요구사항 명세서를 토대로 회의가 진행됩니다. 실제 필요한 기능인지, 개발 이슈는 없는지, 이번 단계(버전)에서 개발하는 것이 좋은 것인지에 대해 검토합니다. 피드백된 내용 또한 업데이트하여 관리합니다.

  • 프로젝트 전체 규모를 파악
  • 구현 가능 여부에 대한 논의
  • 커뮤니케이션 비용 절약
  • 프로젝트 일정 계획 수립

무엇을 기재해야 할까요?

요구사항 명세서는 공식적으로 사용하는 양식은 없지만, 필수로 기재 해야 하는 항목은 대게 유사합니다.

실제 작성한 요구사항명세서

좋은 요구사항 명세서가 가지고 있는 특징

  • 요구사항 명세서를 읽는 작업자(개발자, 디자이너 등)가 이해하기 쉬워야 한다.
  • 무엇을 어떻게 구현되어야 하는지 명확하게 작성한다.
  • 하나의 요구사항에 여러가지(복수) 요구사항을 작성하지 않는다.
  • 다른 요구사항 모순 또는 중복되지 않게 한다.
  • 애매한 단어를 사용하지 않고 명확하게 기재한다. ( ~ 있으면 좋겠다 → ~ 기능 필요) 오해하지 말아야 할 것이 명령하는 것이 아니고 의견을 모호하게 하지 말고 명확하게 표현하라는 의미이다.
  • 꼭 필요하고 중요한 요구사항은 표시하는 것이 좋다. 다만 모든 요구사항에 남발 해서는 안된다.
  • 동일한 용어를 사용한다. 댓글, 코멘트, 덧글과 같이 모두 같은 의미를 다르게 표현하지 말라는 의미이다.
  • 난이도가 있는 기능이거나 프로젝트 기간이 짧아 모든 요구사항을 구현하기 어려울 상황일 경우, 대체 가능한 다른 방법도 함께 기술하여 전달하는 것이 좋다.

요구사항 명세서 샘플

처음에는 샘플을 통해 작성하고, 자신이 속한 팀에 맞게 항목을 추가/삭제하여 사용하는 것을 적극 추천하고, 프로젝트 규모와 상황에 따라 다르지만 구글 드라이브를 사용하여 작성하는 것이 좋고 편리합니다.

요구사항명세서(구글 드라이브) — 직접 작성한 자료

요구사항명세서.xls — 공개된 자료

요구사항 정의서(기술서, 명세서)

SRS, Software Requirements Specification.

서비스를 구현하기 위한 다양한 요구사항을 분석하여명확하고 완전하게 정리 기록한 문서.

소프트웨어 시스템이 수행해야 할 모든 기능과 구현상의 제약 조건에 대해 개발자와 관련자(클라이언트, 기획자, 경영진 등)가 합의한 스펙에 대한 사항을 명세한다.

작성된 명세서를 토대로 회의가 진행된다. 실제 필요한 기능인지, 개발 이슈는 없는지, 이번 버전에서 개발하는 것이 좋은 것인지에 대해 검토한다. 피드백된 내용 또한 업데이트하여 관리한다.

공식적 양식은 없지만 필수 기재 항목은 대개 유사하다.

실제 작성된 요구사항명세서

요구사항명세서(구글 드라이브) — 직접 작성한 자료

요구사항명세서.xls — 공개된 자료

[출처 : https://to2.kr/a12 ]

요구사항의 개념 및 특징
요구사항은 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건 등을 나타냄

요구사항의 유형
요구사항은 일반적으로 기술하는 내용에 따라 기능 요구사항과 비기능 요구사항으로 구분하며, 기술 관점과 대상의 범위에 따라 시스템 요구사항과 사용자 요구사항으로 나눈다.

기능 요구사항
- 시스템이 무엇을 하는지, 어떤 기능을 하는지에 대한 사항
- 시스템의 입력이나 출력으로 무엇이 포함되어야 하는지에 대한 사항
- 시스템이 어떤 데이터를 저장하거나 연산을 수행해야 하는지에 대한 사항
- 시스템이 반드시 수행해야 하는 기능
- 사용자가 시스템을 통해 제공받기를 원하는 기능

비기능 요구사항
- 시스템 장비 구성 요구사항: 하드웨어, 소프트웨어, 네트워크 등의 시스템 장비 구성에 대한 요구사항
- 성능 요구사항: 처리 속도 및 시간, 처리량, 동적 정적 적용량, 가용성 등 성능에 대한 요구사항
- 인터페이스 요구사항: 시스템 인터페이스와 사용자 인터페이스에 대한 요구사항으로 다른 소프트웨어, 하드웨어 및 통신
- 인터페이스, 다른 시스템과의 정보 교환에 사용되는 프로토콜과의 연계도 포함하여 기술
- 데이터 요구사항: 도입되는 장비의 성능 테스트나 구축된 시스템이 제대로 운영되는지를 테스트하고 점검하기 위한 테스트 요구사항
- 보안 요구사항: 시스템의 데이터 및 기능, 운영 접근을 통제하기 위한 요구사항
- 품질 요구사항: 관리가 필요한 품질 항목, 품질 평가 대상에 대한 요구사항으로 가용성, 정합성, 상호 호환성, 신뢰성, 사용성, 유지 관리성, 이식성, 확장성, 보안성 등으로 구분하여 기술
- 제약사항: 시스템 설꼐, 구축, 운영과 관련하여 사전에 파악된 기술, 표준, 업무, 법 제도 등의 제약조건
- 프로젝트 관리 요구사항: 프로젝트의 원활한 수행을 위한 관리 방법에 대한 요구사항
- 프로젝트 지원 요구사항: 프로젝트의 원활한 수행을 위한 지원 사항이나 방안에 대한 요구사항

사용자 요구사항
- 사용자 관점에서 본 시스템이 제공해야 할 요구사항
- 사용자를 위한 것으로 친숙한 표현으로 이해하기 쉽게 작성

시스템 요구사항
- 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항
- 사용자 요구사항에 비해 전문적이고 기술적인 용어로 표현
- 소프트웨어 요구사항이라고도 함

*가용성: 사용하고자 할 때 언제라도 사용할 수 있는 정도
*정합성: 데이터의 값이 서로 모순 없이 일관되게 일치하는 정도
*상호 호환성: 다른 소프트웨어와 정보를 교환할 수 있는 정도
*대응성: 발생한 상황에 대처하는 정도
*이식성: 다양한 하드웨어 환경에서도 운용 가능하도록 쉽게 수정될 수 있는 정도
*확장성: 규모나 범위를 넓힐 수 있는 정도

요구사항 개발 프로세스
- 요구사항 개발 프로세스는 개발 대상에 대한 요구사항을 체계적으로 도출하고 이를 분석한 후 분석 결과를 명세서에 정리한 다음 마지막으로 이를 확인 및 검증하는 일련의 구조화된 활동
- 요구공학의 한 요소

도출 -> 분석 -> 명세 -> 확인

*요구공학: 무엇을 개발해야 하는지 요구사항을 정의하고, 분석 및 관리하는 프로세스를 연구하는 학문


요구사항 도출 (요구사항 수집)
- 시스템, 사용자, 그리고 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항이 어디에 있는지, 어떻게 수집할 것인지를 식별하고 이해하는 과정
- 소프트웨어가 해결해야 할 문제를 이해하는 첫단계
- 이 단계에서 개발자와 고객 사이의 관계가 만들어지고 이해관계자가 식별됨
- 소프트웨어 개발 생명 주기 동안 지속적으로 반복
- 주요기법으로는 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스 등이 있음

요구사항 분석
- 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정
- 요구사항의 타당성을 조사하고 비용과 일정에 대한 제약을 설정
- 내용이 중복되거나 하나로 통합되어야 하는 등 서로 상충되는 요구사항이 있으면 이를 해결
- 도출된 요구사항들을 토대로 소프트웨어의 범위를 파악
- 도출된 요구사항을 토대로 소프트웨어와 주변 환경이 상호 작용하는 방법을 이해

요구사항 명세
- 요구사항을 체계적으로 분석한 후 승인될 수 있도록 문서화 하는 것
- 사용자가 이해하기 쉬우며, 개발자가 효과적으로 설계할 수 있도록 작성
- 설계 과정에서 잘못된 부분이 확인될 경우 그 내용을 요구사항 정의서에 추적할 수 있어야 함

요구사항 확인 (요구사항 검증)
- 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하고 완전하게 작성되었는지를 검토하는 활동
- 내용이 이해하기 쉬운지, 일관성이 있는지, 회사 기준에 맞는지, 누락된 기능이 없는지 등을 검증
- 이해관계자들이 검토해야 함
- 일반적으로 요구사항 관리 도구를 이용하여 요구사항 정의 문서들에 대해 형상관리를 수행

*형상관리: 소프트웨어 개발 단계의 각 과정에서 만들어지는 프로그램, 프로그램을 설명하는 문서, 데이터 등을 통칭하여 형상이라고 한다. 형상 관리는 소프트웨어 의 개발과정에서 만들어지는 형상들의 변경 사항을 관리하는 일련의 활동을 의미

참조 : 도서 '시나공 2020 정보처리기사 필기'