#4 소프트웨어 설계 4 – 요구사항 개발

by

요구 사항 개발

요구사항 엔지니어링

  • 소프트웨어 개발 시 사용자 요구사항을 정확하게 반영하는 시스템을 개발하기 위해 사용자 요구사항을 추출, 분석, 지정, 검증, 관리하는 일련의 구조화된 활동
  • 요구 사항을 정의, 문서화 및 관리하는 프로세스
  • 효과적인 의사소통을 통해 일반적인 이해 설정, 불필요한 비용 절감, 요구 사항 변경 추적
  • 분석 결과의 문서화
  • 데이터 흐름 다이어그램, 재료 사전 등을 효과적으로 사용할 수 있으며, 보다 구체적인 사양에 대해서는 미니 사양사용할 수 있습니다

요구 공학의 목적

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

요구 사항 기준선(기준선)

  • 이해 당사자 간의 명시적인 합의
  • 프로젝트 목표 달성 여부를 판단하는 기준
  • 조기에 명확한 니즈 평가
  • 가능한 수확 변화의 체계적인 처리 기준

요구사항 엔지니어링(개발) 프로세스

  • 요구 사항을 명확하게 분석하고 검증하는 일련의 단계
  • 개발 목표 요구사항의 체계적 도출
  • 도출된 요구사항을 분석하고 분석결과를 스펙으로 정리
  • 정리된 진술을 최종적으로 확인하고 검증하는 일련의 단계
  • 다음과 같은 타당성 조사 나. 경제성, 기술적 타당성, 합법성 및 대안이 선행되어야 한다.

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

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

스위복

  • 소프트웨어 엔지니어링 지식 기반,
  • 국제 표준화 기구의 정보 기술 분과인 ISO/IEC의 의견을 수렴하여 작성 및 발간한 표준화 시스템 문서

요구사항 도출

  • 소프트웨어가 해결하려는 문제를 이해하는 첫 번째 단계
  • 현재 상태를 파악하고 문제를 정의하며 문제에 대한 목표와 해결책을 명확하게 도출하는 단계
  • 요구 사항이 있는 위치 및 캡처 방법과 관련됨
  • 이해관계자를 식별하고
  • 이 단계에서 개발 팀과 고객 간의 관계가 생성됩니다.

  • 다양한 이해관계자와의 효과적인 커뮤니케이션이 중요

요구사항 도출 기법

  • 고객 발표
  • 서류심사
  • 여론 조사
  • 비즈니스 프로세스 및 양식 검토
  • 브레인스토밍
  • 사용 사례
  • 비즈니스 재설계(BPR)
  • 견적 요청(RFP)
  • 벤치마킹
  • 모델 관찰 및 프로토타이핑

요구 사항 분석

  • 소프트웨어가 환경과 상호 작용하는 방식 이해
  • 사용자 요구사항을 필터링하여 요구사항 도출
  • 요구 사항 정의를 문서화하는 프로세스
  • 결과 분석을 통한 소프트웨어 개발 범위 파악
  • 개발 비용 제약, 일정 설정 및 개념 증명 연구 수행
  • 상충되는 요구 사항 해결
  • 소프트웨어 범위(비용 및 일정) 파악 및 개념 증명 수행
  • 요구사항을 설명할 때 요구사항 검토, 요구사항 구현 확인, 비용 산정 등의 작업이 가능하도록 요구사항을 충분하고 정확하게 설명하십시오.

요구사항 분석 기법

  • 사용자 피드백 듣기
  • 사용자 인터뷰
  • 현재 사용되는 다양한 문서 분석 및 소통
  • 관찰 및 모형 제작 기술
  • 설문조사를 통한 의견 수렴

요구 사항 분석을 수행하는 단계

  1. 문제 감지

    • 인터뷰, 설문조사 등의 도구를 사용하여 니즈를 파악하는 과정

  2. 사명

    • 식별된 문제에 대한 추가 조사

  3. 평가 및 합성

    '추천 관련글,
    • 다이어그램 또는 자동화 도구를 사용하여 요구사항을 종합하는 프로세스

  4. 시험

    • 요구사항 분석 작업의 내용을 검토하고 재정렬하는 과정

  5. 선적 서류 비치

    • 요구 사항 분석을 문서화하는 단계
flowchart LR
A(문제인식)-->B(전개)-->C(평가와 종합)-->D(검토)-->E(문서화)

요구 사항의 분류

  • 기술내용에 따른 분류
기능 요구 사항 비기능적 요구 사항
시스템이 실제로 작동하는 방식과 관련된 요구 사항 다음과 같은 실제 성능을 보완하는 요구 사항 B. 시스템 구축을 위한 성능, 보안, 품질 및 안정성
  • 기술 관점 및 목적에 따른 분류
    • 시스템 요구 사항
    • 사용자 요구 사항

요건 분류 기준

  • 기능 및 비기능 요구사항 분류 및 우선순위 검토
  • 요구 사항이 하나 이상의 상위 수준 요구 사항에서 파생되는지 확인
  • 이해 관계자 또는 다른 출처에서 직접 오는지 확인하십시오.
  • 요구 사항이 제품과 관련된 것인지 또는 프로세스와 관련된 것인지를 결정한 다음 요구 사항이 소프트웨어에 영향을 미치는 정도를 결정합니다.

  • 소프트웨어 수명 주기 동안 요구 사항이 변경되는지 확인

