[문서] SRS(Software requirements specification) 문서 작성법

SW 개발자가 되면? 겁나 소프트웨어만 할 줄 알았다. 그런데 이런 문서를 이제서야 만들게 되었다. 진작에 알았다면? 일이 더 많았을 것이라는 생각이 들기는 하다. 그런데 체계적인 개발을 위해서라면? 좋은 툴과 함께 스토리를 만들어 가는 과정이 될것이다. 

 

SRS 소프트웨어 요구 사항에 대한 스펙이라고 이야기 할 수 있겠다. 

 

개인적으로 한달정도 어떻게 써야 하나? 라고 이곳 저곳을 돌아 다녀 봤다. 예제들이라는것이 차례만 나타나 있다. 결국은 예제를 찾는것은 어렵다. 이유는 개발에 대한 세부적인 이야기가 나와야 하기 때문이다. 개발한 제품의 개발 히스토리도 남게 되니 더더욱 보여줄 수가 없는 것이다. 두리뭉실하게만 보여 주는게 최선이다.  

 

SRS는 목적이 중요하다. 꼭 SRS문서만 목적이 중요한것은 아니다. 개발에는 목적이 있다. 제품 사양서가 있다면? 그 사양서가 상위 우두머리고, SRS, HRS 같은 문서는 하위 우두머리들이다. 즉 행동대장들이 되겠다.

우리가 책을 쓴다면? 대상이 필요 하다. 그리고 그 대생이 쉽게 이해 하도록 하는것도 목적이다. SRS 문서는 영문 그대로 소프트웨어 요구 스펙이다.

1장 1절 무엇을 만들것인가?

문서를 보고 개발을 한다면? 이라는 문서의 목적을 생각해 보고 접근을 해야 한다. 

 

예를 들어서 TV를 만든다고 해 보자. 

HW(하드웨어) 관점에서 

HW는 화면이 있는 TV를 만드는것이 최종 목표가 되겠다. 크기와 두께 ..이렇게 하나 둘 내려가면 마지막에는 부품을 하나 하나 나뉘어 질 것이다. 여기서 기구도 포함이 되어야 한다. 

 

SW(소프트웨어) 관점에서 생각한다면? 

HW와 동일하다. 최종적인 목적은 TV가 될 것이다. HW의 블록도를 보면서 하나 둘 내리면서 쓰면 되겠다. 

 

뭔 뜻으냐? 티어 다운(tear down)이라는것이 있다. 제품은 하나 둘 뜯어서 소 단위로 나뉘는 것을 티어 다운이라고 한다.  TV의 완성을 위해서 개발자는 프로그램을 세분화 하고, 문서를 보면서 빠진 부분이 없는지 확인하게 된다. 한방에 문서를 완성 할 수으면 최고의 PM, 팀장이 되겠다. 그래서 전방, 후방 추적성이라는것을 만들어서 관리를 한다. 

 

문서는 조감도를 시작해서, 점점 하위 단계로 넘어가는 구조로 작성하시면 됩니다. 넓은 단계 -> 중간 단계 -> 좁은 단계 라고 보시면 됩니다. 다시 다시... 핸프폰을 분해 한다면? 핸드폰 --> 각각의 부품으로 나뉘기 --> Main 부품을 세부 부품으로 나뉘기 입니다. 소프트웨어도 동일하게 접근하면 됩니다. 

핸드폰은 분해 된 사진을 보니, 구성이 눈에 들어 오죠? 아닌가? 이렇게 소프트웨어도 분해를 한다 생각하고 접근을 합니다. 그것을 말로 해야 합니다. ( 그래서 힘든거 같내요. ) 

 

요구사항을 그때 그때 만들다 보면, 프로젝트는 산으로 간다. TV 하나로 시작 했는데, 고객이 TV에 갑자기 게임기를 넣어 달라고 한다. 넣어 줄 수 있다. 하지만 게임기능을 넣기 위해서 HW도 변경이 필요 할 수 있다. 그래픽을 더 잘 돌아가기 위해서 말이다. 픽셀의 값을 올리고 싶을 수도 있다. 결국 유튜브 방송만 보고 싶었던 TV의 기능에서 엄청난 업그레이드 기능이 들어가게 될 수도 있는 것이다. 

 

SRS 문서는 사양서 같기는 하지만, 사양서가 아니다. 하지만 목표를 명확하게 하는데 필요하다. 만약 일정이 들어 간다면? 개발 계획서가 될거 같다. 소프트웨어가 프로그램을 작성하면서 기능을 빼 먹지 않도록 하기 위한 문서를 만들수 있다.

 

하지만, 문서만 만들고 문서를 버린다면? 문서를 만들면서 느낀 감정을 유지 하시길 바란다. 문서를 위한 문서를 만들기 싫다면? 회사 자체적으로 블록도 SRS를 만들어도 되겠다. 형식이 없다는 점을 말하고 싶다. 

 

참고) https://velog.io/@angel_eugnen/SRSSoftware-requirements-specification 

https://flylib.com/books/en/2.910.1.75/1/ 

1. 소개

