Unit 3 - SRS

2023-08-08(화)

 

SRS의 정의

SRS(소프트웨어 요구 사항 사양)는 소프트웨어 요구 사항 사양이 무엇인지 설명하는 문서입니다.
소프트웨어가 수행하고 수행할 것으로 예상되는 방식입니다. 또한 다음을 설명합니다.
제품이 모든 이해 관계자(비즈니스, 사용자)를 충족시키는 데 필요한 기능이 필요합니다.

SRS는 정의에서 살펴본 바와 같이 우리가 개발하고자 하는 소프트웨어(제품)가 무엇을 하는 것이고 어떻게 작동할지를 예상하는 문서의 집합입니다.

 

그렇다면 이러한 내용들을 어떤 문서로 어떻게 정리해야 하는지 살펴볼 필요가 있습니다. 정리하자면 SRS는 소프트웨어(제품)를 기획/분석, 설계, 구현, 시험하는 데 있어 필요한 종합 설계도와 같다고 할 수 있습니다.

 

프로젝트에서 SRS가 중요한 이유

위에서 언급된 대로 SRS는 종합 설계도와 같습니다.

 

결국 SRS는 프로젝트의 전체적인 그림을 제공합니다. 모든 분야에서 전체적인 그림을 그려보는 작업은 매우 중요합니다. 소프트웨어(제품) 개발에 관련된 모든 팀이 따라야 하는 것의 집합이며 그 원천을 제공하기 때문입니다. 개발 외에도 영어 학습을 위한 로드맵, 특정 사업의 과업 설계 등 이미 수많은 분야에서 그 필요성은 검증되었습니다.

 

비즈니스 관점에서의 개발 프로젝트 이해

   1. 과업 발생

- 개발팀이 프로젝트를 시작하고 착수하는 단계 / 계약 체결을 포함하여 프로젝트 전반에 대한 논의가 진행됩니다.

- 니즈가 발생하는 발주처에서 진행되어야 할 과업이 그 집단의 니즈에 맞게 발생하게 됩니다.

 

   2.사업자 선정 및 계약

- 사업자가 선정되면 발주처는 선정된 사업자에게 거래를 제안하고 여러번의 미팅을 거쳐 최종 계약을 진행하게 됩니다.      이때 발주처는 선정된 사업장에 명확한 요구사항과 일정, 사업 비용 등을 명시할 필요가 있습니다. 이러한 행위를                 RFP(Request For Proposal, 제안 요청서)로 작성하여 문서화 합니다.

- 제안 요청서는 개요와 구축 컨셉, 제안요청사항 정의, 제안서 작성가이드 정의의 내용을 포함합니다.

 

*제안서* 란 수주할 사업자가 해당 내용을 바탕으로 해당 과업을 이렇게 해결하겠다고 제안하는 행위 전체를 의미합니다.

 

   3. 기획/분석

- 진행할 프로젝트의 계약을 포함한 모든 사전 처리가 완료되었다면 프로젝트를 총괄하는 PM (Project Manager)은 프로젝트를 성공적으로 수행하기 위해서 일해야 합니다.

- 계약 관계에 있어 가장 중요한 부분은 인력, 시간, 돈으로 나뉠 수 있는데 PM의 역량에 따라 이 요소들이 조절되거나 결정됩니다.

- 많은 고민의 과정이 ‘기획' 단계에서 구체화 됩니다. 인력, 시간, 돈을 고려하여 고객의 요구사항을 잘 고민하고 그 과정에서 고객과의 소통을 통해 탄생하는 문서가 SRS (Software requirements specification) 입니다.

 

   4. 설계

- 설계 단계는 기획된 SRS의 목표에 따라 그에 맞는 구체적인 설계가 고려되는 과정입니다.

- 개발자를 포함한 프로젝트 인원은 그들의 역할에 맞는 특정 내용을 정리하는 문서들을 통해 설계를 구체화 합니다.

- 화면 정의서, 아키텍처 설계서, 클래스 정의서 등이 설계 문서의 일부입니다.

 

   5. 구현

- 실제로 기획/분석 → 설계 과정을 거친 후 그 가이드에 맞게 개발 업무를 수행하는 과정입니다.

- 우리가 올바르게 개발을 잘 하고 있는지를 알기 위해서 개발된 최소의 단위(동작 단위)로 그 결과를 시험하고 그 결과를 기술하기도 합니다. 개발자들 사이에서는 ‘유닛 테스트'라고 많이 언급되고 있습니다.

 

   6. 시험

- 올바르게 구현이 되었는지, 구현의 결과가 올바른 설계에 의한 것인지 등을 면밀하게 검토

- ‘통합 시험'을 통해 완성된 온전한 하나의 서비스가 그 역할을 잘 수행할 수 있는지를 검사합니다. 또한 이 과정에서 서비스 오픈을 위해 사용자나 운영자 관점에서의 지침서(매뉴얼) 등을 작성하기도 합니다.

 

   7. 서비스 오픈

