요구사항 정의서

소프트웨어 개발 단계

RFP(Request For Proposal)를 통해 제안요청을 하고 프로젝트 계약이 완료되면 SRS(Software requirements specification)를 통해 프로젝트의 큰 그림을 설계합니다. 이때 프로젝트 관리자는 인력, 시간, 돈의 관점에서 성공적인 프로젝트를 수행할 수 있게 전략적으로 접근합니다. 이 과정을 프로젝트를 도입하고 시행하기 위한 기획의 범주라고 가정했을 때 그 다음은 개발할 소프트웨어를 분석하는 과정이 필요합니다. 하나의 프로젝트가 올바르고 안정적으로 진행되려면 다음과 같은 과정을 거쳐야 합니다.

• 분석 단계

소프트웨어를 개발하기 위해서 만들려고 하는 것에 대한 분석이 먼저 이루어집니다. 사용자 요구사항 정의서, 유스 케이스 명세서, 요구사항 추적표와 같은 문서를 작성함으로써 보다 구체적으로 분석합니다.

• 설계 단계

분석이 끝났다면 실제로 구현하기 위해서 올바른 설계를 합니다. 설계 또한 이전에 작성됐던 SRS를 기반으로 하여 범주에 벗어나지 않는 설계를 할 필요가 있습니다. 설계 단계에서는 클래스 설계서, 사용자 인터페이스 설계서, 컴포넌트 설계서, 인터페이스 설계서, 아키텍처 설계서, 총괄시험 계획서, 시스템시험 시나리오, 엔티티 관계 모형 기술서, 데이터베이스 설계서, 통합시험 시나리오, 단위시험 케이스, 데이터 전환 및 초기데이터 설계서와 같은 문서를 작성함으로써 보다 구체적으로 설계합니다.

• 구현 단계

분석 → 설계의 과정을 통해 실질적인 구현의 준비를 마무리합니다. 구현 단계에서는 실제 개발 작업이 이루어지며 소프트웨어의 모습이 갖춰지는 단계입니다. 프로그램 코드, 단위시험 결과서, DB 생성 스크립트 등을 문서화 하여 개발의 진행 정도를 알 수 있게 가시화 합니다.

• 시험 단계

구현이 완료되면 전체적인 테스트를 할 필요가 있습니다. 통합시험 결과서, 시스템시험 결과서, 사용자 지침서, 운영자 지침서, 시스템 설치 결과서, 인수시험 시나리오, 인수시험 결과서와 같은 문서를 작성함으로써 보다 구체적으로 시험을 진행합니다. 또한 시험 단계에서 사용자, 운영자를 위한 지침서(매뉴얼)를 작성합니다.

사용자 요구사항 정의서

분석 단계에서 요구되는 모든 문서를 작성해보고 이를 실제 프로젝트를 진행하는 구현 단계에서 참조 자료로 활용해보면 좋겠으나 시간이 부족하다는 점과 실제 개발 업무가 아닌 학습을 위한 프로젝트 과정임을 감안하여 내용을 축소해야 합니다. 하지만 분석 단계에서 작성하는 ‘사용자 요구사항 정의서'는 매우 중요합니다. 그러므로 우리는 ‘사용자 요구사항 정의서'를 작성해 볼 필요가 있습니다.

1. 작성 목적

시스템의 요구사항을 도출하여 발주자와 내용을 합의하고, 하나의 업무 단위로서 가치를 가지고 수행될 수 있는 업무를 도출하여 업무 내용을 기술합니다.

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

2. 작성 방법

산출물 양식의 표를 이용하여 해당 항목에 기술하며 이해하기 쉽고 구체적인 언어표현을 사용한다. 기능적 요구사항과 비기능 요구사항을 그룹핑하여 별도의 표로 작성한다.

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

3. 항목 설명

(이해를 돕기위해 문서 양식에 예제 추가)

• 요구사항 ID : 요구사항별로 유일한 ID를 부여하여 기입합니다.

