요구사항정의서

소프트웨어 개발 단계

RFP(Request For Proposal)를 통해 제안요청을 하고 프로젝트 계약이 완료되면 SRS(Software requirements specification)를 통해 프로젝트의 큰 그림을 설계한다

이때 프로젝트 관리자는 인력, 시간, 돈의 관점에서 성공적인 프로젝트를 수행할 수 있게 전략적으로 접근하는 과정은 프로젝트를 도입하고 시행하기 위한 기획의 범주라고 가정했을 때 그 다음은 개발할 소프트웨어를 분석하는 과정이 필요하다

하나의 프로젝트가 올바르고 안정적으로 진행되려면 다음과 같은 과정을 거쳐야 한다

 

분석 단계

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

 

설계 단계

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

 

구현 단계

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

 

시험 단계

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

 

사용자 요구사항 정의서

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

 

 

작성 목적

 

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

 

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

 

작성 방법

 

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

 

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

 

 

항목 설명

• 요구사항 ID : 요구사항별로 유일한 ID를 부여하여 기입
• 요구사항명 : 도출된 요구사항을 요약할 수 있는 명칭을 기입
• 구분 : 도출된 요구사항을 기능 / 성능 / 품질 / 인터페이스 / 데이터 / 운영 / 제약사항 중에서 선택하여 기재
• 요구사항 설명 : 사용자 요구사항을 구체적이고 상세하게 기술
• 중요도 : 해당 요구사항의 전체 시스템 구현 측면에서의 중요도를 기술. (상, 중, 하)
• 비고 : 항목에 포함되지 않으나, 고려해야 할 사항이 있으면 기술

 

 

화면 정의서

 

• 화면 ID : 설계된 화면에 고유값을 부여
• 화면명 : 알아볼 수 있는 화면에 대한 제목을 부여
• 화면 유형 : 입력 / 출력 중 알맞은 유형을 선택합니다. 기타 유형이 존재한다면 알맞게 작성
• 메뉴 경로 : 해당 화면이 서비스의 어디에 위치하는지 설명
• 화면 개요 : 화면의 간단한 설명을 추가
• 화면 미리보기 : 와이어 프레임과 같은 화면 설계 툴을 사용하여 작성된 화면 미리보기 이미지를 삽입하고 해당 화면에서 기능을 수행하는 항목을 번호를 매겨 표시
• 기능 번호 : 화면 미리보기에서 표시된 기능의 번호를 기입
• 요구사항 아이디 : 해당 기능이 사용자 요구사항 명세서에 기술된 어떤 항목인지를 아이디로 표시
• API 활용 여부 : 이 기능이 API를 활용하는 기능인지를 구분
• API 주소 : API 활용 여부가 YES라면 어떤 API를 호출하는지 기입
• 유효성 체크 : 기능이 동작하는 동안 화면 내에서 필수적으로 사용되어야 할 데이터에 대한 유효성 체크를 합니다. 예) 회원 가입을 할 때 아이디와 비밀번호는 필수로 작성되어야 한다. → 아이디, 비밀번호

 

 

테이블 명세서

• 데이터베이스 명 : 데이터베이스 명칭을 기입
• 테이블 명 : 테이블 명칭을 기입
• 요구사항 ID : 테이블이 사용되는 요구사항 정의서의 ID를 맵핑
• 테이블 설명 : 테이블의 목적 및 역할을 간략하게 기술
• 컬럼명 : 테이블 컬럼의 내용과 특성을 인식할 수 있는 명칭을 기술
• 컬럼 ID : 테이블 컬럼 ID를 기술.
• 타입 및 길이 : 컬럼의 타입과 최대 허용 길이를 기술
• NOT NULL : 필수항목 여부를 나타낸다
• PK (Primary Key) : 주키 여부를 나타낸다.
• FK (Foreign Key) : 외래키를 의미
• INX (Index) : 인덱스를 의미
• 기본값 : 속성의 기본값이 있는 경우에 그 값을 기술
• 제약조건 : 속성의 특이한 제약조건이 있는 경우 기술

API 명세서

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

API를 정의할 때 웹 애플리케이션은 보통 RESTful한 API를 정의하고 구현한다.

RESTful

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’에 해당