요구 사항 사양

  • 시스템 정의, 시스템 요구 사항 및 소프트웨어 요구 사항 생성
  • 체계적으로 검토, 평가 및 승인될 수 있는 방식으로 문서를 작성하는 것을 의미합니다.

  • 기능적 요구 사항은 누락 없이 명확하게 명시되어 있습니다.

  • 설계 프로세스의 오류는 추적 가능해야 합니다.

  • 비기능적 요구사항은 필요한 것만 명확하게 기술

요구 사항 사양 기술

분할 공식 사양 비정형 사양
기술 수학적으로 베이스/모델 베이스 상태/함수/객체 지향 사양 기술
자연어 베이스
유형 지VDM
Petri net(모델 기반)		 유한 상태 머신(FSM)
결정 테이블, ER 모델링
상태 다이어그램(SADT)
사용 사례
사용자 기반 모델링
장점 시스템 요구 사항의 기능을 정확하고 _간략하게_ 지정하는 능력
사양/구현의 일관성		 이해하기 쉬운 명세서 작성
Prewell 박사의 방법의 다양성
불리 약간의 이해
이해관계자에 대한 압박 증가		 불충분한 사양 기술
모호

요구 사항 사양 속성

재산 설명
정확성 요구 사항은 정확해야 합니다.
명쾌함 한 가지로 설명해야 한다
완전성 모든 것은 표현 가능해야 합니다(기능적 + 비기능적).
일관성 요구 사항 간에 충돌이 없어야 합니다.
간단한 변경 변할 수 있어야 한다
추적성 RFP, 제안을 통해 추적 가능해야 함

요구 사항 검증

  • 요구사항 분석 단계에서 문서로 변환된 내용을 검토 및 검증하는 단계
  • 일반적으로 요구 사항 관리 도구를 사용할 때 이해 관계자는 문서 및 요구 사항 정의 문서를 검토해야 합니다.

    구성 관리
  • 회사 표준을 추적 가능하고 일관되며 완벽하게 준수
  • 요구 사항 분석가가 요구 사항을 이해하는지 확인하려면 검증이 필요합니다.

  • 요청에 리소스를 할당하기 전에 다음 확인을 수행하여 문제를 식별합니다.

    • 표준을 준수합니까?
    • 이해할 수 있습니까?
    • 일관성이 있습니까?
    • 완료되었나요

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

  • 변화하는 요구 사항의 비용 편익 분석
  • 요구 사항 변경 추적
  • 변화하는 요구 사항의 영향 평가
구성 관리
  • 앱 개발 단계에서 나오는 프로그램, 문서, 데이터 등 모든 자료를 개발 단위라고 합니다.

  • 해당 데이터의 변경 사항을 관리하여 앱 버전 관리와 같은 활동을 말합니다.

요구 사항 매핑

  • 요구 사항을 충족하기 위해 아키텍처 구성 요소를 식별하는 활동
  • 식별된 다른 구성 요소와의 상호 작용을 분석하여 추가 요구 사항 발견

공식 분석

  • 구문 및 형식적으로 정의된 의미를 사용하여 언어로 요구 사항 표현
  • 정확하고 명확한 언어 사용으로 오해 최소화
  • 요구사항 분석의 마지막 단계에서 기록

요구 사항 검증 기술

요구 사항 검증 기술의 유형

  • 프로토타입 개발
  • 모델 검증
  • 요구 사항 확인
  • 승인 테스트

프로토타입 개발

  • 개발 과정에서 도출된 추가 요구사항을 지속적으로 재작성하고 도출된 요구사항을 바탕으로 프로토타입(prototype)을 생성하여 타겟 시스템과 비교하는 과정
  • 새로운 요구 사항 도출 수단
  • 소프트웨어 개발자의 관점에서 요구사항을 검토하는 수단으로 많이 사용되며 실제 구현 전에 잘못된 요구사항을 적용하여 자원 낭비를 방지할 수 있습니다.

프로토타이핑 프로세스
flowchart LR
A(요구사항 분석)-->B(프로토타입 설계)-->C(프로토타입 개발)-->D(고객의 평가)-->E(프로토타입 정제)-->F(완제품 생산)
프로토타이핑의 장단점
장점 불리
분석가의 가정을 식별하고 잘못된 경우 유용한 피드백을 제공합니다.


프로토타입은 사용자와 개발자 간의 커뮤니케이션을 용이하게 하는 문서나 그래픽 모델보다 이해하기 쉽습니다.


요구 사항의 가변성은 프로토타이핑 후 극적으로 감소합니다.


빠르게 제작할 수 있으며 반복 제작을 통해 고급 결과물을 얻을 수 있습니다.

 사용자의 관심은 핵심 기능에서 벗어나 프로토타입 디자인이나 품질 문제에 집중될 수 있습니다.


프로토타이핑 비용
전체 영역에서 대상 영역의 하위 집합만 프로토타이핑하면 유용성이 과대 평가될 수 있습니다.

모델 검증

  • 분석 단계에서 개발된 모델의 품질 검증
  • 정적 분석
    • 객체 모델에서 객체간 존재하는 통신 경로(pseudo Soto path)를 확인하기 위해 사용
    • 사양의 일관성과 정확성을 확인하고 분석하는 도구
  • 동적 분석
    • 직접 실행을 통해 모델을 검증하는 방법

승인 테스트

  • 최종 제품이 설계 시 설정한 요구 사항을 충족하는지 확인하는 단계
  • 승인 시점에 각 요구 사항에 대한 검증 프로세스를 계획해야 합니다.

  • 유형
    • 계약 수락 테스트
    • 공식 합격 시험
    • 알파 테스트
    • 베타 테스트
    • 사용자 수용 테스트
    • 운영 승인 테스트