소프트웨어 스펙의 모든 것

책 [소프트웨어 스펙의 모든 것]을 읽고 정리한 문서이다.

소프트웨어 스펙의 개요

소프트웨어 프로젝트 실패의 원인

아래는 프로젝트가 실패했다고 판단하는 기준이다.(사람마다 다를 수 있다.업데이트)

• 약속된 일정 내 제품 또는 서비스를 출시하지 못했다.
• 소프트웨어가 요구되는 품질(기능 요구사항, 성능, 안정성, 사용성, 확장성 등)을 충족하지 못했다.
• 프로젝트에 꼭 필요한 기술 개발에 실패했다.
• 아키텍처가 뒤죽박죽이 되어 유지보수가 어려워졌다.
• 애초 예산보다 훨씬 더 많은 비용이 지출됐다.
• 연이은 야근으로 조직 사기가 떨어지고 많은 사람이 그만뒀다.

아래는 프로젝트가 실패하는 원인들이다.

• 고객의 요구사항을 충분히 파악하지 못했다.
• 초기에 제품의 방향을 빨리 정하지 못하고 우왕좌왕하며 보낸 시간이 많아서 정작 개발 시간이 부족했다.
• 스팩과 설계를 꼼꼼하게 작성하지 않고 코딩을 시작해서 엉뚱한 방향으로 개발했다.
• 작성된 스펙을 프로젝트 이해관계자들이 철저히 검토하지 않아서 잘못된 스펙으로 개발됐다.
• 진행할수록 새로운 요구사항이 계속 생겨서 프로젝트가 한없이 늘어졌다.
• 변경된 요구 사항을 일관되게 관리하지 못해서 프로젝트 팀원들이 서로 다른 기준으로 개발했다.
• 상명하달된 출시 일정에 맞추기 위해 급하게 코빙부터 시작했다. 나중에 잘못된 코드를 재작성하느라 시간이 더 많이 소비됐다.
• 훈련이 덜 된 개발자들을 투입해서 초반에 갈팡질팡하느라 시간을 지체했다.
• 느슨한 일정 관리로 프로젝트가 지연되고 있다는 징후를 알아채지 못했다.
• 리스크 관리를 하지 않아서 프로젝트에 큰 문제가 발생해 실패했다.
• 프로젝트 막판에 경영진이나 주요 고객이 프로젝트 방향을 완전히 틀어서 처음부터 다시 개발해야 했다.
• 지속적인 팀워크 불화로 프로젝트가 산으로 갔다.
• 외부에서 도입한 필수 기술이 기대처럼 동작하지 않는다는 사실을 막바지에 알게 됐다.
• 테스트팀에 스펙을 제대로 전달하지 못해서 테스트 준비를 충분히 하지 못했다.
• 회사의 표준 프로세스를 강요해 문서를 많이 만들다 보니 정작 개발에는 소홀해졌다.

위 프로젝트가 실패하는 원인들을 크게 나눠 스펙, 팀, 관리, 고객, 기술등으로 분류할 수 있으나 이 책에서는 스펙에 관해 이야기한다.

프로젝트 규모가 작을 경우, 스펙을 제대로 적지 않고 요구사항 몇 줄로 개발해도 무난히 완성할 수 있으나 수십 명의 개발자가 투입되는 대규모 프로젝트에서는 체계적으로 정리된 스펙 문서가 반드시 필요하다.

소규모 프로젝트에 대규모 방법론을 적용하는 것이 실패의 원인이 될 수도, 반대로 대규모 프로젝트에 중소규모 방법론을 적용하는 것이 프로젝트 실패의 원인이 되기도 한다.

개발은 문서대로 진행되지 않을 뿐만 아니라 문서가 너무 많아 수시로 바뀌는 요구사항을 전부 문서에 반영하지도 못한다.

따라서 엄격한 프로세스로 규제하는 것도 어렵다.

저자가 생각하는 최선의 방법은 '원칙만 지킬 수 있는 최소한의 프로세스 환경에서 좋은 문화를 공유'하는 것이다.

모든 이해관계자들이 스펙을 철저히 검토하고, 사소한 이유로 쉽게 요구사항을 바꾸지 말아야 한다.

좋은 환경이라도 스펙을 작성하는 역량이 부족하다면 소프트웨어 프로젝트의 성공을 보장하기 어렵다. 스펙을 제대로 적는 역량은 소프트웨어 개발에서 가장 어려운 능력이며 소질 있는 개발자도 10년 이상의 경험과 노력으로 터득하는 기술이다.

스펙에 대한 오해

스펙을 적는 것이 좋은 줄 몰라서 안 적는 게 아니다

스펙을 제대로 적고 소프트웨어를 개발하는 것이 좋은 줄은 아는데 어떤 사정 때문에 스펙을 제대로 작성하지 못한다는 얘기다.

필요하면 언제든 적을 수 있다고 주장하기도 한다.

위와 같이 주장하는 사람들은 스펙 작성이 소프트웨어 프로젝트에서 얼마나 중요하고 필요한지 확실이 모를 공산이 크다.

스펙은 프로젝트를 성공으로 이끄는 주된 요소이기 때문에 작성하는 것이다.

