KTY repository

요구사항의 개발과 관리

•
  • legacy
 •
  • 요구사항
  • 요구사항-중요성
  • 요구사항-개발
  • 요구사항-관리
  • 김희영

5.1 요구사항(requirements)란?

고객이나 사용자는 소프트웨어가 왜 필요한지에 대한 답을 제시, 그 결과 정리한 것.

개발방법론 표준에 입각하여 요구사항정의 일반적

요구사항명세서(SRS)

IEEE, “문제의 해결 또는 목적을 달성하기 위하여 요구되거나, 표준이나 명세 등을 만족하기 위하여 시스템이나 시스템 컴포넌트(즉, 소프트웨어)가 가져야 하는 조건 또는 역량”
“A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document”
한국정보통신기술협회, 계약, 표준, 명세 또는 달느 형식으로 제시된 문서에 맞추어 시스템이나 시슽메 구성 요소가 갖추어야할 조건이나 능력

  • 명시적(explicit) 요구사항: 고객이나 사용자가 공식적으로 요구한 소프트웨어 기능과 품질을 만족하기 위한 조건이나 기능
  • 묵시적(implicit) 요구사항: 고객이 요구하지 않았더라도 소프트웨어가 당연히 제공되어야 한다고 일반적으로 가능되는 사항들.

5.2 요구사항의 중요성

뭘개발해야되는지 모른다. 모르는데 개발하고있다. 프로젝트의 실패

시스템분석가는 요구사항을 정의하고 문서로 만들어야한다.

  • 기능적 요구사항(Functional Requirements): 수행될 기능과 관련되어 입력과 출력 및 그들 사이의 처리과정과 피드백 등의 기능(ex) 파일저장, 문서편집, 인쇄 등)
  • 비기능적 요구사항(Non-Functional Requirements): 제품의 비기능적 품질기준 등을 만족시키기 위해 소프트웨어가 가져야하는 성능, 사용 편의성, 안정성과 같은 특성을 파악한 요구사항(ex) 성능(응답시간, 처리량), 사용 용이성, 신뢰도, 이식성, 유지보수성, 보안성, 운용상 제약 등)

  • 국제표준 ISO/IEC 9126, 소프트웨어 품질특성 분류

    분류 == 내용
    기능적 품질특성 기능성(Functionality) 요구사항에 적합한 기능을 발휘함.
    비기능적 품질특성 신뢰성(Reliability) 명시된 조건과 기간 동안 일정 수준 이상의 성능을 유지함.
    || 사용성(Usablility) 사용자 입장에서 시스템 사용의 편리함 여부
    || 효율성(Efficiency) 개발된 소프트웨어 사용시 조직이나 기업에 미치는 효과와 효율
    || 유지보수성(Maintainability) 운영시 시스템 보완이나 유지의 편리함 정도
    || 이식성(Portability) 타 시스템 또는 플랫폼에 손쉽게 이식 가능 여부

5.3 요구사항 개발과 관리 프로세스

요구사항 개발 관리는 베이스라인을 중심으로 프로세스 나눠짐.

  • 요구사항 개발: “고객이나 사용자로부터 개발될 소프트웨어의 사양을 정확히 도출 및 분석하여 요구사항을 명세화하고, 이를 검증한 결과를 개발자들이 이해할 수 있는 형식으로 서술하는 활동”
    • 프로세스: 도출 -> 분석 -> 명세 -> 검증 (“요구사항 명세서” 작성 완료위한 업무절차)
  • 요구사항 관리: “고객이나 사용자로부터 개발될 요구사항과 프로젝트 계획 및 산출물간의 일관성을 확보하기 위한 활동”, 일관성 확보는 변경이 발생할 수 밖에 없는 현실에서 이미 만들어진 요구사항 명세서를 다시 현실과 맞도록 하는 작업
    • 상세활동
      • 요구사항에 대한 이해를 확보
      • 요구사항에 대한 고객 및 사용자와 합의
      • 요구사항의 변경관리 및 추적성 확보
      • 요구사항과 산출물 간의 불일치 사항을 식별 및 개선

5.4 요구사항 개발 프로세스

