Software requirements specification

날이 많이 추워졌다. 운동을 게을리하니 잠도 늘었고, 동면의 계절.. 항시 조심해야한다.


1. SRS

소프트웨어의 동작 목표, 작동 예상을 설명하는 문서이다. 소프트웨어의 이해관계자의 요구를 충족하는데 필요한 기능을 기술한다.

1.2. 비지니스 로직에서의 프로젝트

  1. 과업발생: 개발팀이 착수할 프로젝트 발생
  2. 사업자 선정 및 계약: Request For Proposal, 제안요청서로 작성하여 문서화한다.
    • 제안요청서: 개요와 구축컨셉, 제안요청사항 정의, 제안서 작성가이드 정의의 내용을 포함하는 과업해결을 제안하는 행위의 모든것.
  3. 기획/분석: PM에따라 프로젝트 운명이 달라진다. 고객과 소통을 위해 SRS를 작성한다.
  4. 구현
  5. 시험: 서비스를 위한 사용자나 운영자 측면의 매뉴얼을 작성한다.
  6. 오픈
  7. 유지보수: 사업비에 포함된 a/s기간

1.3. 프로젝트 구분

  • 솔루션: 기업에서 개발한 소프트웨어
  • System Integration: 시스템구축, 몇몇 파견용역회사들 덕에 의미가 퇴색되어 SI라고하면 부정적인 시각이 있다.
  • System Management: 운영과 유지보수로 병원이나 기업전산이 해당하나, 결혼해서 애가있는 개발자들이 선호하는 적당한 연봉의 칼퇴가보장되는 인식이 있는 업무

대표에따라 다르겠지만, 대부분 수익을 내는 회사의 경우에는 자체 솔루션이 대박이지 않는 소규모기업이라면 대부분 외주로 다른 회사의 si, sm업무를 대행하는경우가 많다. 자체 솔루션없이 si와 sm, 혹은 si만, sm만 하는 기업도 있다.