단, 스펙의 양과 작성법은 프로젝트 성격에 따라 달라질 수 있다.

소프트웨어를 만들어보기 전에는 천재도 그 내용을 다 알 수 없다

일리 있으나 100% 모든 것을 아는 것만 프로젝트로 수행하지 않는다. 성공을 장담할 수 없는 알고리즘이나 한 번도 사용해보지 않은 상용 라이브러리로 소프트웨어를 개발하기도 한다. 프로젝트 중후반까지 고객의 요구사항을 다 파악하지 못하기도 하고, 요구사항이 몇 번이고 번복되기도 한다.

스펙을 제대로 작성한다는 것은 자세히 작성한다는 것이 아니며 프로젝트 내 어려움과 미지수까지 사실 그대로 적시해야 하며, 검증을 통해 불확실성을 줄여가야 한다.

나도 작성할 줄 아는데 쓸 시간이 없다

시간이 없어 스펙을 작성하지 못한다는 것은 모순이다. 스펙을 제대로 작성하는 이유는 최단 기간에 소프트웨어를 개발하기 위해서다. '스펙'하면 방대한 문서가 먼저 떠오르지만, 적은 양으로도 스펙을 제대로 작성하는 경우가 많다.

일정이 촉박한 탓에 스펙을 건너뛰고 프로젝트를 진행한다면, 대개의 경우 스펙을 제대로 작성하고 진행하는 것 보다 더 오래 걸린다. 모든 프로젝트는 적절한 인력과 시간이 필요한데 시간이 절대적으로 부족한 비즈니스 상황에 처했다면, 스펙을 생략하는 것보다 효율적으로 신속하게 작성하는 것이 훨씬 더 낫다.

스펙을 항상 일정한 절차를 거쳐 상세하게 많이 작성해야 한다는 것은 오해다. 비즈니스 상황과 프로젝트 여건에 맞게 프로젝트를 가장 빨리 끝낼 수 있는 방법으로 작성하는 것이야말로 스펙을 제대로 작성하는 방법이다.

나도 작성해봤는데 우리 경우는 달라서 적기 어렵다

많은 회사에서 말하길, 자사 소프트웨어는 일반적인 것이 아니라서 스펙을 작성할 수 없다고 한다.

스펙 관점으로 보면 모든 소프트웨어는 같다. 모든 소프트웨어에는 스펙이 있고 스펙을 제대로 작성하는 것은 소프트웨어 프로젝트의 성패를 가를 만큼 중요하다.

기획팀에서 주는 문서로는 스펙을 적을 수 없다

기획팀에서 기획서를 잘 작성해주면 소프트웨어 스펙을 작성하는 데 많은 도움이 된다. 기획팀에서 고객 요구사항을 충분히 파악하지 못하거나 소프트웨어 비전과 전략을 꼼꼼하게 정리해서 전달하지 못하는 경우가 비일비재하다.

기획이 부실하다면 소프트웨어 분석 담당 아키텍트가 기획에서 해야 할 역할도 일부 수행하는 것이 좋다.

폭포수 모델과 달리 우리는 애자일이라서 잘 적을 필요가 없다

스펙 작성은 폭포수 모델에서나 하는 것이라는 생각은 오해다. 실무에서 폭포수 모델을 사용하는 소프트웨어 회사는 거의 없다. 방법론과 상관없이 소프트웨어 스펙은 중요하다.

애자일이라 하더라도 스펙 내용은 바뀌지 않고 적는 방법이 달라질 뿐이다.

잘된 샘플을 보고 싶다

스펙 작성을 배울 때도 샘플을 보여달라고 하며 샘플에 적한 내용을 그대로 옮겨와 자기 프로젝트에 맞게 바꾼다.

위와 같은 식으로 스펙을 작성하면 100% 실패한다. 세상 모든 프로젝트가 서로 다른데 샘플을 보고 작성하는 것은 어불성설이다.

많은 경우 샘플은 도움보단 방해가 된다. 샘플에 적혀있는 내용은 그 상황에만 맞는 것이다. 샘플에 잘못된 방법으로 흉내 내서 적다가 나쁜 습관으로 굳어진다.

스스로 많은 생각을 하며 직접 맨땅에 부딪쳐보는 것이 현명하다.

실리콘밸리에서는 한번 적은 스펙은 변경되지 않는가?

프로젝트 도중 스펙이 변경되지 않는 경우는 거의 없다.

스펙 변경을 기정 사실로 인정하고 매번 스펙을 제대로 작성해야 한다.

변경이 잦은 프로젝트에서는 스펙 작성법도 바뀔 수 있다. 변경을 쉽게 받아들이는 노하우를 적용하고 제각각 다른 프로젝트에 특성에 맞춰 작성법도 달리해야 한다.

스펙의 역할

모든 프로젝트 이해관계자를 연결하는 프로젝트의 중심이다

스펙은 프로젝트의 모든 요구사항을 취합해 프로젝트의 중심이 되는 문서다.

프로젝트의 모든 이해관계자가 스펙을 참조하거나 작성에 참여해 스펙은 다시 여러 이해관계자들에게 전달되어 본연의 역할을 수행한다.

고객, 마케팅, 영업팀은 어떤 제품이 만들어질지 미리 알 수 있다