- 모든 준비가 끝나면 서비스가 오픈됩니다. 프로젝트가 완전히 끝난것은 아닙니다. 유지보수가 남아있기 때문입니다.

 

   8. 유지보수

- 프로젝트가 계약될 시점에 ‘유지보수'에 대한 항목을 보통 명시합니다. 유지보수 기간은 경우에 따라 다릅니다. 유지보수는 우리가 가전제품을 구매하면 AS 기간을 제공해주는 것과 같습니다.

 

 

---

개발 프로젝트 구분

 

• 솔루션 : 솔루션이라고 함은 기업에서 개발한 제품입니다. 카카오톡이나 배달의 민족 애플리케이션이 대표적입니다. 그 기업의 고유한 자산이자 매출의 원천이 됩니다. 완벽하게 올바른 의미는 아니지만 현시점에서 말하는 ‘솔루션 개발 회사'는 이렇듯 우리의 솔루션을 개발하는 회사를 의미합니다.
• SI (System Integration) : 시스템 구축을 의미합니다. 사실 기존의 SI 뜻은 요즘에 사용되는 SI와는 의미가 조금 달랐습니다. 예전에는 기업의 전산시스템을 구축할 때 자체적으로(외부의 힘을 빌리지 않고) 시스템을 구축했습니다. 하지만 시간이 흐르면서 시스템이 복잡해지고 더 높은 전문성이 요구됨에 따라 특화된 기업과 계약을 맺고 진행하는 형태로 발전하게 되었습니다. SI라는 의미 자체는 시스템을 구축하는 행위를 압축해서 표현함이 올바른 표현입니다.
• SM (System Management) : 시스템 운영 및 유지보수를 의미합니다. 시스템 개발보다는 개발 완료되어 서비스되는 시스템을 관리하는 관리자로 운영에 초점이 맞춰진 형태를 뜻합니다. 예로 들면 대기업 금융 회사의 전산실 업무 담당 등이 있겠습니다.

‘네이버나 카카오 같은 회사들은 <비즈니스 관점에서의 개발 프로젝트 이해>에서 설명한 느낌과 다르지 않은가?’를 고민해 보겠습니다. 위 용어 정리를 보면 카카오나 네이버 같은 회사는 ‘솔루션 회사'라고 개발자 입장에서 생각할 수 있습니다. 그리고 실제로 일상적인 대화를 할 때에는 그렇게 불리고 있습니다. 그렇다고 해서 솔루션 회사들이 SI나 SM 업무를 하지 않는가에 대한 질문엔 ‘아니요’라고 답할 수 있습니다.

 

우리의 솔루션을 만들어 낸 A라는 회사가 있는데 이 솔루션을 원하는 다른 기업에 단순히 판매를 해서 사용하게 할 수 있지만 솔루션의 내용과 기능에 따라 그 기업에 특화되게 커스터마이징 해야 하는 경우도 있고(SI) 솔루션을 도입한 기업에서 특정 기간 동안 시스템 운영을 부탁(SM) 할 수 있습니다. ‘오라클’이나 ‘SAP’ 같이 전 세계적으로 유명한 솔루션은 그 기술을 익힌 사람들이 매우 많기 때문에 채용이 가능하지만 그렇지 않다면 해당 솔루션 회사와 계약하여 부분 수정 요청을 하거나 시스템 운영 계약을 맺을 수 있다는 의미입니다.

 

따라서 <비즈니스 관점에서의 개발 프로젝트 이해>의 내용은 개발 회사의 구분을 떠나서 하나의 프로젝트가 사업적인 측면에서 진행되는 과정의 큰 흐름이라고 정리하면 좋고, 해당 <개발 프로젝트 구분>은 우리나라 개발자의 개발 형태를 대략적으로 구분하여 이해하는 내용이라고 정리하면 좋겠습니다. 기술의 발전과 시대의 흐름에 따라 이러한 절차나 형태는 계속해서 변화할 수 있으며 인식 또한 달라질 수 있습니다. 절대적인 것은 없으며 중요한 것은 개발자는 개발만 하는 것이 아니라 하나의 사업 모델이라는 관점에서 그에 맞는 직무를 수행할 수 있는 역량을 키워야 함을 인지할 필요가 있습니다.

 

 

SRS의 구성

 

