[Stack-Overflow 클론] 요구사항 명세서

들어가면서...

요구사항 명세서라면 대학생 때 질리도록 작성했지만 단 한 번도 제대로 작성한 적은 없는 것 같습니다. 간만에 Pre-Project에서 한 번 더 제대로 작성할 수 있는 기회를 얻게 되었는데, 얼떨결에 팀장까지 되어서 겪은 여러가지 운영 실수와 개선 사항들을 포함하여 전부 여기에 정리합니다.

 

 

 

일반적인 프로젝트 개발 단계

 

기획 → 분석 → 설계 → 구현 → 시험

 

익숙한 순서입니다. 하지만 애자일 방법론을 따르는 스프린트 개발은 저렇게 고정된 절차로 이루어지지 않습니다. 아래 그림처럼 스프린트 단위마다 빙글빙글 돌게 될 것입니다.

 

 

프로젝트 진행 단계

 

 

기획 단계

우선 RFP(Request For Proposal)을 통해 제안요청을 한 뒤, 프로젝트 계약이 완료되면 SRS(Software requirements specification)를 작성합니다. 일종의 프로젝트의 큰 그림을 설계하는 것입니다. 사실 이때도 분석은 이루어지는데, 조금 더 자세한 분석을 '분석 단계'에서 진행한고 생각하면 됩니다.

 

분석 단계

분석이라 함은 마치 사전 준비 단계에서 완료되어야 할 것 같지만, 요구사항 정의서 내용은 스프린트 실행 단계에서 얼마든지 변경될 수 있고, 추가적인 분석 또한 진행될 수 있으므로 분석은 스프린트 실행 단계에 포함합니다.

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

 

설계 단계

실제로 구현하기 위해 올바른 설계를 합니다. 이전에 작성한 SRS를 기반으로 범주에 벗어나지 않는 설계를 해야합니다. 클래스 설계서, 사용자 인터페이스 설계서, 컴포넌트 설계서, 인터페이스 설계서, 총괄시험 계획서, 시스템 시험 시나리오, 엔티티 관계 모형 기술서, 데이터베이스 설계서, 통합시험 시나리오, 유닛 테스트 케이스, 데이터 전환 및 초기 데이터 설계서 등... 과 같은 문서를 작성합니다.

 

구현 단계

실제 개발 작업이 이루어지며 소프트웨어의 모습이 갖춰집니다. 프로그램 코드, 유닛 테스트 결과서, DB 생성 스크립트 등을 문서화 하여 개발의 진행 정도를 알 수 있게 가시화 합니다.

 

시험 단계

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

 

 

 

 

 

사전 준비 단계

[기획] SRS(Software Requirements Specification) 문서 작성하기

SRS란?

소프트웨어가 무엇을 할 것이며 어떻게 작동할 것으로 예상되는지를 설명하는 문서를 말합니다. 제품이 모든 이해 관계자(비즈니스, 사용자)의 요구를 충족시키는데 필요한 기능을 설명합니다.

 

SRS 내용 예시

 

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

 

 

 

 

스프린트 실행 단계

[분석] 사용자 요구사항 정의서 작성하기

• 산출물을 표에 정리한 뒤, 해당 항목에 대한 설명을 이해하기 쉽고 구체적으로 기술합니다.
• 기능적 요구사항과 비기능적 요구사항을 그룹핑하여 별도의 표로 작성합니다.
  • 기능적 요구사항: '현금 출금 기능' 과 같은 동작을 수행하는 모든 행위
  • 비기능적 요구사항: '시스템 관리자가 조직 변경에 따른 권한 변경이 있을 경우, 이를 1분 이내에 적용할 수 있어야 한다.' 와 같은 성능적 측면 등

 

이번 Pre-Project의 주제는 Stack Overflow를 클론코딩 하는 것이라, 비기능적 요구사항은 제외하고 간단히 기능적 요구사항만 기술하였습니다. 양식은 SW인재양성 교육 때 사용한 양식을 노션에 똑같이 만들어서 사용했습니다.

 

 

1. 기능 목록

어떤 기능을 구현할지 정리하는 것입니다. Pre-Project 기간은 단 2주밖에 되지 않고, 그마저도 설계 기간, 주말을 제외하면 구현에 집중할 수 있는 기간은 오직 7일 정도였습니다. 너무 짧죠.

 

코치님께서 말씀하시길, 프로젝트를 성공리에 마치는 방법은 '과연 자신이 어디까지 구현할 수 있을까'를 현실적으로 측정하는 것이라 하였습니다.

 

일단 스택 오버플로우에 존재하는 핵심 기능만 뽑으면 이렇습니다.

 

기능 요구사항 목록

 

물론 태그, 투표, 이력관리 등은 핵심적이라고 말하긴 힘들지만 만약 프로젝트 기간 동안 시간이 조금 남을 경우 꼭 만들어보고 싶은 기능이기에 적어보았습니다. 이런 경우 우선순위를 낮게 두면 됩니다.

 

 

 

2. 운영체계

구체적인 요구사항 정리

 

앞에서 정리한 요구사항을 카테고리별로 구체적으로 적는 단계입니다.

 

모든 기능을 최대한 구체적으로 적은 뒤, 팀원들과 상의하여 불가능한 부분은 과감하게 제거했습니다.

 

+ 다음 Main Project 때 더 자세하게 작성할 시간이 있다면 도출된 요구사항을 기능/부기능/성능/품질/인터페이스/데이터/운영/제약사항 으로 구분 해보고싶네요.

 