스펙이 없거나 부실한 상태로 진행되면 개발이 완료되기 전까지 어떤 소프트웨어가 개발될지 알기 어렵다. 위와 같은 상황이면 영업팀은 소프트웨어 개발이 완료되기 전에 판매 준비를 하거나 계약을 할 수 없다.

스펙이 잘 작성될 경우 최종적으로 개발될 소프트웨어가 어떤 것인지 정확히 알 수 있다. 위와 같은 상황이면 영업팀은 판매 준비를 미리 할 수 있다.

안전, 의료, 보안 등의 인증이 필요한 경우, 스펙이 잘 작성되었다면 소프트웨어 개발이 완료되기 전 인증을 신청해 획득할 수 있다. 개발 후 인증 받으려다 수년의 영업 기회를 날려버릴 수 있다.

프로젝트 관리자에게는 스펙이 관리 기준이다.

스펙이 제대로 작성되지 않았다면 프로젝트 관리자는 할 일이 별로 없다. 인력 산정, 인력 배분, 리스크 분석등을 진행하지 못하여 적절한 리소스 계획도 세우지 못한다. 프로젝트 관리자가 프로젝트의 정확한 진척률을 확인할 수 없다.

프로젝트의 성격에 따라 단계를 나누어 진행하며 짧은 주기로 여러 차례 업그레이드 하는 경우도 있으나 주기만 짧을 뿐 주기에 해당하는 스펙을 제대로 작성하는 것은 똑같이 필요한 일이다.

개발팀은 스펙을 통해 개발해야 할 제품이 무엇인지 정확히 안다

스펙을 제대로 작성하지 않았다면 개발팀은 정확하게 무엇을 개발해야 하는지 파악하지 못한다. 기획자나 분석 아키텍트에게 수시로 물어야 해서 시간 낭비가 크다. 개발자가 임의로 생각해 기능을 구현하면 기획 의도와 전혀 다른 제품이 만들어진다.

개발자에게 주어진 재량이 과도하면 소프트웨어 아키텍처가 부실하게 만들어지기도 한다. 소프트웨어 전체 아키텍처가 분석, 설계에서 정해져서 개발자에게 한정된 재량만 주어져야 한다. 그렇게 해야 의도한 대로 소프트웨어가 개발된다.

테스트팀은 스펙을 통해 테스트 계획 및 테스트 케이스를 작성한다

보통은 스펙 작성 후 개발자들이 구현하는 동안 테스트팀이 테스트 준비를 한다.

스펙이 없거나 부실하다면 결과물이 나오기 전에 테스트 계획을 세우고 테스트를 설계할 수 없다.

이에 따라 소프트웨어 품질이 떨어지고 프로젝트 일정도 지연된다.

기술문서팀은 스펙을 보고 매뉴얼과 도움말을 작성한다

스펙이 완성된 후에는 많은 사람이 바빠진다.

기술문서팀은 스펙을 보고 메뉴얼부터 작성한다. 그리고 나중에 개발된 소프트웨어를 동작해보며 화면 캡처를 추가해 매뉴얼을 완성한다.

고객지원팀과 교육팀도 스펙을 보고 일을 시작한다.

스펙 없이 소프트웨어를 개발하는 것은 개발자 중심 방식이며 프로젝트의 효율적 진행에도 도움이 되지 않는다.

외주 업체는 스펙을 통해 업무를 정확하게 파악하고 SRS를 기준으로 계약한다

우리나라에서는 많은 소프트웨어 프로젝트가 스펙 없이 진행된다.

SRS 작성법

Introduction(개요)

개요는문서를 처음 본 사람이 이 문서가 무엇에 관한 것인지, 어떻게 읽어야 하는지 가르쳐준다.

짧은 문서에는 필요 없으며 분량이 많을수록 문서를 읽는 사람이 효율적으로 필요한 내용을 찾을 수 있다.

Purpose(목표)

목표는 보통 소프트웨어의 시스템 이름, 버전, 별도 목적을 작성한다.

Product Scope(범위)

범위는 개발할 소프트웨어가 어떤 것인지를 간략하게 적는다.

이해관계자 입장에서 가장 중요한 섹션 중 하나이다.

지원하는 것과 지원하지 않는 것도 기술해야 한다.

Document Conventions(문서 규칙)

문서 규칙에서는 문서의 표준 스타일을 정의한다.

아래 내용들을 고려하면 좋다.

• 깔끔한 구성
  • 글자, 줄 간격, 들여쓰기, 탭 등으로 깔끔하고 일관성 있게 작성해야 한다.
  • 다른 누군가가 작성해도 구성이 일관되어야 한다.
  • 문서 작성자는 스타일을 사용해 문서를 편집하며 가급적 글자, 줄 간격 등을 수동으로 수정하지 않도록 한다.
• 우선순위 표기
  • 각 기능에 우선순위를 표기하되, 그 표기법은 전사 통일해야 한다.
  • 우선순위가 일관성이 있어야 한다.
• 여러 버전의 내용 표기
  • 소프트웨어를 업그레이드 할 때 마다 매번 SRS를 작성하는 것이 아닌 해당 내용에서 수정하며 덮어쓴다.
