요구사항 개발

요구사항 개발

요구공학(Requirements Engineering)

• 소프트웨어 개발 시 사용자 요구가 정확히 반영된 시스템 개발을 위하여 사용자의 요구를 추출, 분석, 명세, 검증, 관리하는 구조화된 활동 집합
• 요구사항을 정의하고, 문서로 만들고, 관리하는 프로세스를 의미
• 효과적인 의사소통을 통하여 공통 이해 설정, 불필요한 비용절감, 요구사항 변경 추적 가능
• 분석 결과의 문서화
• 자료 흐름도, 자료 사전 등이 효과적으로 이용될 수 있으며, 더 구체적인 명세를 위해 소단위 명세서(Mini-Spec)가 활용될 수 있음

요구공학의 목적

• 이해관계자 사이의 원활한 의사소통 수단 제공
• 요구사항 누락 방지, 상호 이해 오류 등 제거로 경제성 제공
• 요구사항 변경 이력 관리를 통하여 개발 비용 및 시간 절약
• 비용과 일정에 대한 제약 설정과 타당성 조사, 요구사항 정의 문서화 등 수행

요구사항 베이스라인(BaseLine, 기준선)

• 이해 당사자 간 명시적 합의 내용
• 프로젝트 목표 달성 여부를 확인하는 기준
• 요구사항을 조기에 명확히 확정
• 추수 발생 가능한 변경 사항을 체계적으로 관리하기 위한 기준

요구공학(개발) 프로세스

• 요구 사항을 명확히 분석하여 검증하는 진행 순서
• 개발 대상에 대한 요구사항을 체계적으로 도출
• 도출된 요구사항을 분석하여 분석 결과를 명세서에 정리
• 정리된 명세서를 마지막으로 확인, 검증하는 일련의 단계
• 경제성, 기술성, 적법성, 대안성 등 타당성 조사(Feasibility Study)가 선행되어야 함

SWEBOK에 따른 요구사항 개발 프로세스

flowchart LR
A[도출: Elicitation]-->B[분석: Analysis]-->C[명세: Specification]-->D[확인: Validation]

SWEBOK

• Software Engineering Body of Knowledge, 소프트웨어 공학 지식체계
• 국제 표준화 기구의 정보 기술 분야인 ISO/IEC에서 의견을 모아 집필 발간하는 표준화 체계 문서

요구사항 도출(Requirement Elicitation)

• 소프트웨어가 해결해야 할 문제를 이해하는 첫번째 단계
• 현재의 상태를 파악하고 문제를 정의한 후 문제 해결과 목표를 명확히 도출하는 단계
• 요구사항의 위치와 수집 방법과 관련되어 있음
• 이해 관계자(Stakeholder)가 식별되며
• 개발팀과 고객 사이의 관계가 만들어지는 단계이며
• 다양한 이해관계자와 효율적인 의사소통이 중요

요구사항 도출 기법

• 고객의 발표
• 문서 조사
• 설문
• 업무 절차 및 양식 조사
• 브레인 스토밍
• Use Case
• BPR(업무 재설계)
• RFP(제안 요청서)
• 벤치마킹
• 관찰 및 모델의 프로토 타이핑

요구사항 분석(Requirement Analysis)

• 소프트웨어가 환경과 어떻게 상호작용하는 지 이해하고
• 사용자의 요구사항을 걸러내기 위한 과정을 통하여 요구사항을 도출하고
• 요구사항 정의를 문서화하는 과정
• 도출된 사항을 분석하여 소프트웨어 개발 범위를 파악
• 개발 비용, 일정에 대한 제약을 설정하고 타당성 조사 수행
• 요구사항 간 상충하는 것을 해결
• 소프트웨어 범위(비용과 일정)를 파악하고 타당성 조사 시행
• 요구사항 기술 시 요구사항 확인, 요구사항 구현의 검증, 비용 추정 등의 작업이 가능하도록 충분하고 정확하게 기술