이 과정에서 처음에는 FE+BE 팀원들이 전부 모여 '기능목록' 표를 기반으로 각 요구사항에 대한 상세설명을 그냥 떠오르는 대로 막 적었습니다. 팀장인 제가 타이핑 하고, 팀원들이 함께 대화하며 이것저것 추가하는 식이었죠. 기획 시간이 부족해서 빠르게 해결하려다 보니 어영부영 그랬는데, 그 결과 요구사항에 대한 상세 설명이 너무 부족했습니다.

 

클론 코딩 할 사이트를 함께 조각조각 들여다보며 사용자 흐름을 하나하나 따라가 적었어야 하는데...

 

결국 저의 잘못으로 인해 그날 밤 다시 하나하나 구체적인 기능까지 정리했습니다. 그 다음 팀원들과 다시금 들여다보며 추가/삭제를 진행했습니. 그 결과가 첫번째 보이는 회색 표이고, 이번 기회를 통해 "시간이 오래 걸리더라도 한 번 회의 할 때 제대로 해결하자" 라는 다짐을 하게 되었습니다. 그게 오래 걸려 봤자 두 번 일하게 되는 것보단 짧겠더군요.

 

 

 

 

[분석] 화면 정의서 작성하기

화면 정의서는 아래 규칙을 따라 작성합니다.

• 시스템이 제공하는 사용자 인터페이스의 전체 구조와 메뉴 형식, 화면 목록과 화면의 상세 설계 내역을 기술한다.
• 전체 시스템에 대한 사용자 인터페이스의 구조를 사용자에게 제공하는 메뉴 형식으로 기술한다.
• 화면 및 출력으로 구분하여 목록을 작성한다.
• 화면의 상세 설계 내용을 화면별로 기술한다.

 

Pre-Project 화면 정의서 예시

 

더 자세하게 적고싶다면 화면 별 필수사항 정도를 추가 기입해도 좋습니다.

 

 

 

 

[분석] 테이블 명세서 작성하기

테이블 명세서는 아래 규칙에 따라 작성합니다.

• 최종적으로 설계된 테이블과 인덱스를 데이터베이스 공간에 맵핑시키고 저장공간 등의 물리 모델을 기술한다.
• 부서에서 운영하는 DB 목록을 작성하고, DB의 물리적 상세내용을 기술한다.

 

이 부분은 백엔드 팀원들이 맡아주었습니다. FE+BE 모두 모여 화면 별 필요한 데이터를 자료사전에 대강 정리해본 뒤, 구체적인 부분은 백엔드 팀원 분들이 설계 해주었습니다.

 

Pre-Proj 테이블 명세서 폼 예시

 

 

 

[분석] API 명세서 작성하기

• RESTful한 API를 정의하고 구현합니다.
  • RESTful 한 API? 모든 리소스에 대해 고유한 URI를 부여하고 HTTP Method를 적절히 사용하여 리소스를 제어할 수 있는 수단.

 

1) REST API 규칙

REST API 규칙 예시

 

 

2) 관계 나타내기

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

• groups, users : 이와 같이 복수로 표현되는 것들은 보통 여러 개의 리소스를 가질 수 있으므로 복수형으로 표시하고 ‘Collection’이라고 부릅니다.
• 1 : Collection에 포함된 대상 리소스는 단수형으로 표시하고 ‘Document’라고 부릅니다.
• /groups/1/users : Collection과 Document의 관계를 /를 통해 나타낼 수 있습니다. 그룹이라는 Collection 안에 ‘1’ Document를 나타내고, 해당 Document가 갖고 있는 사용자들을 나타냅니다.

 

3) HTTP Method

HTTP Method 종류 예시

 

 

그리하여 작성된 API 명세서는 아래 표와 같습니다.

 

 

API 명세서

 

이 과정에서도 약간 보완할 점이 있었습니다...

 

BE 팀원들이 필수적인 요청들을 간추려 명세서를 만들고, 그 다음 FE에서 추가/삭제할 부분을 논의했습니다. 하지만 지금에 와 다시 생각해보니 왜 그걸 BE분들이 알아서 작성하도록 부탁했는지 모르겠네요. 프론트에서 보낼 요청들인데 말이죠. 다른 팀들을 보니 저처럼 API 명세를 오직 백엔드 팀에게만 맡기는 경우가 있던데, 어차피 프론트에서도 점검 해야해서 일을 두 번 하는 꼴이 되는 것 같습니다. 게다가 서로 이해하고 있는 게 달라 내용이 뒤엉키면 수정을 하는 데에 시간이 더 많이 들었던 것 같습니다.

 

다음부터는 FE+BE 팀원이 모두 모여 유저플로우를 따라 요청을 정리해야겠습니다..

 

 

 

 

마치면서...

아무래도 어울리지 않게 팀장이라는 역할을 맡게 되니, 이전에 내가 참여한 팀들의 아주 훌륭한 팀장님들이 얼마나 분석적이고 체계적으로 사람들을 이끄는 능력이 있는지 다시 한 번 깨닫게 되었습니다. 당시에도 정말 대단하다고 생각했는데, 똑같은 상황에 처해보니 다들 어디서 배워서 그렇게 잘하셨나 궁금할 지경입니다.

 

하지만 정말 운이 좋은 건, 저보다 친절하고 똑똑한 팀원들을 만나서 제 실수가 무엇인지 바로바로 깨달을 수 있었다는 점입니다. 이걸 기회 삼아 앞으로 같은 실수를 반복하지 않고 팀장이든 팀원이든 어떻게 해야 팀이 잘 굴러가는지 배워야겠습니다.