요구사항 명세서(SRS)

1. 요구사항 명세서란?(What is SRS)

A Software Requirements Specification is a detailed document that outlines the objectives, functionalities, constraints, and expectations of a system, software, or project. It serves as a foundational reference for all stakeholders—clients, developers, designers, and testers—ensuring everyone has a shared understanding of what the project will deliver.
(요구 사항 사양은 시스템, 소프트웨어 또는 프로젝트의 목표, 기능, 제약 및 기대 사항을 개략적으로 설명하는 자세한 문서입니다. 이는 모든 이해 관계자(클라이언트, 개발자, 설계자 및 테스터)에게 기초적인 참조 자료 역할을 하며, 모든 사람이 프로젝트에서 제공할 내용에 대한 공통된 이해를 갖도록 보장합니다.)

2. 요구사항 명세서는 대충 작성해도 될까?

• 요구사항 명세서는 개발팀, 디자이너, 테스트팀, 고객 등 모든 이해관계자 간의 커뮤니케이션 도구 역할을 한다.
• 요구사항이 명확하지 않으면 개발 도중 빈번한 수정과 재작업이 필요할 수 있다. 즉, 비용과 시간을 낭비할 수 있다.
• 요구사항이 명확하지 않으면 팀원들 간의 의견 충돌이 발생할 가능성이 높아진다.
• 명확한 요구사항은 시스템을 빠르게 이해하고 수정하여 유지보수성을 높인다.
• 요구사항 명세서는 기능이 무엇인지에 대한 것 외에 기능이 얼마정도의 품질을 가지느냐도 논해야 한다. 이는 품질을 보장하도록 한다.

3. 요구사항 명세서 구성요소

IEEE에 따르면 중요한 구성요소로는 다음과 같은 것들이 있다.

1. Introduction(개요)
   • Purpose(목적), Scope(범위)
2. Overall Description(전체 설명)
   • System Context (시스템 환경), User Needs (사용자 요구사항), Constraints (제약조건)
3. Specific Requirements(구체적인 요구사항)
   • Functional Requirements(기능 요구사항), Non-Functional Requirements (비기능 요구사항)

4. Introduction (소개)

• Purpose:
  • 요구사항 문서의 목적을 명확히 설명합니다.
  • 예: 이 문서는 프로젝트의 모든 기능 및 비기능 요구사항을 정의합니다.
• Scope:
  • 시스템 또는 프로젝트의 범위를 설명합니다.
  • 예: 이 시스템은 전자 상거래 플랫폼으로, 상품 검색, 구매, 결제 기능을 제공합니다.

5. Overall Description (전체 설명)

• System Context (시스템 환경):
  • 시스템이 운영될 환경을 설명합니다(예: 하드웨어, 네트워크, 사용자).
• User Needs (사용자 요구사항):
  • 주요 이해관계자와 사용자 그룹의 요구사항.
  • 예: 사용자는 간단한 UI를 통해 10초 이내에 회원가입을 할 수 있어야 한다.
• Constraints (제약조건):
  • 프로젝트 또는 시스템 설계의 기술적/법적/운영적 제약.
  • 예: 시스템은 GDPR을 준수해야 한다. (개인정보 보호 법률임)

6. Specific Requirements (구체적인 요구사항)

이 섹션은 요구사항 명세서의 핵심으로, 기능 요구사항과 비기능 요구사항을 상세히 작성해야 합니다.

• Functional Requirements (기능 요구사항):
  • 시스템이 제공해야 할 기능을 구체적이고 측정 가능하게 설명합니다.
  • 예
    • FR-001: 사용자는 이메일과 비밀번호를 입력하여 계정에 로그인할 수 있어야 한다.
    • FR-002: 사용자는 장바구니에 상품을 추가하거나 삭제할 수 있어야 한다.
• Non-Functional Requirements (비기능 요구사항):
  • 성능, 보안, 유지보수성 등과 관련된 요구사항.
  • 예
    • NFR-001: 시스템은 평균 응답 시간을 2초 이하로 유지해야 한다.
    • NFR-002: 시스템은 동시 접속자 10만 명 이상을 지원할 수 있어야 한다.

7. 좋은 요구사항 명세서를 작성하기 위해 고려해야 할 점

1. 현실성 : 비현실적인 요구사항을 조심