• 커스터마이징 내용 표기
  • 특정 회사에 공급하는 버전만 예외적으로 기능을 추가, 변경, 삭제하는 경우 별도 표기한다.
• 컬러 구분
  • SRS 문서는 꼭 모니터에서만 보는 것이 아니라 인쇄하여 보기도 한다.

Terms and Abbreviations(정의 및 약어)

정의 및 약어에서는 분야마다 서로 약어를 다르게 쓰는 경우가 많기 때문에 뜻을 풀어 설명해주는 것이 좋다.

아래의 요령에 맞게 정의 및 약어를 기술하면 된다.

• 프로젝트 이해관계자를 기준으로 일부 사람이 알지 못할 수 있는 용어는 가능하면 모두 설명한다.
• 특정 이해관계자만 읽는부분에 나오는 용어는 모든 이해관계자를 위해 모두 설명할 필요가 없다.
• 모든 이해관계자가 뻔히 다 아는 용어는 설명하지 않는다.
• 모두가 알 만한 용어는 설명하지 않는다.

Related Documents(관련 문서)

관련 문서에서는 SRS를 읽는 데 도움되는 문서나 링크를 걸어준다.

Intended Audience adnd Reading Sugggestions(대상 및 읽는 방법)

대상 및 읽는 방법은 방대한 SRS의 경우 독자 계층을 분류하여 필요한 내용만 읽을 수 있게 추천해주는 영역이다.

• 이해관계자 계층
  • 개발자
  • 마케터
  • 사용자
  • 프로젝트 관리자
  • QA
  • 테스터
  • 분석가
  • 설계자
  • 경영자
  • 영업팀
  • 고객
  • 지원팀

Project Output(프로젝트 산출물)

프로젝트 산출물에서는 결과물의 형태와 버전 등을 기술한다.

산출물 형태가 독립된 소프트웨어나라이브러리, 툴, 유틸리티인지 구분해 기술한다.

산출물의 공식 명칭도 기록해야 한다.

공식 명칭을 정하지 못한 경우 그 전까지 사용할 가칭을 기록한다.

Overall Description(전체 설명)

전체 설명에는 완성된 프로젝트 산출물의 전체적인 구성 및 동작, 기능에 대해 간략히 기술한다.

이 챕터부터 본격적으로 소프트웨어 내용에 대해 엔지니어링 관점의 정보를 적기 시작한다.

Product Perspective(제품 조망)

제품 조망에선 제품을 바깥에서 바라본 모습을 기술한다.

프로젝트 산출물과 회사의 기존 제품, 신규 제품 또는 외부 시스템과의 관계 및 연관성을 기술한다.

큰 시스템의 일부분일 경우 큰 시스템과의 인터페이스를 기술한다.

제품을 외부에서 바라본 관점에서 시스템을 인터페이스와 함께 간단한 다이어그램으로 표현하는 것이 유용하다.

Overall System Configuration(전체 시스템 구성)

전체 시스템 구성에서는 제품의 내부 모습을 기술한다.

이 섹션에서는 시스템의 내부가 어떻게 구성되었는지 간략하게 설명한다.

제품 내부 주요 컴포넌트를 도출하고 그 컴포넌트들 간 연관 관계를 설명한다.

Overall Operation(전체 동작 방식)

전체 동작 방식에선 프로젝트 산출물의 전체 시스템 구성을 기준으로 동작 원리와 시나리오를 기술한다.

이 섹션에는 대략적으로 시스템이 어떻게 동작하는지 기술한다.

Product Functions(제품 주요 기능)

제품 주요 기능에서는 프로젝트의 주요 기능을 간략하게 기술한다.

세부 기능은 이후 작성하므로 이 섹션에서 상세히 기술하지 않는다.

이 섹션에서 사용하는 용어와 표현법은 고객 수준에 맞춘다.

큰 의미가 없는 소소한 기능을 일일히 나열하거나 단어로만 축약해 적는 것은 좋지 않다.

User Classes and Characteristics(사용자 계층과 특징)

사용자 계층과 특징에서는 프로젝트 산출물의 사용자 계층과 각각의 특징을 기술한다.

이 제품을 사용할 것으로 예상되는 다양한 사용자 계층을 식별하는데, 이때 최종 사용자뿐만 아니라 관리자, 기술 지원 등 모든 사용자를 아루른다.

사용자 계층 별로 이 제품의 사용 빈도, 주로 사용하는 기능을 기술한다.

각 사용자 계층이 보유해야 할 기술이나 전문 지식, 교육 수준을 명시하고 각 사용자 계층의 중요도에 대한 설명도 할 수 있다.

사용자 계층이 식별되면 사용자 계층을 표준화하고 사용자를 위한 기능을 구성하는 데 도움된다.

Assumptions and Requirements(가정과 종속관계)

가정과 종속관계에서 프로젝트를 수행하기 위해 필요하거나 반드시 수행 또는 결정되어야 할 전제 조건, 선행되어야 할 사항을 기술하며 그 결과가 프로젝트의 어떤 부분에 어떻게 영향을 미치는 지 설명한다.

통제 불가한 외부 요소의 영향을 받을 수 있는 경우, 그 요소에 대해서도 기술한다.

Apportioning of Requirements(단계별 요구사항)