1.4. SRS문서 구성

  1. 소개
    1. Purpose: 목적, 요구사항이 명시되어있는 소프트웨어를 성ㄹ명한다. 전체 시스템 중 일부라면 그부분이나 하위시스템을 설명한다.
    2. Doucment Convention: 뮨서 규칙, text style, highlight, annotation등 과 같은 모든 표준 또는 표기규칙 기술
    3. Intend Audience and Reading Suggestion: 독자대상 읽는법, 문서의 독자계층, SRS 나머지부분, SRS의 구성과 방법 등 읽는 법을 기술한다.
    4. Project Scope: 프로젝트 범위, 소프트웨어 목적 간단설명
    5. Reference: 참조, 참조하는 문서와 리소스, 하이퍼링크 포함
  2. Overall Description
    1. Product Perspective: 제품조망, 구성과 유래 설명, 확장되는 제품군의 다음 구성인지 왓넝된 시스템의 다음 버전인지, 기존 버전을 완전 엎는 새로운 제품인지 설명
    2. Project Feature: 제품 기능, 제품이 가지는 주요기능 또는 제품이 수행하는 중요한 기능 나열, 요구사항의 주요그룹과 그 그룹이 연결되 있는 방법을 설명하는 최상위 데이터 플로우 다이어그램, 유스케이스 다이어그램, 클래스 다이어그램 등으로 기술
    3. User Classes and Characteristic: 사용자 계층과 특징 설명
    4. Operation Enviroment: 운영환경, 하드웨어 플랫폼, 운영체제와 버전, 사용자, 서버와 데이터베이스의 지리적위치 등 소프트웨ㅐ어가 동작되는 환경을 설명. 시스템이 연동되는 다른 소프트웨어 컴포넌트 또는 앱을 나열
    5. Design and Implementation constraint: 설계 및 구현 제약사항,
      • 반드시 사용하거나 피해야 하는 기술, 툴, 프로그래밍 언어와 인터페이스.
      • 사용될 웹 브라우저의 유형과 버전과 같이 제품의 운영환경으로 인한 제약.
      • 필요한 개발 규칙 또는 표준(예를 들면 고객의 조직이 소프트웨어를 유지보수 할 예정이라면, 그 조직은 - 하청업체가 따라야 하는 설계 표기법과 코딩 표준을 명시 할 수 있다.)
      • 이전 제품과의 호환성.
      • 비즈니스 규칙에 따른 제약.
      • 메모리 또는 프로세스의 제약, 크기, 무게, 비용과 같은 하드웨어의 제약.
      • 기존 제품을 개선하는 경우에 따라야 하는 기존 사용자 인터페이스 규칙.
      • XML과 같은 표준 데이터 교환 형식.
    6. User Documentation: 사용자 문서, 나열, 매뉴얼, 도움말, 교재 등
    7. Assumptions and Dependencies: 가정과 종속관계, 프로젝트가 통제할수없는 외부요소에 어느정도 종속되는지 설명
  3. System Feature: 시스템 특징,
    1. System Features: 시스템 특징,
      1. Derscription and Priority: 설명과 우선순위, 기능에 대한 간단한 설명, 우선순위 기술, 우선순위는 동적, 요구사항관리툴 사용 시 유구사항 특성 우선순위 기술
      2. Stimulus/Response Sequence: 자극/응답순서, 입력 자극(신호)의 순서와 기능에 대한 동작 정의하는 시스템 반응 기술
      3. Fuctional Requirement: 기능 요구사항, 상세한 기능 요구사항을 항목으로 기술, 기능의 서비스를 수행하기 위한, 유스케이스를 수행하기 위한 소프트웨어의 기능들
  4. External Interface Requirement: 외부 인터페이스 요구사항
    1. User Interface: 사용자 인터페이스, 설계 상세 내용은 본문서말고 별도의 사용자 인터페이스 명세에 기술
      • 시스템이 요구하는 각각의 사용자 인터페이스와 논리적인 특징을 설명한다. 따라야 할 GUI 표준 또는 제품 스타일가이드에 대한 참조.
      • 폰트, 아이콘, 버튼 레이블, 이미지, 색상 체계, 필드탭 순서, 공통으로 사용되는 컨트롤 등에 대한 표준.
      • 화면 레이아웃 또는 해상도 제약 조건.
      • 도움말 버튼과 같이 모든 화면에 나타나는 표준 버튼, 기능 또는 탐색 링크.
      • 단축키.
      • 메시지 표시 규칙.
      • 소프트웨어 번역을 원활하게 하는 레이아웃 표준.
      • 시각장애자를 위한 기능.
    2. Hardware Interface: 하드웨어 인터페이스, 시스템 소프트웨어와 하드웨어 컴포넌트간 모든 접점의 특징 설명, 지원되는 장비 유형, 데이터 컨트롤 연동, 사용될 통신 프로토콜 등
    3. Software Interface: 소트프웨어 인터페이스, 다른 소프트웨어 컴포넌트(데이터베이스, 운영체제, 툴, 라이브러리, 통합 상업용 컴포넌트)간의 연결을 설명, 소프트웨어 컴포넌트 간 교환되는 메서지, 데이터 컨트롤 항목 기술
    4. Communication Interface: 통신인터페이스, 이메일, 웹브라우저, 네트워크통신 프로토콜, 전자문서와 같이 제품이 사용할 모든 통신 기능에 대한 요구사항 설명, 관련된 모든 메세지 형태를 정의하고 통신보안 또는 암호화문제, 데이터 전송률과 동기화 메커니즘을 명시
  5. Other Nonfuncional Requirements: 기능 외 다른 요구사항
    1. Performance Requirement: 성능 요구사항, 다양한 시스템 운영에 대한 특정 성능 요구사항을 설명. 개발자들이 적합한 설계를 선택할 수 있게 만든 논리를 설명.
    2. Safety Requirement: 안전 요구사항, 반드시 방지해야 하는 잠재적으로 위험한 행동 뿐만 아니라 반드시 취해야 할 모든 안전장치 또는 행동을 정의. 제품이 따라야 하는 보안인증, 정책 또는 규제를 정의.
    3. Security Requirement: 보안 요구사항, 제품에 대한 접속과 제품사용에 영향을 미치는 보안, 무결성 또는 사생활 문제, 제품이 사용하거나 만드는 데이터 보호를 모두 명시.
    4. Software Quality Attribute: 소프트웨어 품질 특성, 객 또는 개발자에게 중요한 모든 별도의 품질 특성을 설명. 이런 특성들은 명확하고 계량적이며 확인이 가능해야함.
  6. Other Requirement: 다른 요구사항, SRS의 다른 부분에서는 다루지 않는 모든 요구사항을 정의

2. 소프트웨어 개발단계

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

2.1. NIA(한국정보화진흥원) 사용자 요구사항 정의서

  1. 작성목적: 시스템의 요구사항을 도출하여 발주자와 내용을 합의하고, 하나의 업무 단위로서 가치를 가지고 수행될 수 있는 업무를 도출하여 업무 내용을 기술한다.
  2. 방법: 산출물 양식의 표를 이용하여 해당 항목에 기술하며 이해하기 쉽고 구체적인 언어표현을 사용한다. 기능적 요구사항과 비기능 요구사항을 그룹핑하여 별도의 표로 작성한다.
  3. 항목