요구사항 분석을 위한 기법

• 사용자 의견 청취
• 사용자 인터뷰
• 현재 사용중인 각종 문서 분석과 중재
• 관찰 및 모델 작성 기술
• 설문 조사를 통한 의견 수렴

요구사항 분석 수행단계

1. 문제인식

   • 인터뷰, 설문 조사 등 도구를 활용하여 요구 사항을 파악하는 과정

2. 전개

   • 파악한 문제를 자세히 조사하는 작업

3. 평가와 종합

   • 요구들을 다이어그램이나 자동화 도구를 이용하여 종합하는 과정

4. 검토

   • 요구분석 작업의 내용을 검토, 재정리하는 과정

5. 문서화

   • 요구사항 분석 내용을 문서로 만드는 단계

flowchart LR
A[문제인식]-->B[전개]-->C[평가와 종합]-->D[검토]-->E[문서화]

요구사항 분류

• 기술 내용에 따른 분류

기능적 요구사항	비기능적 요구사항
시스템이 실제로 어떻게 동작하는 지에 관점을 둔 요구사항	시스템 구축에 대한 성능, 보안, 품질, 안정성 등으로 실제 수행에 보조적인 요구사항

• 기술 관점 및 대상에 따른 분류
  • 시스템 요구사항
  • 사용자 요구사항

요구사항 분류 기준

• 기능 요구사항, 비기능 요구사항을 구분하고 우선순위 여부 확인
• 요구사항이 하나 이상의 고수준 요구사항으로부터 유도된 것인지 확인
• 이해관계자나 다른 원천(source)으로부터 직접 발생한 것인지 확인
• 요구사항이 제품에 관한 것인지 프로세스에 관한 것인지 확인 후 요구사항이 소프트웨어에 미치는 영향의 범위를 확인
• 요구사항이 소프트웨어 생명 주기 동안에 변경이 발생하는 지 확인

요구사항 명세(Requirement Specification)

• 시스템 정의, 시스템 요구사항, 소프트웨어 요구사항을 작성
• 체계적으로 검토, 평가, 승인될 수 있도록 문서로 작성하는 것을 의미
• 기능 요구사항은 빠지는 부분 없이 명확하게 기술
• 설계 과정의 오류사항을 추적할 수 있어야 함
• 비기능 요구사항은 필요한 것만 명확하게 기술

요구사항 명세 기법

구분	정형 명세	비정형 명세
기법	수학적 기반/모델링 기반	상태/기능/객체 중심 명세 기법 자연어 기반
종류	Z, VDM Petri-Net(모형 기반)	FSM(Finite State Machine) Decision Table, ER 모델링 State Chart(SADT) UseCase 사용자 기반 모델링
장점	시스템 요구 특성을 정확하고 명세가 간결하게 명세 가능 명세/구현의 일치성	명세 작성 이해 용이 의사 전잘 방법 다양성
단점	낮은 이해도 이해관계자의 부담 가중	불충분한 명세 기능 모호성

요구사항 명세 속성

속성	설명
정확성	요구사항은 정확해야 함
명확성	단 한가지로만 해설되어야 함
완전성	모든 것이 표현(기능+비기능) 가능해야 함
일관성	요구사항 간 충돌이 없어야 함
수정 용이성	요구사항 변경이 가능해야 함
추적성	RFP, 제안서를 통해 추적 가능해야 함

요구사항 확인(Requirement Validation)

• 요구사항 분석 단계를 거쳐 문서로 만들어진 내용을 확인하고 검증하는 단계
• 일반적으로 요구사항 관리 도구를 이용하여 이해관계자들이 문서를 검토해야 하고, 요구사항 정의 문서들에 대해 형상 관리
• 회사의 표준에 적합하고 이해할 수 있고, 일관성 있고 완전한 지 곰증
• 요구 분석가가 요구사항을 이해했는 지 확인(Validation)이 필요
• 리소스가 요구사항에 할당되기 전에 문제를 파악하기 위하여 다음과 같은 검증 수행
  • 표준에 적합한가?
  • 이해 가능한가?
  • 일관성 있는가?
  • 완전한가?