소프트웨어 첫 버전을 개발할 때 너무 많은 기능을 포함하지 않고 기본에 충실한 것이 프로젝트 성공 확률을 높인다.

단계별 요구사항에서는 차후 버전으로 넘길 수 있는 기능을 기술한다.

Backward Compatibility(하위 호환성)

하위 호환성에서는 기존 시스템을 업그레이드 하는 시스템일 경우 종래에 연동했던 시스템이나 데이터와 호환 가능 여부와 방법을 기술한다.

Environment(환경)

환경에서는 소프트웨어를 개발하고 테스트하고 동작시키기 위한 환경을 다룬다.

환경에 대한 정확한 기준이 있어야 혼란이 발생하지 않는다.

Operating Environment(운영 환경)

운영 환경에서는 프로젝트를 통해 개발될 산출물을 설치하고 운영할 하드웨어 환경과 소프트웨어 환경을 기술한다.

Product Installation and Configuration(제품 설치 및 설정)

제품 설치 및 설정에선 프로젝트 산출물의 설치 과정에서 필요한 요구 사항을 기술한다.

Distribution Environment(배포 환경)

배포 환경에서는 프로젝트 산출물을 어떤 형태로 구성할 것인지 기술한다.

• 마스터 구성
• 배포 방법
• 설치 방법
• 패치, 업데이트 방법

Development Environment(개발 환경)

개발 환경에서는 개발에 필요한 하드웨어, 운영체제, 소프트웨어 등의 개발 툴 정보를 기록한다.

개발 환경을 미리 정하지 않으면 개발 도중에 개발 환경 문제로 괜한 시간을 낭비할 수 있다.

Test Environment(테스트 환경)

테스트 환경은 테스트를 수행할 모든 운영체제 목록을 기술한다.

그 외 자동화를 위한 툴을 정의하고 테스트 관리 툴로 무엇을 쓸지도 기록한다.

Configuration Management(형상 관리)

프로젝트의 베이스라인에 포함되는 문서, 소스코드를 어떻게 관리할지 결정한다.

이 섹션에서는 아래 항목들을 기술한다.

• 사용할 형상 관리 시스템
• 베이스라인에 포함될 산출물
• 형상 관리 프로세스
• 브랜치 머지 정책 및 프로세스
• 베이스라인 설정, 즉 태깅 정책 및 프로세스
• 소스코드 디렉터리 구조
• 담당자별 디렉터리 접근 권한

Bugtrack System(버그트래킹 시스템)

프로젝트를 진행하면서 버그를 등록하고 관리할 버그트래킹 시스템 정보를 기술한다.

External Interface Requirements(외부 인터페이스 요구사항)

소프트웨어의 아키텍처를 설계하려면 가장 먼저 개발하고 있는 시스템과 상호작용하는 외부 시스템을 모두 파악해야 한다.

System Interface(시스템 인터페이스)

시스템 인터페이스에서는 이 시스템이 연동해야 할 외부 시스템과의 인터페이스를 기술한다.

각 인터페이스를 정의할 때 아래와 같은 내용을 포함한다.

• 인터페이스 우선 순위
• 인터페이스 데이터 타입
• 인터페이스 데이터 크기 및 형식
• 인터페이스 데이터 단위
• 인터페이스 데이터 범위
• 인터페이스 발생 시간
• 인터페이스 발생 순서
• 인터페이스 데이터 보안 등
• 각 인터페이스의 조합
• 통신 방법
• 프로토콜
• 에러 처리 방법

User Interface(사용자 인터페이스)

사용자 인터페이스에선 시스템과 사용자가 어떻게 상호작용하는지 기술한다.

소프트웨어와 사용자 간 각 인터페이스의 논리적 특징을 설명하면 된다.

글로만 작성하기 보다 화면 이미지, UI 목업, 와이어프레임, UI 스타일 가이드, 화면 레이아웃 등 다양한 방법으로 표현하는 것이 좋다.

Hardware Interface(하드웨어 인터페이스)

하드웨어 인터페이스에서 프로젝트 산출물과 하드웨어 시스템 간의 인터페이스를 정의한다.

이 프로그램은 4GB RAM의 Mac에서 실행되어야 합니다.

위 예시와 같이 하드웨어 요구사항을 명시하지 않는다.(위와 같은 내용은 챕터 3인 환경에서 기술한다.)

소프트웨어와 상호작용하고 제어해야 할 실제 하드웨어 장치를 자세히 설명한다.(ex: 카메라 등)

많은 응용 프로그램에는 하드웨어 인터페이스가 없다.

위 경우 시스템에 하드웨어 인터페이스가 없다고 기술하면 된다.

Software Interface(소프트웨어 인터페이스)

소프트웨어 인터페이스에는 이 제품과 데이터베이스, 운영체제, 도구, 라이브러리 등과 같은 외부 소프트웨어 구성요소와의 인터페이스를 기술한다.

시스템으로 들어오는 데이터나 메세지의 목적 및 필요한 서비스와 커뮤니케이션 성격을 기술해야 한다.

외부 소프트웨어 구성요소와 공유할 데이터를 식별해야 한다.

외부 소프트웨어 구성요소를 정의할 때 아래와 같은 내용을 포함하여 정확히 식별한다.