• 예산, 인력, 일정에 맞지 않는 요구사항을 포함하면 프로젝트가 실패할 가능성이 커짐.
• 적당히 좋은 결과를 위한 현실적인 요구사항을 정의해야 함.
• 모든 가능성을 요구사항에 포함하려 하지 말고,
  실제로 필요한 요구사항과 나중에 추가될 수 있는 요구사항을 구분해야 함.

1. 다양한 의견 수용

• 혼자 생각하고 혼자 결론을 내린 아이디어는 부족할 가능성이 높음.
• 아이디어를 모두에게 공유해야 함.

1. 명확성 : 모호함을 피한다.

• 요구사항을 추상적으로 작성하면 개발팀과 이해관계자가 서로 다른 해석을 내릴 수 있음.
  모든 요구사항은 구체적이고 명확해야 함.
• 예: 시스템은 빠르게 동작해야 한다 >>> 시스템은 요청 응답 시간을 1초 이내로 유지해야 한다.

1. 일관성 : 모순과 중복을 피한다.

• 요구사항은 서로 모순되거나 중복되지 않아야 한다.
• 표현방식이나 용어를 일관되게 사용해야 한다.

1. 필요성 : 필요해야 한다.
2. 검증 가능성 : 측정할 수 있어야 한다.

• 측정 가능하거나 관찰 가능한 기준을 제시해야 한다.

1. 추적 가능성 : 추적 가능해야 한다.

8. 요구사항 정의서 예시

한국에서 작성하는 요구사항 정의서의 예시이다. 이 방식도 나쁘지는 않다. 표로 작성하여 모든 기능이 한 눈에 들어온다.

https://i-ten.tistory.com/96

https://brunch.co.kr/@applehong/63

보통 우리는 요구사항 정의서! 라고 하면 저런 표가 떠오른다.

하지만 한국 밖에서는 저런 표를 요구사항 정의서라고 하지 않는다.

해외에서는 요구사항 정의서는 보통 서술형 문서로 작성하고,

이런 방식의 표는 FRD(Functional Requirements Table)이라고 한다.

그리고 표로 기능 요구사항을 작성하는 방식보다는 유스케이스를 사용하고, 전문 도구(Confluence, IBM DOORS,JIRA, Trello) 를 사용해서 정리한다고 한다.

왜 그럴까?

표 방식은 요구사항이 변경될 때마다 문서를 수동으로 업데이트 해야 한다. 비용적으로도 안좋고, 실수하기도 매우 쉽다. 점점 표를 신뢰하지 못하게 된다

9. Waterfall vs agile

Waterfall(워터폴)과 Agile(애자일)은 소프트웨어 개발 방법론의 대표적인 두 가지 접근 방식이다. 두 방법론이 서로 경쟁 관계는 아니다. 위에서 보았던 저런 표 방식은 워터폴 방식에 매우 적합한 방식이라고 볼 수 있다. 워터폴은 순차적으로 진행되고 에자일은 순차적이지 않고 동시에 진행된다.

특징	Waterfall	Agile
프로세스 구조	선형적, 순차적 (계획 > 설계 > 구현 > 테스트 > 배포)	반복적, 점진적 (작은 주기 반복: 계획, 설계, 구현, 테스트를 짧은 스프린트 내에서 반복)
단계 간 이동	다음 단계로 넘어가기 전에 이전 단계를 완료해야 함	단계 간 이동과 피드백을 허용하며, 반복적으로 요구사항과 결과를 개선
요구사항 정의	초기에 모든 요구사항을 상세히 정의하고, 개발 과정 중 변경을 최소화.	요구사항이 점진적으로 추가/변경되며, 피드백을 통해 진화적 요구사항을 수용
팀 구조	단계별로 팀 역할이 고정적(예: 기획팀 → 개발팀 → 테스트팀)	크로스 펑셔널 팀(다양한 직무의 팀원이 하나의 팀에서 협업)
커뮤니케이션	문서 중심의 커뮤니케이션(요구사항 명세서, 설계 문서 등)	지속적이고 비공식적인 대화와 회의를 중심으로 협업
적용 사례	대규모, 복잡한 프로젝트: 예: 정부 프로젝트, 건설, 규제가 많은 산업(의료, 항공 등)	변화가 많은 프로젝트: 예: 소프트웨어 개발, 스타트업 제품 개발.
문서 유지보수	문서 변경이 어렵고, 최신 상태를 유지하는데에 높은 비용이 듬	문서의 간소화로 인해 유지보수 부담이 적음

