요구사항 개발

요구공학(Requirements Engineering)

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

요구공학의 목적

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

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

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

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

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

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

• 도출(Elicitation) → 분석(Analysis) → 명세(Specification) → 확인(Validatioin)

요구사항 도출(Requirement Elicitation)

• 소프트웨어가 해결해야 할 문제를 이해하는 첫 번째 단계
• 현재의 상태를 파악하고 문제를 정의한 후 문제 해결과 목표를 명확히 도출하는 단계
• 요구사항의 위치와 수집 방법과 관련
• 이해관계자(Stakeholder)가 식별되며, 개발팀과 고객 사이의 관계가 만들어지는 단계
• 다양한 이해관계자와 효율적인 의사소통 중요
• 요구사항 도출 기법 : 고객의 발표, 문서 조사, 설문, 업무 절차 및 양식 조사, 브레인스토밍, 워크숍, 인터뷰, 관찰 및 모델의 프로토타이핑, Use Case, 벤치마킹 BPR(업무 재설계), RFP(제안 요청서)

요구공학 분석(Requirement Analysis)

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

요구사항 분석 수행 단계

• 문제 인식 : 인터뷰, 설문 조사 등 도구를 활용하여 요구사항을 파악하는 과정
• 전개 : 파악한 문제를 자세히 조사하는 작업
• 평가와 종합 : 요구들을 다이어그램이나 자동화 도구를 이용하여 종합하는 과정
• 검토 : 요구분석 작업의 내용을 검토, 재정리하는 과정
• 문서화 : 요구사항 분석 내용을 문서로 만드는 단계

요구사항 분류

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

요구사항 분류 기준

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

기능적 요구사항 vs 비기능적 요구사항

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

요구사항 명세(Requirement Specification)

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

요구사항 명세 기법

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

요구사항 명세 속성

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

요구사항 확인(Requirement Validation)

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

형상 관리(Configuration Management)

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

요구사항 할당(Requirement Allocation)

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

정형 분석(Formal Analysis)

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