• 구성요소 이름
• 사양 번호
• 버전 번호
• 출처

Communication Interface(통신 인터페이스)

통신 인터페이스에서 제품에 필요한 전자 우편, 웹 브라우저, 네트워크 서버 통신 프로토콜, 전자 양식 등 통신 기능과 관련된 요구사항을 기술한다.

사용자 정의 프로토콜을 사용해 시스템 간 통신하는 경우 설계자가 설계할 수 있도록 해당 프로토콜을 문서화해야 한다.

Performance Requirements(성능 요구사항)

성능 요구사항에선 프로젝트 목표 제품의 성능 요구사항을 기술한다.

시장의 요구 수준, 목표, 검증된 성능을 적기도 한다.

프로젝트 성격에 따라 기술할 요구사항이 다를 수 있다.

성능 요구사항은 비기능 요구사항 중 하나이며 모든 소프트웨어에서 중요하게 다루는 항목이기에 SRS에서도 별도로 성능 요구사항을 작성한다.

Throughput(작업 처리량)

작업 처리량에는 초당 작업 처리 속도를 의미한다.

작업 처리량을 표시할 때는 환경이 되는 표준 시스템이 필요하다.

챕터 3 환경에서 정의한 환경을 사용하여 작업 처리량을 표시한다.

Concurrent Session(동시 세션)

동시 세션에서는 동시에 얼마나 많은 세션을 연결해 처리할 수 있는지 기술한다.

시스템이나 컴포넌트 간 연결된 곳으로 동시 접속이 많다면 동시에 연결 가능한 세션의 수를 기록하는 것이 좋다.

Response Time(대응 시간)

대응 시간에서는 시스템이 얼마나 빨리 반응해야 하는지 기준을 정의한다.

사용자나 외부 시스템 각각의 요청에 시스템이 대응해야 하는 시간을 정리한다.

각 기능이나 요청에 따라 대응 시간이 다르기에 따로 정리해야 한다.

모든 기능이나 요청에 따른 대응 시간을 기록해야 하는 것은 아니다.

대응 시간이 특히 중요한 민감한 요청이나 기능에 대한 대응 시간을 정리하면 된다.

때로 요구되는 대응 시간에 따라 시스템 아키텍처가 완전히 바꿀 수 있기에 스펙에 잘 정의해야 한다.

Performance Dependency(성능 종속관계)

성능 종속관계에서는 트레이드으프 관계의 성능 요구사항을 기술해야 한다.

성능ㅇ이 다른 외부 환경의 영향을 받는다면 이 또한 기술해야 한다.

예시는 아래와 같다.

• 동시 세션이 5000개를 넘으면 대응 시간이 급격히 떨어진다.
• 동시 세션과 최대 작업 처리량은 반비례한다.

Other Performance Requirements(그 외 성능 요구사항)

소프트웨어 특성에 따라 앞에서 정의한 항목 외의 성능 요구사항이 존재할 수 있다.

그 외 성능 요구사항에서는 그러한 성능 요구사항들을 기술한다.

Functional Requirements(기능 요구사항)

기능 요구사항에서는 제품의 기능을 상세하게 분류해 설명한다.

각 기능에 고유한 Label(레이블)을 부여해 구분한다.

기능들을 계층 구조로 조직화해 적어나갈 수도, 유스케이스를 이용해 적을 수도, 기능 자체를 객체로 설명할 수도, 계층을 설명할 수도 있다.

Non-functional Requirements(비기능 요구사항)

SRS에서 기능 요구사항이 중요하나 비기능 요구사항 역시 중요하다.

여러 요구사항들을 분석하다 보면 개발자가 찾아내기도 한다.

소프트웨어 아키텍처에 많은 영향을 끼치므로 나중에 바꾸기 어렵기 때문에 SRS 작성 시 꼼꼼하게 비기능 요구사항을 찾아내고 작성해야 한다.

Safety(안정성 요구사항)

안정성 요구사항에서는 시스템 사용으로 발생할 수 있는 손실, 손해, 상해와 관련된 요구사항을 기술해야 한다.

제품의 정상적인 사용이나 비정상적인 종료로 발생하는 안전상의 요구사항들을 모두 설명해야 한다.

안정성 요구사항을 도출할 때 아래와 같은 관점으로 생각하는 것이 좋다.

• 정상 또는 비정상적인 시스템의 동작으로 사용자가 건강, 생명, 재산상의 피해를 입을 수 있는가?
• 정상 또는 비정상적인 시스템의 동작이 피해를 줄 확률이 얼마나 되는가?
• 어떠한 비정상적인 종료나 장애가 있을 수 있는가?
• 사용자의 실수로 손실이 발생할 수 있는가?
• 비정상적인 시스템 종료 시 피할 수 없는 피해는 무엇인가?

Security(보안 요구사항)

보안 요구사항은 제품에서 사용하거나 작성된 데이터의 보호와 관련된 보안 요구사항이나 개인 정보 보호와 관련된 요구 사항을 기술한다.

아래와 같은 사항을 포함한다.