• 1.1 목적 (Purpose)
  : 이 문서에 요구사항이 명시되어 있는 제품 또는 애플리케이션을 설명한다. 이 SRS가 전체 시스템 중 일부에만 관련된 것이라면 그 부분 또는 하위시스템을 설명한다.
• 1.2 문서 규칙 (Document Convention)
  : 텍스트 스타일, 하이라이트 또는 주석과 같은 모든 표준 또는 표기규칙을 설명한다.
• 1.3 독자대상과 읽는 방법 (Intend Audience and Reading Suggestion)
  : SRS가 대상으로 하고있는 다양한 독자계층을 나열한다. SRS의 나머지 부분과, SRS가 조직되어 있는 방법을 설명하고, 각각의 독자 계층에 대해 가장 적합한 읽기 순서를 설명한다.
• 1.4 프로젝트 범위 (Project Scope)
  : 설명되고 있는 소프트웨어와 그 목적에 대해 간단하게 설명한다.
  --> 무한대로 범위를 넓힐수는 없다. 개발하고자 하는 범위를 좁히는것도 팀장, PM의 역할이다. 범위를 축소하고 인력을 고루 분포하기 위해서는 범위의 제한은 필요하다. 바보같은 팀장, PM은 한 없이 고객의 요구 사항을 다 들어주면서 범위를 넓히게 된다. 
• 1.5 참조 (Reference)
  : 이 SRS가 참조하고 있는 모든 문서 또는 다른 리소스를 나열하며, 가능한 경우에는 하이퍼링크도 포함시킨다.
  --> Datasheet가 주요 참고 사항이 되겠다. 또한 아이디어 노트가 있다면 아이디어 노트가 참고 문서가 되겠다. 전장(자동차) 일을 하게 되면, 문서가 완료가 되는 순간 제품은 완성이 된다는 말을 한다. 자동차의 히스토리를 문서로 남기면서 누가 와서도 문서를 보고 만들 수 있다면? 최고의 문서가 되겠다. ( 하지만 문서만으로 숨어 있는 노하우를 가져 갈 수는 없다. ) 

---

1. 전체 설명 (Overall Description)

• 2.1 제품조망 (Product Perspective)
  : 제품의 구성과 유래를 설명한다. 
  --> 조망이라는 한자어다. 위에서 내려다 본다. overview 라고 말 할 수 있다. 전체적으로 보자라는 것이다. 건축이라고 하면 조감도 라고도 할 수 있다. 넓은 땅에 포크레인 하나만 있지만, 그 앞에 조감도 하나 있으면, 우리는 상상한다. 20층 건물이 올라 올 것이라는 상상을 한다. 
• 2.2 제품 기능 (Project Feature)
  : 제품이 가지고있는 주요기능 또는 제품이 수행하는 중요한 기능을 나열한다. 
  --> 조감도만 보고 상상을 할 수 없는 사람들에게, 층별 설명이 필요하다. 1층은 약국, 2층은 PC방..... 3층은 안과.....20층은 헬스장... 
• 2.3 사용자 계층과 특징 (User Classes and Characteristic)
  : 이 제품을 사용할 것으로 예상되는 사용자계층을 파악하고 그들의 특징을 설명한다.
  --> 사용자가 아닐수도 있을 것이다. 어느 기기의 부품으로 들어 갈 수도 있다. 특징을 설명하면 된다. 
• 2.4 운영 환경 (Operation Environment)
  : 하드웨어 플랫폼, 운영체계와 버전, 사용자, 서버와 데이터베이스의 지리적 위치 등과 같은 소프트웨어가 동작되는 환경을 설명한다. 
  --> 이런 부분이 개발자들에게 힘들게 한다. 운영환경 이런거 모르겠다. 그러면 빼면 된다. 간단한 소프트웨어 환경인데, 운영 환경이 뭔말이냐? 라는 생각을 들 것이다. 이유는 SRS 문서들은 대형 프로젝트에 많이 이용되고 있기 때문인거 같다. 자신에게 맞게 변형하면 되겠다. 문서의 형식은 있지만, 꼭 이렇게 하라 라고 하는것은 아니다. 
• 2.5 설계 및 구현 제약사항 (Design and Implementation constraint)
  : 개발자가 선택할 수 있는 사항을 제약하는 모든 요소와 각 제약조건의 이유를 설명한다. 제약 조건은 다음과 같다.- 반드시 사용하거나 피해야 하는 기술, 툴, 프로그래밍 언어와 인터페이스. - 사용될 웹 브라우저의 유형과 버전과 같이 제품의 운영환경으로 인한 제약. - 필요한 개발 규칙 또는 표준(예를 들면 고객의 조직이 소프트웨어를 유지보수 할 예정이라면, 그 조직은 하청업체가 따라야 하는 설계 표기법과 코딩 표준을 명시 할 수 있다.) - 이전 제품과의 호환성. - 비즈니스 규칙에 따른 제약. - 메모리 또는 프로세스의 제약, 크기, 무게, 비용과 같은 하드웨어의 제약. - 기존 제품을 개선하는 경우에 따라야 하는 기존 사용자 인터페이스 규칙. - XML과 같은 표준 데이터 교환 형식.