요구사항 관리 도구의 필요성

• 요구사항 변경으로 인한 비용 편익 분석
• 요구사항 변경의 추적
• 요구사항 변경에 따른 영향 평가

형상 관리(Configuration Management)

• 앱 개발 단계에서 도출되는 프로그램, 문서, 데이터 등의 모든 자료를 현상 단위라고 함
• 이러한 자료의 변경을 관리함으로써 앱 버전 관리 등을 하는 활동을 의미

요구사항 할당(Requirement Allocation)

• 요구사항을 만족시키기 위한 아키텍처 구성 요소를 식별하는 활동
• 식별된 타 구성요소와 상호작용 여부 분석을 통하여 추가 요구사항을 발겨

정형분석(Formal Analysis)

• 구문(Syntax)와 형식적으로 정의된 의미(Semantics)를 지닌 언어로 요구사항을 표현
• 정확하고 명확하게 표현하여 오해 최소화
• 요구사항 분석의 마지막 단계에서 이루어짐

요구사항 확인 기법

요구사항 확인 기법의 종류

• 프로토 타이핑(Prototyping)
• 모델 검증(Model Verification)
• 요구사항 검토(Requirement Revies)
• 인수 테스트(Accptance Test)

프로토 타이핑(Prototyping)

• 도출된 요구 사항을 토대로 프로토타입(시제품)을 제작하여 대상 시스템과 비교하면서 개발 중에 도출되는 추가 요구 사항을 지속해서 재작성하는 과정
• 새로운 요구사항을 도출하기 위한 수단
• 소프트웨어 엔지니어 관점에서 요구사항을 확인하기 위한 수단으로 많이 사용되고 실제 구현 전에 잘못된 요구 사항을 적용하는 자원 낭비 방지 가능

프로토 타이핑 절차

flowchart LR
A[요구사항 분석]-->B[프로토타입 설계]-->C[프로토타입 개발]-->D[고객의 평가]-->E[프로토타입 정제]-->F[완제품 생산]

프로토 타이핑 장단점

장점	단점
분석가의 가정을 파악하고 잘못되었을 때 유용한 피드백 제공 문서나 그래픽 모델보다 프로토타입으로 이해하기 쉬워 사용자와 개발자 사이의 의사소통에 도움이 됨 요구사항의 가변성이 프로토타이핑 이후에 급격히 감소함 빠르게 제작 가능하며 반복 제작을 통하여 발전된 결과를 가져올 수 있음	사용자의 관심이 핵심 기능에서 멀어질 수 있으며 프로토타입의 디자인이나 품질문제로 집중될 수 있음 프로토타입 수행 비용 발생 전체 범위 중 일부 대상 범위만 프로토타입을 제작하면 사용성이 과대 평가될 수 있음

모델 검증(Model Verification)

• 분석 단계에서 개발된 모델의 품질 검증
• 정적 분석(Static Analysis)
  • 객체 모델에서 객체들 사이에 존재하는 Communication Path(의사소토 경로)를 검증하기 위해 사용
  • 명세의 일관성과 정확성을 확인 분석하는 도구
• 동적 분석(Dynamic Analysis)
  • 직접 실행을 통하여 모델을 검증하는 방식

인수 테스트(Acceptance Test)

• 최종 제품이 설계 시 제시한 요구사항을 만족하는 지 확인하는 단계
• 인수 시 각 요구사항의 확인 절차 계획해야 함
• 종류
  • 계약 인수 테스트
  • 규정인수 테스트
  • 알파검사
  • 베타검사
  • 사용자 인수 테스트
  • 운영 인수 테스트