도출 -> 분석 -> 명세 -> 검증

  1. 요구사항 도출(elicitation): 고객이나 사용자가 원하는 요구사항을 수집하는 것. 요구사항에 대한 기초를 수집, 수집된 요구사항을 통해 개발되어야할 소프트웨어의 기능 및 제약사항을 식별, 이해하는 활동 진행, 요구사항은 계약 및 최초 범위산정의 기본이되며, 소프트웨어 활용할 조직의 사업기준과 규칙 참조할 필요 있음.(도메인 공부)
    • 인터뷰: 요구사항 도출 대상자 중에서 선발하여 이들과 직접 대화통해 정보 추출하는 기법, 어떻게 활용될 것인가?
      • 개방인터뷰(open interview): 형식이 없이 미리 준비된 질문서 없이 대화를 통해 진행
      • 폐쇄 인터뷰(close interview): 사전에 질문서 미리 제공, 이를 기준으로 진행, 인터뷰 결과는 “인버튜결과서”라는 회의록 유사한 문서산출물을 작성함. -> “요구사항 분석” 요구사항 명세서의 기초
    • 시나리오 기법: 소프트웨어와 사용자 간의 상호작용을 시나리오로 작성하거나 비즈니스 프로세스를 시나리오로 작성하여 요구사항을 도출하는 기법.(ex) BPMN(Business Process Modeling Notation) 활용 다이어그램 작성)
    • 관찰: 시찰해서 뭘만들지 관찰함. 시나라오나 인터뷰로 보완해야됨. 생산성 향상의 효과가 높을 것으로 보이는 포인트 알기위해 필요함. 업무상태를 자동화하는 것보다 파괴적으로 새로운 프로세스 설계하여 새로운 접근을 통해 생산성 향상을 가져올 수 있는 방법을 고민하기 위한 기초자료로 관찰이 진행되기도함. 요구사항 명세서 작성을 위한 기초로 활용하게 되며, 실제 솔루션화 고민 설계에서 이루어짐.
  2. 요구사항 분석(analysis): 대상자들로부터 추출된 추상적인 요구사항을 명세서 작성 전에 일관성 있는 요구사항으로 정리하는 것.
    • 분석활동의 기준
      • 구현될 소프트웨어를 계층적이고 구조적으로 표현할 수 있어야함.
      • 외부 사용자와의 인터페이스 및 내부 소프트웨어 모듈 혹은 시스템 구성요소 간의 인터페이스를 정확히 분석하여야함.
      • 분석활동 이후 설계와 구현을 위한 필요한 정보를 제공할 수 있어야한다.
    • 구조적 분석기법(structured analysis): 대표적 기법 데이터흐름도(DFD: Data Flow Diagram), 기능을 중심으로 구조적인 이해와 관계성을 분석함.
      • 프로세스 도출 -> 관련도니 조직이나 담당자(외부 엔터티(external entity))와의 데이터흐름 정의
    • 정보공학 분석기법(information engineering analysis): 조직전체의 관점에서 정보와 데이터구조에 초점을 맞춘 분석기법, 개체관계모형(ERD(Entity Relation Dialgram)), ERD에서의 개체 Entity는 데이터의 집합, 테이블로 표현될 실세계의 사물임.
    • 객체지향 분석기법(object oriented analysis): 요구사항을 사용자 중심의 시나리오 분석을 통해 유스케이스(use case)로 분석하는 기법 대표적, 유스케이스 실체화(realization)과정 통해 도출된 요구사항 분석함. 기능적 시나리오 분석
  3. 요구사항 명세(specification): 분석된 요구사항을 명확하고 완전하게 기록하는 것이 명세임. 소프트웨어 혹은 시스템이 수행하여야 할 모든 기능적 요구사항과 시스템 관련된 구현 상의 제약조건 및 개발자와 사용자가 합의한 성능 ㄷ으 비기능적 요구사항을 명세서로 작성함. 요구사항명세서(SRS: Software Requirements Specification) 초안이 완성(검증과 승인 전 0.5, 0.6버전), 가장 중요한 문서 SRS, 어떻게(HOW), 무엇을(WHAT), 수행할것인가를 기술한 문서. 소프트웨어가 이루어야할 목표 기술하지만 목표달성위한 해결방법은 기술하지 않음. 해결방안(HOW)는 설계단계에서.
    • 요구사항을 명세화할때 고려할점
      • 소프트웨어 품질특성 6가지
      • 소프트웨어와 연계되는 외부 인터페이스
      • 소프트웨어 개발과 관련된 제약사항
        • 법제도
        • 환경
        • 사업기준 / 규칙
        • 기술의 한계
    • 책을 쓴 저자의 팁
      • 소프트웨어가 수행할 모든 기능과 제약조건을 명확하게 기술
      • 기술된 모든 요구사항은 검증이 가능할 수 있도록 품질, 상대적 중요도, 검증 방법 및 기준을 명확하게 제시
      • 아직 특정한 구조나 알고리즘을 사용하여 설계하지 않을것.
      • 관련자들이 소프트웨어의 기능을 이해하거나, 변경에 대한 영향 분석 등을 위하여 계층적으로 구성
      • 요구사항을 쉽게 참조할 수 있도록 고유의 식별자(ID)를 부여
      • 모든 요구사항이 동등한것이 아니며, 모든 소프퉤어로 구현하는 것 아니므로 요구사항을 우선 순위화핳고 개발범위를 정할 수 있도록함.
  4. 요구사항 검증(verification): 이해관계자의 요구사항이 명세서 상에 올바르게 기술되었는가를 검토, 기술적으로 실현 가능한 스토리인가? 안전, 보안 및 위험성과 관련된 품질특성 요구사항이 정확한가? 설계기준에 따라 하드웨어 형상항목, 소프트웨어 형상항목 등에 적절하게 할당되었는가?
    • 검증 방법
      • 체크리스트를 통한 간단한 질문
        • 사용자나 고객의 목적을 완전히 서술했는가?
        • 문서작성 표준을 따르고 있는가?
        • 명세서 기준 설계작업 진행이 가능한가?
        • 명세서가 일관성과 완전성 가지는가?
    • 검증 완료 고객 승인하면, 베이스라인 설정. 버전 1.0 탄생함.
    • 버전 1.1, 1.2 같이 변경하며 관리적 측면에서 변경된 내용의 반영을 이력으로 기록을 통해 추적할 수 있도록 함.

