미완성 블로그입니다

3. Requirement Engineering


요구 공학(Requirement Engineering)

고객이 시스템에 요구하는 서비스와 시스템 운영 및 개발에 적용되는 제약 조건을 설정하는 프로세스

  • 요구사항 엔지니어링 프로세스 중에 생성되는 시스템 서비스와 제약 조건에 대한 설명을 시스템 요구사항이라 한다

  • 요구사항(Requirements): 서비스 또는 시스템 제약 조건에 대한 고수준의 추상적인 진술부터 상세한 수학적 기능 사양까지 다양합니다
    • 서비스 진술 - 기능 요구사항(FR)
    • 시스템 제약 조건 - 비기능 요구사항(NFR)
  • 사용자 요구사항(User requirements)
    • 시스템이 제공하는 서비스와 그 운영상의 제약 사항을 자연어로 표현한 설명 및 다이어그램
    • 이해관계자로부터 도출(Elicited)/발견
    • 고객을 위해 정의
  • 시스템 요구사항(System requirements)
    • 시스템의 기능, 서비스 및 운영 제약 사항에 대한 자세한 설명을 제시하는 구조화된 문서
    • 구현해야 할 사항을 정의
    • 개발자를 위해 명시

System Stakeholders (시스템 이해 관계자)

어떤 방식으로든 시스템의 영향을 받는 사람이나 조직으로서 합법적인 이해관계를 가진 사람

Stakeholder features
User 새로운 시스템의 기능과 기능에 관심이 있음
Designer 완벽한 시스템을 구축하거나 기존 코드를 재사용하고 싶어함
System Analyst 요구 사항을 정확히 충족하고 싶어함
Training and User Support 새로운 시스템이 사용 가능하고 관리 가능한지 확인하고 싶어함
Business Analyst 경쟁사보다 더 나은 성과를 내고 있다는 것을 확인하고 싶어함
Technical Author 새로운 시스템에 대한 사용자 매뉴얼 및 기타 문서를 준비합니다
Project Manager 모든 목표를 달성하고 예산 내에서 정해진 시간 내에 프로젝트를 완료하고 싶어합니다
Customer 투자한 돈에 대한 최상의 가치를 얻고 싶어함

애자일 방법 및 요구사항

  • 많은 애자일 방법론은 다음과 같이 주장합니다
    • 요구사항은 너무 빨리 변하기 때문에 자세한 시스템 요구 사항을 작성하는 것은 시간낭비이다
    • 따라서 요구사항 문서는 항상 out of date 이다
  • 애자일 방법은 일반적으로 증분적 요구 사항 엔지니어링을 사용하며 요구 사항을 사용자 스토리로 표현할 수 있음
    • 비즈니스 시스템에 적합
    • 출시 전 분석이 필요한 중요한 시스템 등이나 여러 팀이 개발한 시스템의 경우에 대해 종종 문제 발생 (이는 Waterfall 방식이 적절함)


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

기능적 요구사항

  • 시스템이 제공해야 하는 서비스에 대한 설명
    • 시스템이 특정 입력에 어떻게 반응해야 하는지
    • 시스템이 특정 상황에서 어떻게 동작해야 하는지
      • 시스템이 해야 할/하지 말아야 할 일을 명시할 수 있음
    • 기능적 사용자 요구사항은 시스템이 수행해야 하는 작업을 개략적으로 설명하는 내용일 수 있음
    • 기능적 시스템 요구사항은 시스템 서비스(사용자 요구사항)를 자세히 설명해야 함

비기능적 요구사항

  • 시스템이 제공하는 서비스나 기능에 대한 제약 조건
    • 시간, 개발 프로세스에 대한 제약이나 표준 등
    • 개별 기능이나 서비스보다는 시스템 전체에 적용되는 경우가 많음

도메인 요구사항

  • 운영 도메인의 시스템 제약 조건


요구사항 부정확성 (Imprecision)

기능적 요구사항이 명확하게 명시되지 않으면 문제가 발생할 수 있습니다

  • Ambiguous 한 요구사항은 개발자와 사용자가 서로 다르게 해석할 수 있습니다
  • 예를 들어, “사용자는 모든 진료소의 예약 목록을 검색할 수 있어야 합니다”
    • 사용자는 모든 진료소의 모든 예약에서 환자 이름을 검색합니다
    • 그러나 개발자의 의도는 진료소를 선택하고, 개별 진료소에서 환자 이름을 검색하는 것입니다.
    • 이는 언어의 중의적 표현과 모호함과 관련이 있습니다.


요구사항 완전성 및 일관성

원칙적으로 요구사항은 완전하고 일관성 있어야 합니다(Complete & Consistent)

  • Complete
    • 필요한 모든 것에 대한 설명을 포함해야 함
  • Consistent
    • 설명에 충돌이나 모순이 없어야 함
  • 현실적으로 완전하고 일관된 요구사항 문서를 작성하는 것은 불가능


비기능적 요구사항

시스템 속성 및 제약 조건을 정의

  • 속성 - 안정성, 응답 시간 및 저장공간에 대한 요구사항, I/O 장치 기능, 시스템 표현 등
  • 제약 조건 - 특정 IDE, 프로그래밍 언어, 개발 방법, 또는 표준 준수
    • IEC 61508, ISO 26262, IEEE 829,830,1012,1016,12207,25010, etc.
      예시 표준에 대한 설명
      표준 정식 명칭 주요 내용 / 적용 분야
      IEC 61508 Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems 기능 안전(Functional Safety)의 근간이 되는 표준으로, 모든 산업 분야(E/E/PE 시스템)에 적용 가능. 자동차용 ISO 26262, 철도용 EN 50128, 산업기계용 IEC 62061 등의 상위 표준.
      ISO 26262 Road Vehicles – Functional Safety 자동차 전자·전기(E/E) 시스템의 기능 안전 표준. IEC 61508을 자동차 분야에 맞게 확장한 것으로, ASIL 등급(A~D)으로 위험도를 분류하여 관리.
      IEEE 829 Standard for Software and System Test Documentation 소프트웨어 테스트 문서화 표준. 테스트 계획, 설계, 절차, 결과 보고서 등의 문서 형식과 내용 정의. (현재는 ISO/IEC/IEEE 29119로 통합 대체됨)
      IEEE 830 Recommended Practice for Software Requirements Specifications 요구사항 명세서(SRS) 작성 표준. SRS의 구성, 표현 방식, 품질 특성 등을 규정. (현재 ISO/IEC/IEEE 29148로 통합)
      IEEE 1012 Standard for System and Software Verification and Validation 검증(Verification) 및 확인(Validation) 프로세스 표준. 시스템이 요구사항에 맞게 구현되고 올바르게 동작하는지 검증 절차 정의.
      IEEE 1016 Recommended Practice for Software Design Descriptions 소프트웨어 설계 명세(SDD) 작성 표준. 설계 문서의 구조, 내용, 표현 방식 제시.
      IEEE 12207 Systems and Software Engineering – Software Life Cycle Processes 소프트웨어 생명주기 프로세스(Lifecycle Processes) 표준. 개발, 운영, 유지보수, 지원 활동 전체의 절차 정의. (ISO/IEC 12207으로 통합됨)
      ISO/IEC 25010 Systems and Software Quality Requirements and Evaluation (SQuaRE) – Quality Model 소프트웨어 품질 특성 모델 표준. 8가지 품질 특성(기능적합성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성, 보안성, 호환성)을 정의. 품질 평가 지표로 활용.

비기능적 요구사항의 분류

참고