10. Agile

💡Agile Manifesto

https://agilemanifesto.org/

Agile Maifesto라는 유명한 선언문이 있다.

• Individuals and interactions over processes and tools (개인과 상호작용 > 프로세스와 도구)
• Working software over comprehensive documentation (작동하는 소프트웨어 > 포괄적인 문서화)
• Customer collaboration over contract negotiation (고객과의 협력 > 계약 협상)
• Responding to change over following a plan (변화에 대한 대응 > 계획 준수)

💡Agile 12 Principles

 

1. 고객 만족

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.""우리의 최우선 순위는 가치 있는 소프트웨어를 초기에 그리고 지속적으로 제공함으로써 고객을 만족시키는 것이다."

• 고객에게 지속적으로 동작 가능한 소프트웨어를 제공하여 가치를 전달함.

2. 변화 수용

"Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.""개발 후반부라도 변화하는 요구사항을 환영한다. 애자일 프로세스는 고객의 경쟁 우위를 위해 변화를 활용한다."

• 변화하는 요구사항을 프로젝트의 일부로 받아들이고, 이를 활용해 더 나은 결과를 제공함.

3. 자주 동작 가능한 소프트웨어 제공

"Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.""작동하는 소프트웨어를 자주 제공한다. 주 단위에서 몇 달 단위까지, 가능한 짧은 주기를 선호한다."

• 짧은 주기로 결과물을 제공하여 빠르게 피드백을 받을 수 있음.

4. 비즈니스와 개발 간 협력

"Business people and developers must work together daily throughout the project.""비즈니스 담당자와 개발자는 프로젝트 전반에 걸쳐 매일 협력해야 한다."

• 비즈니스와 개발팀 간 긴밀한 협업을 통해 요구사항을 명확히 이해하고 신속히 대응함.

5. 동기부여된 개인 중심

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.""동기부여된 개인을 중심으로 프로젝트를 구축하라. 필요한 환경과 지원을 제공하고, 그들이 맡은 일을 신뢰하라."

• 팀원들에게 자율성과 책임을 부여하여 동기를 높이고 생산성을 증대시킴.

6. 효과적인 커뮤니케이션

"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.""정보 전달의 가장 효율적이고 효과적인 방법은 대면 대화이다."

• 문서보다 직접적인 대화로 정보 전달을 명확히 하고, 오해를 줄임.

7. 작동하는 소프트웨어

"Working software is the primary measure of progress.""작동하는 소프트웨어가 진척을 측정하는 주요 척도이다."

• 소프트웨어가 실제로 동작하는지를 기준으로 프로젝트의 성공 여부를 판단함.

8. 지속 가능한 개발

"Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.""애자일 프로세스는 지속 가능한 개발을 촉진한다. 후원자, 개발자, 사용자 모두 일정한 속도를 계속 유지할 수 있어야 한다."

• 팀이 장기적으로 일정한 작업 속도를 유지할 수 있도록 함.

9. 기술적 우수성과 설계

"Continuous attention to technical excellence and good design enhances agility.""기술적 우수성과 좋은 설계에 지속적으로 주의를 기울이면 애자일이 강화된다."

• 코드 품질과 설계를 지속적으로 개선하여 유지보수성과 유연성을 높임.

10. 단순성

"Simplicity—the art of maximizing the amount of work not done—is essential.""단순성, 즉 하지 않을 작업을 극대화하는 기술이 필수적이다."

• 불필요한 작업을 줄이고 핵심 목표에 집중하여 효율성을 극대화함.

11. 자율적인 팀

"The best architectures, requirements, and designs emerge from self-organizing teams.""최고의 아키텍처, 요구사항, 설계는 자율적으로 조직된 팀에서 나온다."

• 팀에게 권한을 부여하여 자율적으로 최선의 결정을 내릴 수 있도록 함

12. 정기적인 회고

"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.""팀은 정기적으로 더 효과적으로 일할 방법을 돌아보고, 그에 따라 행동을 조정한다."

• 회고를 통해 프로세스를 개선하고 팀의 생산성을 향상시킴.