요구사항 ID 요구사항 명 구분 요구사항 설명 중요도 비고
SS_AA00001 로그인 기능 아이디와 비밀번호를 입력해 로그인을 한다. 세션유지및 관리
SS_AB00001 관리자 권한기능 부기능 관리자가 계정에 권한을 부여한다. 읽기/쓰기 권한 관리
  • 요구사항 ID : 요구사항별로 유일한 ID를 부여하여 기입한다.
  • 요구사항명 : 도출된 요구사항을 요약할 수 있는 명칭을 기입한다.
  • 구분 : 도출된 요구사항을 기능/성능/품질/인터페이스/데이터/운영/제약사항 중에서 선택하여 기재한다.
  • 요구사항 설명 : 사용자 요구사항을 구체적이고 상세하게 기술한다.
  • 중요도 : 해당 요구사항의 전체 시스템 구현 측면에서의 중요도를 기술한다. (상, 중, 하)
  • 비고 : 항목에 포함되지 않으나, 고려해야 할 사항이 있으면 기술한다.

2.2. NIA(한국정보화진흥원) 화면 정의서

  1. 작성목적: 시스템이 제공하는 사용자 인터페이스의 전체 구조와 메뉴 형식, 화면 목록과 화면의 상세 설계 내역을 기술한다.
  2. 작성방법: 전체 시스템에 대한 사용자 인터페이스의 구조를 사용자에게 제공하는 메뉴 형식으로 기술하고, 화면 및 출력으로 구분하여 목록을 작성하며, 화면의 상세 설계 내용을 화면별로 기술한다.
  3. 항목
화면ID SS_AA00001 화면 명 로그인
화면유형 입력 메뉴 경로 홈->로그인
화면개요 기사용자가 서비스를 이용하가위해 로그인을 할수있는 화면

화면 설계 미리보기

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

2.3. NIA(한국정보화진흥원) 테이블 명세서

  1. 작성목적: 최종적으로 설계된 테이블과 인덱스를 데이터베이스 공간에 맵핑시키고 저장공간 등의 물리 모델을 기술한다.
  2. 작성방법: 부서에서 운영하는 데이터베이스 목록을 작성하고, 데이터베이스의 물리적 상세내용을 기술한다.
  3. 항목
데이터베이스 명 service 테이블 명 Member
요구사항 ID RQ_001_01, RQ_001_02 테이블 설명 로그인 관리
컬럼명 컬럼ID 타입 및 길이 Not null PK FK IDX 기본값 제약조건
ID id CHAR(10) Y Y     ID01  
비밀번호 pwd(VARCHER(16)) Y            
  • 데이터베이스 명 : 데이터베이스 명칭을 기입한다.
  • 테이블 명 : 테이블 명칭을 기입한다.
  • 요구사항 ID : 테이블이 사용되는 요구사항 정의서의 ID를 맵핑한다.
  • 테이블 설명 : 테이블의 목적 및 역할을 간략하게 기술한다.
  • 컬럼명 : 테이블 컬럼의 내용과 특성을 인식할 수 있는 명칭을 기술한다.
  • 컬럼 ID : 테이블 컬럼 ID를 기술한다.
  • 타입 및 길이 : 컬럼의 타입과 최대 허용 길이를 기술한다.
  • NOT NULL : 필수항목 여부를 나타냅니다.
  • PK (Primary Key) : 주키 여부를 나타냅니다.
  • FK (Foreign Key) : 외래키를 의미한다.
  • INX (Index) : 인덱스를 의미한다.
  • 기본값 : 속성의 기본값이 있는 경우에 그 값을 기술한다.
  • 제약조건 : 속성의 특이한 제약조건이 있는 경우 기술한다.

2.4. API 명세서

  • REST(Representational State Transfer) API(Application Programming Interface)
    • 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과 같은 사전 정의된 형식을 사용하여 일관된 방법으로 주고 받음.
  • 특징
    • Server-Client Architecture: 서버-클라이언트 구조
    • Stateless: 무상태성
    • Cacheable: 캐시 가능
    • Uniform Interface: 일관된 인터페이스
    • Self-Descriptiveness: 자체적인 표현 구조
    • Layered System: 계층 구조
  • 규칙
    • /로 끝나지 않는다. server.kimtank.com/login
    • _말고 -사용 server.kimtank.com/sign-up
    • 소문자사용
    • 동사사용 지양 server.kimtank.com/delete/member
    • 확장자 가림 filename Accept: image/png
  • 관계
    • http://server.kimtank.com/tasks/65513/members
      • task, member는 여러개의 리소스를 가지므로 복수형으로 표시, Collection
      • Collection에 포함된 65513 대상 리소스는 단수형, Document
      • /tasks/65513/members Collection, Document관계 /로 표현
  • HTTP method
  • GET: Query -> SELECT
  • POST: Query -> INSERT
  • PUT: Query -> UPDATE
  • DELETE: Query -> DELETE

참조

한국지능정보사회진흥원: main
codestates: main