• 특정 암호화 기술 사용
• 특정 로그 또는 기록된 데이터 유지
• 특정 기능을 다른 모듈에 할당
• 프로그램의 일부 영역 간 통신 제한
• 중요한 데이터에 대한 무결성 검사
• 사용자 인증 요구사항
• 제품에 영향을 미치는 외부 정책 및 규정
• 보안, 개인 정보 보호 인증

일반적으로 보안 요구사항을 분석할 때 아래 항목을 점검한다.

• Authentication(인증)
• Authorization(권한 부여)
• Access control(접근 제어)
• Non repudiation(부인 방지)
• Confidentiality(기밀 유지)
• Integrity(무결성)
• Secure coding(보안 코딩)
• Web vulnerabilites(웹 취약점)

System Attributes(소프트웨어 시스템 특성)

소프트웨어 시스템 특성은 여러 가지 존재하며 대표적인 것이 SRS 템플릿에 포함된다.

소프트웨어 종류에 따라 틀별히 요구되는 시스템 특성이 있다면 추가로 기술한다.

• Availability(가용성)
  • 시스템이 가동되는 정도를 나타내는 특성을 말한다.
  • 가동과 가동 중단의 비율을 수치로 나타내거나 서술식으로 표현할 수 있다.
  • 가용성은 신뢰성과도 연관이 있다.
• Maintainability(유지보수성)
  • 소프트웨어 자체를 얼마나 쉽게 유지보수할 수 있어야 하는지 그 정도를 나타내는 요구사항이다.
  • 프로젝트 상황이나 향후 유지보수 계획에 따라 유지보수가 얼마나 용이해야 하는지 결정해야 한다.
• Portability(이식성)
  • 소프트웨어를 다른 종류의 시스템이나 운영체제로 이식하는 것과 관련된 요구사항을 기술한다.
    • 호스트 종속된 컴포넌트 비율
    • 호스트 종속된 코드 비율
    • 이식 용이한 개발 언어 사용
    • 특정 컴파일러 사용
    • 특정 운영체제 사용
    • 특정 CPU 사용
• Reliability(신뢰성)
  • 소프트웨어가 확보해야 할 신뢰성 요구사항을 기술한다.
  • MTBF 요구사항이 있다면 이 부분에 기록한다.
• Remaining Attributes(나머지 특성)
  • 시스템마다 필요한 특성이 달라 템플릿에 모든 시스템 특성이 기술되지 않는다.
  • 각 소프트웨어에 따라 필요한 특성을 여기에 별도로 기술한다.
    • Correctness(정확성): 프로그램이 스펙을 충족하고 사용자의 목표를 달성하는 정도
    • Efficiency(효율성): 기능을 수행하는 데 필요한 컴퓨팅 자원 및 코드의 양
    • Scalability(확장성): 소프트웨어의 지원 규모를 확장하기 용이한 정도
    • Flexibility(연동성): 타 시스템과 연동하는 데 필요한 노력의 정도
    • Reusability(재사용성): 다른 소프트웨어에서 재사용하는 데 필요한 노력의 정도
    • Testability(테스트성): 의도한 대로 테스트를 수행하는 데 필요한 노력의 정도
    • Usability(사용성): 사용자가 시스템을 사용하기 위해 필요한 교육, 운영, 준비 등의 정도

Logical Database Requirements(데이터베이스 요구사항)

데이터베이스 요구사항은 데이터베이스에 관한 논리적인 요구사항을 작성한다.

아래의 내용이 포함된다.

• 다양한 기능에서 사용되는 정보의 유형
• 정보의 사용 빈도
• 정보 접근 용량
• 데이터의 엔티티와 그 관계
• 무결성 요구사항
• 데이터 보존 요구사항

고객이 데이터 모델을 제시한 경우 여기에 기술한다.

ER 다이어그램은 복잡한 데이터 관계를 나타내는 데 매우 유용한 툴이다.

SRS에 추가하는 것이 좋다.

Business Rules(비즈니스 규칙)

비즈니스 규칙에서는 제품이 따라야 할 원칙을 나열한다.

지켜야 할 정부 법규나 산업 표준, 내사 규칙, 지켜야 할 알고리즘 등이 해당된다.

Design and Implementation Constraints(설계와 구현 제한사항)

설계와 구현 제한사항에서는 표준이나 하드웨어 제한 등으로 영향을 받을 수 있는 설계상의 제약 조건을 지정한다.

• Standards Compliance(표준 준수)
  • 프로젝트에서 지켜야 할 기준의 표준이나 구정에서 파생되는 요구사항을 기술한다.
    • 보고서의 형식
    • 데이터의 이름 명명 규칙
    • 회계 절차
    • 감사 추적
• Other Constraints(기타 제한사항)
  • 개발자가 설계나 구현 시 사용할 수 있는 옵션을 제한하는 내용을 기술한다.
    • 사용해야 하거나 피해야 할 기술, 설계 툴, 개발 툴, 개발 언어, 데이터베이스 등이 있으면 기술한다.
    • 준수해야 할 개발 규칙(프로그래밍 가이드, 에러 코드, 빌드 버전 등)이나 표준(표준명 및 버전) 등이 있으면 기술한다.
    • 하드웨어나 운영 환경 상 제약 조건은 챕터 3 환경에 기술한다.

Memory Constraints(메모리 제한사항)