5.5 요구사항 관리 프로세스

요구사항 추적 -> 변경요청 -> 변경영향분석 -> 변경 승인/기각 -> 요구사항 추적

베이스라인 설정된 요구사항 명세서는 지속적인 변경가능성을 모니터랑하고 변경되고 있는 과정을 추적하는 것 필요.

5.5.1. 요구사항 추적(requirements trace)

“요구사항 추적 매트릭스”는 고객이나 사용자가 요구한 내역, 즉 요구사항이 기능과 비기능적 항목으로 정의되고, 소프트웨어로 구현이 되었는지를 확인할 수 있게 함.

   graph LR
   A[요구사항 변경요청] --> B[요구사항 추적]
   B --> C[요구사항변경항목관리]
   B --> D{요구사항 추적 매트릭스}
   A --> E{요구사항 저장소}
   B --> E
   C --> E

5.5.2. 요구사항 변경요청(requirements change request)

  • 변경요청 원인
    • 요구사항의 요류, 충돌
    • 요구사항 간의 불일치
    • 기술적, 시간적인 문제와 비용상의 문제
    • 사용자 혹은 고객의 우선순위 변경
    • 법/제도, 경제상황 등 환경의 변화
    • 조직의 비즈니스 측면에 의한 변경
    • 기술의 발전에 따른 신기술 반영결정

변경을 정해진 절차에 따라 관리해야됨.

“요구사항 변경요청서” 작성이 원칙.

변경요청서 항목 내용
변경요청번호 프로젝트관리기준에 따름
변경제목 변경요청사항을 나타내는 이름
변경내용 변경이 필요하게 된 이유와 근거문서 등을 자세히 기술
변경처리 기한 요청자가 기대하는 ‘처리완료일’을 지정
변경요청 유형 단순, 일반, 긴급 등 변경관리 회의 소집여부를 표시
변경 항목 내용
UI 화면이나 보고서의 신규 개발이나 변경
데이터베이스 UI의 변경에 따른 DB의 수정, 혹은 새로운 DB생성
타시스템과 인터페이스 데이터의 전송을 위한 새로운 인터페이스의 필요
문서산출물 미리 정의되지 않았던 문서의 생성요청 및 수정
기타 새로운 HW, SW, 기술자 등의 추가투입 여부

5.5.3. 변경 영향분석(change effect analysis)

기존정의 요구사항에서 변경이 요청된 요구사항 수행해야할 업무범위, 일정, 예산등의 관점에서 어느정도 파급효과 나타낼지 추정해야됨.

영향분석은 변경요청서 상에 기록되어도 되고, 별도로 문서 생성해도 된다.(관리 편리성을 위해 동일한 문서에 영향도 파악하는 것이 관리 용이)

관련된 개발자 혹은 전문가가 프로젝트관리자와 함께 영향내역을 분석하여 프로젝트 전체에 미치는 영향 정도를 문서화함.

영향 분석 내용
일정 기존 일정의 변경 및 새로운 일정의 필요 여부
예산 주어진 예산 내에서 처리여부 및 새로운 비용 가능성
위험 전체 프로젝트의 성공에 미치는 위험 분석
심각도 변경 사안의 심각도와 계약관련 이슈사항 검토
해결방안 영향분석 결과, 가능한 해결방안의 모색

5.5.4. 변경 승인/기각(approval or reject)

승인이나 기각은 변경통제위원회(CCB: Change Control Board)의 결정, 발주자 측 사업책임자와 수주자 측 프로젝트관리자가 함께 협의에 의해 변경사항에 대한 수용여부를 협의하고 최종 결정함.

대립으로 결정할 수 없는 상황 발생 시 상위 의사결정위원회(Steering Committee)로 결정여부 넘김.(양측 경영층으로 구성된 최고의 의사결정기구)