• 2.6 사용자 문서 (User Documentation)
  : 소프트웨어와 함께 제공할 사용자 문서를 나열한다. 사용자 문서로는 사용자 메뉴얼, 온라인 도움말, 교재 등이 있으며 따라야 하는 문서 전달 형식, 표준 또는 툴이 있다면 그것들을 설명한다.
• 2.7 가정과 종속관계 (Assumptions and Dependencies)
  : 가정이 잘못되거나 이것을 공유하지 않는다면 문제가 발생될 수 있기 때문에 어떤 가정은 프로젝트 위험으로 간주된다. 프로젝트가 통제할 수 없는 외부 요소에 어느정도 종속되는지 또한 설명해야 한다.

---

1. 시스템 특징 (System Feature)

• 3.1 시스템 특징

가. 설명과 우선순위 (Description and Priority)

     : 기능에 대해 간단하게 설명하고 그것이 높은 우선순위인지 낮은 우선순위인지를 나타낸다. 우선순위는 프로젝트 중
     에 변할 수 있는 동적인 것으로, 요구사항관리 툴을 사용한다면 요구사항 특성의 우선순위를 정의한다.

나. 자극/응답 순서 (Stimulus / Response Sequence)

     : 입력 자극(사용자 행동, 외부 장비의 신호 또는 다른 자극)의 순서와 이 기능에 대한 동작을 정의하는 시스템 반응을       나열한다.

다. 기능 요구사항 (Functional Requirement)

     : 이 기능과 관련된 상세한 기능 요구사항을 항목으로 나열한다. 이것들은 사용자가 기능의 서비스를 수행하기 위해          또는 유스케이스를 수행하기 위해 사용하는 소프트웨어의 기능들이다.

---

1. 외부 인터페이스 요구사항 (External Interface Requirement)

• 4.1 사용자 인터페이스 (User Interface)단축키.
  - 메시지 표시 규칙.
  - 소프트웨어 번역을 원활하게 하는 레이아웃 표준.
  - 시각장애자를 위한 기능.
  - 사용자 인터페이스 설계 상세 내용은 SRS가 아닌 별도의 사용자 인터페이스 명세에 문서로 정리한다.
• - 시스템이 요구하는 각각의 사용자 인터페이스와 논리적인 특징을 설명한다. 따라야 할 GUI 표준 또는 제품 스타일 가이드에 대한 참조. - 폰트, 아이콘, 버튼 레이블, 이미지, 색상 체계, 필드탭 순서, 공통으로 사용되는 컨트롤 등에 대한 표준. - 화면 레이아웃 또는 해상도 제약 조건. - 도움말 버튼과 같이 모든 화면에 나타나는 표준 버튼, 기능 또는 탐색 링크.
• 4.2 하드웨어 인터페이스 (Hardware Interface)
  : 시스템의 소프트웨어와 하드웨어 컴포넌트간의 모든 인터페이스의 특징을 설명한다. 설명에는 지원되는 장비 유형, 소프트웨어와 하드웨어간의 데이터와 컨트롤 연동, 사용될 통신 프로토콜 등이 포함된다.
• 4.3 소프트웨어 인터페이스 (Software Interface)
  : 이 제품과 다른 소프트웨어 컴포넌트(데이터베이스, 운영체제, 툴, 라이브러리, 통합 상업용 컴포넌트)간의 연결을 설명한다. 소프트웨어 컴포넌트 간에 교환되는 메시지, 데이터와 컨트롤 항목을 설명한다.
• 4.4 통신 인터페이스 (Communication Interface)
  : 이메일, 웹 브라우저, 네트워크 통신 프로토콜, 전자 문서와 같이 제품이 사용할 모든 통신 기능에 대한 요구사항을 설명한다. 관련된 모든 메시지 형태를 정의하고 통신 보안 또는 암호화 문제, 데이터전송률과 동기화 메커니즘을 명시한다.

---

1. 기능 이외의 다른 요구사항 (Other Nonfunctional Requirements)

• 5.1 성능 요구사항 (Performance Requirement)
  : 다양한 시스템 운영에 대한 특정 성능 요구사항을 설명한다. 개발자들이 적합한 설계를 선택할 수 있게 만든 논리를 설명한다.
• 5.2 안전 요구사항 (Safety Requirement)
  : 반드시 방지해야 하는 잠재적으로 위험한 행동 뿐만 아니라 반드시 취해야 할 모든 안전장치 또는 행동을 정의한다. 제품이 따라야 하는 보안인증, 정책 또는 규제를 정의한다.
• 5.3 보안 요구사항 (Security Requirement)
  : 제품에 대한 접속과 제품사용에 영향을 미치는 보안, 무결성 또는 사생활 문제, 제품이 사용하거나 만드는 데이터 보호를 모두 명시한다.
• 5.4 소프트웨어 품질 특성 (Software Quality Attribute)
  : 고객 또는 개발자에게 중요한 모든 별도의 품질 특성을 설명한다. 이런 특성들은 명확하고 계량적이며 확인이 가능해야 한다.

---

1. 다른 요구사항 (Other Requirement)