메모리 제한사항에는 메모리에 적용 가능한 특성 및 제한사항을 정의한다.

물리적으로 메모리의 제약이 큰 시스템의 스펙을 적을 때 매우 신중해야 한다.

일반 PC에서 동작하는 소프트웨어라 하더라도 대량의 메모리를 사용해야 한다면 메모리 제한사항을 잘 정의해야 한다.

특별한 메모리 제한사항이 없다면 없다는 것을 명시해야 한다.

Operations(운영 요구사항)

운영 요구사항에는 시스템을 운영하기 위해 사용자가 해야 할 일반 및 특수 작업을 기술한다.

운영 요구사항에는 아래와 같은 것들이 있다.

• 대화형으로 시스템에서 운영해야 할 것
• 무인 작업해야 할 것
• 데이터 처리와 관련된 내용
• 백업 및 복구 작업

Site Adaptation Requirements(사이트 적용 요구사항)

사이트 적용 요구사항의 경우 시스템을 사이트에 적용하기 위해 필요한 요구사항을 기술한다.

고객의 작업 영역을 수정해야 한다면 이 곳에 기술한다.

고객이 구매해야 하는 장비나 시스템이 바르게 설치되어 작동하도록 하기 위해 수행해야 하는 소프트웨어 설정은 여기 기술된다.

Internationalization Requirements(다국어 지원 요구사항)

다국어 지원 요구사항에서는 소프트웨어 국제화 요구사항을 기술한다.

소프트웨어 국제화를 이해하기 위하여 아래 세 용어를 반드시 알아야 한다.

• Locale
  • 전 세계적으로 언어, 숫자, 화폐 등 여러가지가 달라 국제화를 언어로만 구분하지 않는다.
• i18n[아이에잇틴엔]
  • Internationalization의 약자이다.
  • 소프트웨어가 여러 로케일을 지원할 수 있도록 아키텍처를 만드는 것을 의미한다.
• L10n[엘텐엔]
  • Localization의 약자이다.
  • 소프트웨어에서 특정 로케일이 지원되도록 하는 것이다.

소프트웨어 국제화는 기본적으로 여섯 가지 카테고리를 지원하는 것이 표준이다.

거의 모든 운영체제와 프레임워크가 여섯 가지 카테고리의 국제화를 지원하므로 이것을 잘 사용하면 된다.

국제화 표준의 여섯 가지 카테고리는 아래와 같다.

• LC_MESSAGES: 메세지, 화면에 출력되는 문자열
• LC_CTYPE: 대소문자 구분
• LC_NUMERIC: 숫자 표기
• LC_TIME: 날짜, 시간 표기
• LC_COLLATE: 문자열 정렬
• LC_MONETARY: 화폐 표기

비표준 국제화 카테고리 중 일부는 아래와 같다.

• 이름 표기
• 전화번호
• 아이콘
• 키보드 배열
• 주소
• 색상의 의미
• 소리
• ...

소프트웨어가 어떤 국제화를 지원해야 하는지는 소프트웨어 특성에 따라 결정해야 한다.

소프트웨어 국제화는 초기 버전에서 지원하지 않았을 때, 나중에 추가로 지원하기 위한 공수가 크다.

Number	Item	Description
1	언어 구분	한 나라에서 사용하는 언어가 여러 개이기도 하고, 한 언어가 여러 나라에서 서로 다르게 쓰이기도 한다.
2	지역 구분	지역과 국가가 완전히 일치하지는 않는다.언어와 지역 정보가 합쳐져야 로케일이 된다.소프트웨어는 로케일 단위로 지역화한다.
3
4
5	...	...

Unicode Support(유니코드 지원)

유니코드 지원은 글자가 깨지는 문제를 없애기 위해 고려되어야 한다.

소프트웨어의 유니코드 지원은 아래와 같은 여러 의미를 지닌다.

• 소프트웨어 내부에서 유니코드 문자열을 사용한다.
• 파일을 저장할 때 유니코드로 저장한다.
• 타 시스템과 통신할 때 유니코드 문자열을 주고받는다.

64bit Support(64비트 지원)

현재 PC 시스템의 대부분은 64bit로 이루어져 있으나 Windows의 경우 아직 32bit과 64bit으로 나뉜다.

요구사항에 따라 64bit만을 지원하거나 32bit과 64bit 모두를 지원해야 할 필요가 있다.

Certification(제품 인증)

제품인증에서는 프로젝트 산출물이 외부 인증을 받아야 하는지, 그렇지 않다면 어떤 인증을 어떤 방법으로 진행하여 무엇을 준비하고 비용은 얼마나 드는지를 기술해야 한다.

마케팅팀, 인증팀과의 협의가 필요한 내용이다.

인증은 아래와 같은 것들이 있다.

• MS Logo 인증
• Good Software 인증
• CC(국제공통평가기준)
• FDA 인증
• CE 인증

Change Management Process(변경 관리 프로세스)

변경 관리 프로세스는 필수 챕터는 아니나 회사에 따라 변경 관리 프로세스를 SRS에 기술할 수 있다.

Document Approvals(최종 승인자)

최종 승인자는 SRS 문서가 최종 확정됐음을 확인하기 위해 이해관계자의 대표자들에게 서명 받는 것이다.