• 요구사항명 : 도출된 요구사항을 요약할 수 있는 명칭을 기입합니다.

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

• 요구사항 설명 : 사용자 요구사항을 구체적이고 상세하게 기술합니다.

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

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

화면 정의서

테이블 명세서

API 명세서

REST(Representational State Transfer) API(Application Programming Interface)

API를 정의할 때 웹 애플리케이션은 보통 RESTful한 API를 정의하고 구현합니다. 그렇다면 RESTful한 것은 무엇일까요? 이것을 알아보기 위해서는 리소스(Resources)와 URI에 대해 간단하게 알고 넘어갈 필요가 있습니다. 리소스는 미디어, DB 데이터 등 모든 자원을 의미합니다. 즉 RESTful한 API로써 통신을 할 때 기대하는 결과값에 해당하는 자원들의 일체를 의미합니다.

URI(Uniform Resource Identifier)란 특정 리소스를 식별하는 ‘통합 자원 식별자'를 의미합니다. 웹 기술에서 사용하는 논리적 또는 물리적 리소스를 식별하는 고유한 문자열 시퀀스입니다. 바로 감이 안잡히죠? 우리가 익히 잘 알고 있는 URL과 비교하여 이해하면 조금 더 명확하게 그 의미를 파악할 수 있습니다. URL은 흔히 웹 주소라고 많이 부르고 있습니다. 좌표의 개념으로 생각하면 쉽습니다. 리소스가 어디 있는지 알려주기 위한 주소값인 셈이죠. 이에 반해 URI는 URL보다 더 큰 범위의 개념을 갖습니다. 즉 URI는 식별하고 URL은 위치를 알려준다고 생각 할 수 있습니다. URI는 따라서 URL보다 더 많은 정보를 담고 있는데 그 구조를 살펴보면 다음과 같습니다.

scheme:[//[user[:password]@host[:port]][/path][?query][#fragment]

• scheme : http 또는 https를 사용합니다.

• user, password : 데이터가 있는 서버에 접근하기 위해 필요한 ID와 PASSWORD

• host, port : 서버의 호스트와 포트 번호

• path : 서버의 상세 경로

• query : path에 접근하기 위한 추가 정보 (파라미터)

• fragment : 메인 리소스 내에 존재하는 서브 리소스에 접근할 때 식별하기 위한 정보

RESTful한 API란 모든 리소스에 대해 고유한 URI를 부여하고 HTTP Method를 적절히 사용하여 리소스를 제어할 수 있는 수단입니다. 이때 요청에 대한 응답은 JSON이나 XML과 같은 사전 정의된 형식을 사용하여 일관된 방법으로 주고 받습니다. REST의 특징을 몇가지로 정리할 수 있는데 그 특징은 다음과 같습니다.

• 서버-클라이언트 구조 (Server-Client Architecture)

• 무상태성 (Stateless)

• 캐시 가능 (Cacheable)

• 일관된 인터페이스 (Uniform Interface)

• 자체적인 표현 구조 (Self-Descriptiveness)

• 계층 구조 (Layered System)

REST API 규칙

관계 나타내기

http://test.com/groups/1/users

groups, users : 이와 같이 복수로 표현되는 것들은 보통 여러개의 리소스를 갖을 수 있으므로 복수형으로 표시하고 ‘Collection’ 이라고 부릅니다.

1 : Collection에 포함된 대상 리소스는 단수형으로 표시하고 ‘Document’라고 부릅니다.

/groups/1/users : Collection과 Document의 관계를 /를 통해 나타낼 수 있습니다. 그룹이라는 Collection 안에 ‘1’ Document를 나타내고, 해당 Document가 갖고 있는 사용자들을 나타냅니다.

HTTP Method

• GET : Query의 ‘SELECT’에 해당한다.

• POST : Query의 ‘INSERT’에 해당한다.

• PUT : Query의 ‘UPDATE’에 해당한다.

• DELETE : Query의 ‘DELETE’에 해당한다.