컴퓨터과학/프로젝트 관리

소프트웨어 요구 사항 명세서 SRS (Software Requirements Statement) 작성

InfHo 2023. 4. 5. 16:38

목차

     

    소프트웨어 개발자 또는 프로젝트 관리자라면 "SRS" 또는 "소프트웨어 요구 사항 명세서"라는 용어를 들어본 적이 있을 것입니다. 이것은 소프트웨어 프로젝트의 특징과 기능을 개략적으로 설명하는 중요한 문서이며, 개발 팀이 따라야 할 청사진의 역할을 합니다.

     

    SRS

    SRS(Software Requirements Statement)소프트웨어 프로젝트의 기능 및 비기능 요구사항을 요약한 문서입니다. 개발자, 설계자, 이해관계자가 따라야 할 로드맵 역할을 하며 프로젝트의 범위와 목표에 관한 한 모든 사람이 동일한 입장에 있도록 돕는다.

     

    SRS가 중요한 이유는 무엇입니까?

    • 프로젝트에 관련된 모든 사람들이 같은 생각을 하고 있는지 확인하는 데 도움이 됩니다. SRS는 소프트웨어의 특징과 기능을 명확하게 설명함으로써 지연, 비용 초과 및 기타 문제로 이어질 수 있는 오해와 오해를 방지합니다.
    • SRS는 소프트웨어가 사용자의 요구를 충족하도록 보장합니다. SRS는 요구 사항을 명확하게 정의함으로써 소프트웨어가 기능적이고 사용하기 쉬우며 대상 고객의 요구 사항을 충족할 수 있도록 지원합니다.
    • SRS는 소프트웨어가 제시간에 예산에 맞게 개발되도록 보장합니다. 개발자와 프로젝트 관리자는 요구사항을 사전에 요약함으로써 현실적인 개발 계획과 예산을 수립하고 비용이 많이 드는 범위의 변경이나 프로젝트 중간 개발을 방지할 수 있습니다.

     

    SRS를 작성하는 방법

    1. 명확한 범위 설명으로 시작합니다.
      범위 설명은 소프트웨어의 목적, 의도된 대상 및 제한이나 제약 조건을 개략적으로 설명해야 합니다.

    2. 기능 요구사항을 정의합니다.
      이 절에서는 소프트웨어의 특징과 기능 및 사용자가 소프트웨어와 상호 작용하는 방법을 개략적으로 설명해야 한다.

    3. 비기능적 요구사항을 정의합니다.
      이 섹션에서는 응답 시간, 확장성 또는 보안과 같은 기술 또는 성능 요구사항을 개략적으로 설명해야 합니다.

    4. 설계 또는 사용적합성 요건을 포함한다.
      이 섹션은 브랜딩, 사용자 인터페이스 또는 접근성과 같은 특정 설계나 사용적합성 요건을 개략적으로 설명해야 한다.

    5. 모든 테스트 또는 품질 보증 요구사항을 포함합니다.
      이 섹션에서는 SRS에 설명된 요구 사항을 충족하는지 확인하기 위해 소프트웨어를 테스트 및 검증하는 방법을 개략적으로 설명해야 합니다.

    6. 피드백 및 수정사항을 확인합니다.
      SRS를 작성했으면 이해 관계자, 개발자 및 다른 팀원들로부터 피드백을 받아야 합니다. SRS가 프로젝트의 목표와 범위를 정확하게 반영할 수 있도록 필요에 따라 수정합니다.

     

    SRS 목차

    SRS_문서_목차_예시
    SRS 문서 목차 예시

     

    1. 소개

    1.1 목적

    1.2 범위

    1.3 정의, 약어 및 약어

    1.4 참조

    1.5 SRS 개요

     

    2. 전체 설명

    2.1 제품 관점

    2.2 제품 기능

    2.3 사용자 특성

    2.4 구속조건

    2.5 가정 및 종속성

     

    3. 특정 요구사항

    3.1 외부 인터페이스 요구사항

    3.1.1 사용자 인터페이스

    3.1.2 하드웨어 인터페이스

    3.1.3 소프트웨어 인터페이스

    3.1.4 통신 인터페이스

    3.2 기능 요구사항

    3.3 성능 요구사항

    3.4 설계 구속조건

    3.5 소프트웨어 시스템 속성

    3.5.1 신뢰성

    3.5.2 가용성

    3.5.3 보안

    3.5.4 유지관리성

    3.5.5 휴대성

     

    4. 부록

    4.1 용어집

    4.2 사용 사례

    4.3 추가 요구사항

     

    SRS에 포함되어야 할 모델링 산출물

    • 유즈케이스 다이어그램: 이 다이어그램은 시스템 사용자와 시스템 자체 간의 상호 작용을 보여줍니다. 시스템의 기능 및 기능에 대한 요구 사항을 식별하는 데 도움이 됩니다.
    • 도면요소-관계(ER) 다이어그램: 이 다이어그램은 사용자, 데이터 및 프로세스와 같은 시스템의 서로 다른 엔티티 간의 관계를 보여줍니다. 시스템에 대한 데이터 요구 사항을 파악하는 데 도움이 됩니다.
    • 시퀀스 다이어그램: 이 다이어그램은 시스템의 여러 구성 요소 간의 상호 작용 순서를 보여 줍니다. 시스템 동작 및 성능에 대한 요구 사항을 파악하는 데 도움이 됩니다.
    • 상태 다이어그램: 이 다이어그램은 시스템이 있을 수 있는 다양한 상태와 이러한 상태 간의 전환을 보여줍니다. 시스템 동작 및 기능에 대한 요구 사항을 식별하는 데 도움이 됩니다.
    • 클래스 다이어그램: 이 다이어그램은 시스템 개체의 클래스, 속성 및 메서드를 보여 줍니다. 시스템의 데이터 및 기능에 대한 요구 사항을 식별하는 데 도움이 됩니다.
    • 데이터 흐름 다이어그램: 이 다이어그램은 시스템을 통한 데이터 흐름을 보여줍니다. 시스템의 데이터 처리 및 저장에 대한 요구 사항을 파악하는 데 도움이 됩니다.
    • 사용자 인터페이스(UI) 목업: 이러한 모형은 시스템 사용자 인터페이스의 시각적 설계 및 레이아웃을 보여줍니다. 시스템의 사용성 및 접근성에 대한 요구사항을 식별하는 데 도움이 됩니다.

     

    SRS에 포함되어야 할 내용 예시

    1. 소개

    이 SRS(소프트웨어 요구 사항 설명서) 문서는 소프트웨어 시스템을 개발하기 위한 요구 사항 및 사양을 정의하는 것을 목표로 합니다. 소프트웨어 시스템은 고객의 요구를 충족시키기 위해 사용될 것입니다.

     

    2. 목적

    소프트웨어 시스템의 목적은 고객의 데이터와 정보를 관리 및 구성하고 데이터 관리 프로세스를 단순화하기 위한 플랫폼을 제공하는 것입니다.

     

    3. 시스템 기능

    - 사용자 등록 및 인증

    - 사용자 프로필 관리

    - 데이터 및 정보 관리

    - 검색 및 필터링 옵션

    - 대시보드 및 보고서

    - 알림

     

    4. 기능 요구사항

    - 소프트웨어 시스템은 사용자가 등록하고 인증할 수 있도록 해야 합니다.

    - 소프트웨어 시스템은 사용자가 프로필을 관리할 수 있도록 해야 합니다.

    - 소프트웨어 시스템은 사용자가 데이터와 정보를 저장, 검색 및 관리할 수 있도록 해야 합니다.

    - 소프트웨어 시스템은 사용자가 특정 데이터와 정보를 찾을 수 있도록 검색 및 필터 옵션을 제공해야 합니다.

    - 소프트웨어 시스템은 데이터와 정보를 시각화할 수 있는 대시보드와 보고서를 제공해야 합니다.

    - 소프트웨어 시스템은 사용자에게 알림 및 경고를 제공해야 합니다.

     

    5. 비기능 요구사항

    - 소프트웨어 시스템은 안전해야 합니다.

    - 소프트웨어 시스템은 확장 가능해야 합니다.

    - 소프트웨어 시스템은 대응력이 뛰어나고 빨라야 합니다.

    - 소프트웨어 시스템은 데이터 관리 및 보안의 국제 표준을 따라야 합니다.

     

    6. 사용자 인터페이스 설계

    소프트웨어 시스템의 사용자 인터페이스 설계는 사용자 친화적이고 직관적이어야 합니다. 고객에게 쾌적한 사용자 경험을 제공하도록 설계되어야 합니다. 사용자 인터페이스 설계는 최신 설계 트렌드를 따라야 합니다

     

    비기능적 요구 사항이 포함되어야 하는가?

     

    SRS_구현시_고려사항
    SRS 구현 시 고려사항

     

    'CBD SW개발 표준 산출물 관리 가이드' 의 SRS 구현 시 고려사항에는 비기능적 요구사항이 유즈케이스와 관련이 되면 기술하는 것으로 명시되어 있다. 하지만, 비기능적 요구 사항은 품질에 대한 요구사항을 나타내어, 개발 과정에서 이해관계자들이 참고할 수 있는 기술 문서이기 때문에, 비기능적 요구사항이 SRS에 포함되는 것이 원칙이다.

     

    UML의 V프로세스

    uml_v_프로세스
    UML의 V프로세스 순서

     

    UML의 V프로세스는 기능 모델링, 동적 모델링, 정보 모델링 순으로 시작해 역순으로 마감하는 프로젝트 분석 순서를 제공해 주는 프로세스입니다.

     

    SRS(소프트웨어 요구 사항 명세서)를 작성할 때 UML의 V 프로세스를 적용하면 다양한 유형의 출력이 생성됩니다. 이러한 출력은 소프트웨어 시스템의 요구사항과 설계를 문서화하고 전달하는 데 도움이 됩니다.

     

    UML V 프로세스 분석 산출물

    • 유즈케이스 다이어그램: 이러한 다이어그램은 소프트웨어 시스템의 다양한 사용 사례 또는 시나리오를 보여줍니다. 시스템의 기능과 사용자가 시스템과 상호 작용하는 방식을 정의하는 데 도움이 됩니다.
    • 액티비티 다이어그램: 이러한 다이어그램은 소프트웨어 시스템 내의 활동 또는 프로세스의 흐름을 보여줍니다. 특정 작업 또는 프로세스를 완료하는 데 관련된 단계를 식별하는 데 도움이 됩니다.
    • 클래스 다이어그램: 이러한 다이어그램은 소프트웨어 시스템의 클래스, 개체 및 관련 관계를 보여줍니다. 시스템 개체의 구조와 동작을 정의하는 데 도움이 됩니다.
    • 시퀀스 다이어그램: 이 다이어그램은 특정 시나리오에서 개체 간의 상호 작용을 보여줍니다. 그들은 정보의 흐름과 객체 간의 제어를 설명하는 데 도움이 됩니다.
    • 구성 요소 다이어그램: 이러한 다이어그램은 소프트웨어 시스템의 물리적 구성 요소와 이러한 구성 요소가 서로 상호 작용하는 방식을 보여줍니다. 시스템 아키텍처를 정의하는 데 도움이 됩니다.
    • 배포 다이어그램: 이러한 다이어그램은 소프트웨어 시스템 구성요소의 물리적 배치 및 상호 연결 방법을 보여줍니다. 시스템의 배포 환경을 정의하는 데 도움이 됩니다.

     

    전반적으로 SRS(소프트웨어 요구 사항 명세서)를 작성할 때 UML의 V 프로세스를 적용하여 생성된 출력은 소프트웨어 시스템의 요구 사항과 설계를 포괄적이고 시각적으로 표현합니다. 이를 통해 모든 이해 관계자가 시스템의 기능, 동작 및 아키텍처를 명확하게 이해할 수 있습니다.

     

    분석 산출물 관계

    분석_산출물의_관계
    분석 산출물의 관계

     

    유즈케이스 다이어그램은 여러 개의 유즈케이스 시나리오를 포함합니다.

    유즈케이스 다이어그램은 하나의 클래스 다이어그램을 포함합니다.

    유즈케이스 시나리오는 각각 하나의 시퀀스 다이어그램을 포함합니다.

    유즈케이스 시나리오 중, 액티비티 다이어그램이 필요한 경우 하나를 포함할 수 있습니다.

     

    "SRS목차" 부분의 'SRS 목차 예시' 사진을 보았을 때, 단어장 서비스가 유즈케이스 다이어그램 (상위 기능) 이 될 수 있습니다. 단어장 서비스가 유즈케이스 다이어그램이 되는 경우, 유즈케이스 시나리오는 '단어장 조회', '단어장 수정' 등의 하위 기능이 될 수 있습니다.