1. 소개이 문서에 요구사항이 명시되어 있는 제품 또는 애플리케이션을 설명한다. 이 SRS가 전체 시스템 중 일부에만 관련된 것이라면 그 부분 또는 하위시스템을 설명한다.텍스트 스타일, 하이라이트 또는 주석과 같은 모든 표준 또는 표기규칙을 설명한다.SRS가 대상으로 하고 있는 다양한 독자계층을 나열한다. SRS의 나머지 부분과, SRS가 조직되어 있는 방법을 설명하고, 각각의 독자 계층에 대해 가장 적합한 읽기 순서를 설명한다.설명되고 있는 소프트웨어와 그 목적에 대해 간단하게 설명한다.이 SRS가 참조하고 있는 모든 문서 또는 다른 리소스를 나열하며, 가능한 경우에는 하이퍼링크도 포함시킨다.
2. 1.5 참조 (Reference)
3. 1.4 프로젝트 범위 (Project Scope)
4. 1.3 독자대상과 읽는 방법 (Intend Audience and Reading Suggestion)
5. 1.2 문서 규칙 (Document Convention)
6. 1.1 목적 (Purpose)

1. 전체 설명 (Overall Description)제품의 구성과 유래를 설명한다. 제품이 확장되는 제품군의 다음 구성제품인지, 완성된 시스템의 다음 버전인지, 기존 애플리케이션을 대체하는 것인지, 완전히 새로운 제품인지를 설명한다.제품이 가지고 있는 주요 기능 또는 제품이 수행하는 중요한 기능을 나열한다. 요구사항의 주요 그룹과 그 그룹이 연결되어 있는 방법을 설명하는 최상위 데이터 플로우 다이어그램, 유스케이스 다이어그램, 클래스 다이어그램 등이 도움이 된다.이 제품을 사용할 것으로 예상되는 사용자계층을 파악하고 그들의 특징을 설명한다.하드웨어 플랫폼, 운영체계와 버전, 사용자, 서버와 데이터베이스의 지리적 위치 등과 같은 소프트웨어가 동작되는 환경을 설명한다. 시스템이 아무런 문제 없이 연동해야 하는 다른 소프트웨어 컴포넌트 또는 애플리케이션을 나열한다.개발자가 선택할 수 있는 사항을 제약하는 모든 요소와 각 제약조건의 이유를 설명한다. 제약 조건은 다음과 같다.
   • 반드시 사용하거나 피해야 하는 기술, 툴, 프로그래밍 언어와 인터페이스.
   • 사용될 웹 브라우저의 유형과 버전과 같이 제품의 운영환경으로 인한 제약.
   • 필요한 개발 규칙 또는 표준(예를 들면 고객의 조직이 소프트웨어를 유지보수 할 예정이라면, 그 조직은 하청업체가 따라야 하는 설계 표기법과 코딩 표준을 명시할 수 있다.)
   • 이전 제품과의 호환성.
   • 비즈니스 규칙에 따른 제약.
   • 메모리 또는 프로세스의 제약, 크기, 무게, 비용과 같은 하드웨어의 제약.
   • 기존 제품을 개선하는 경우에 따라야 하는 기존 사용자 인터페이스 규칙.
   • XML과 같은 표준 데이터 교환 형식.
   2.6 사용자 문서 (User Documentation)2.7 가정과 종속관계 (Assumptions and Dependencies)
2. 가정이 잘못되거나 이것을 공유하지 않는다면 문제가 발생될 수 있기 때문에 어떤 가정은 프로젝트 위험으로 간주된다. 프로젝트가 통제할 수 없는 외부 요소에 어느 정도 종속되는지 또한 설명해야 한다.
3. 소프트웨어와 함께 제공할 사용자 문서를 나열한다. 사용자 문서로는 사용자 매뉴얼, 온라인 도움말, 교재 등이 있으며 따라야 하는 문서 전달 형식, 표준 또는 툴이 있다면 그것들을 설명한다.
4. 2.5 설계 및 구현 제약사항 (Design and Implementation constraint)
5. 2.4 운영 환경 (Operation Environment)
6. 2.3 사용자 계층과 특징 (User Classes and Characteristic)
7. 2.2 제품 기능 (Project Feature)
8. 2.1 제품조망 (Product Perspective)

1. 시스템 특징 (System Feature)가. 설명과 우선순위 (Description and Priority)나. 자극/응답 순서 (Stimulus / Response Sequence)다. 기능 요구사항 (Functional Requirement)
2. 이 기능과 관련된 상세한 기능 요구사항을 항목으로 나열한다. 이것들은 사용자가 기능의 서비스를 수행하기 위해 또는 유스케이스를 수행하기 위해 사용하는 소프트웨어의 기능들이다.
3. 입력 자극(사용자 행동, 외부 장비의 신호 또는 다른 자극)의 순서와 이 기능에 대한 동작을 정의하는 시스템 반응을 나열한다.
4. 기능에 대해 간단하게 설명하고 그것이 높은 우선순위인지 낮은 우선순위인지를 나타낸다. 우선순위는 프로젝트 중에 변할 수 있는 동적인 것으로, 요구사항관리 툴을 사용한다면 요구사항 특성의 우선순위를 정의한다.
5. 3.1 시스템 특징

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

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

1. 다른 요구사항 (Other Requirement)
2. SRS의 다른 부분에서는 다루지 않는 모든 요구사항을 정의한다.