맨위로가기

요구사항 분석

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

요구사항 분석은 시스템 개발 과정에서 고객 또는 사용자의 요구를 파악하고 문서화하는 일련의 활동을 의미한다. 주요 활동으로는 요구사항 수집, 분석, 기록이 있으며, 인터뷰, 워크숍, 프로토타이핑, 유스케이스, 사용자 스토리 등의 기법이 활용된다. 요구사항 분석은 이해관계자 식별 및 관리, 요구사항 명세, 다양한 유형의 요구사항 분류를 포함하며, 문제점 해결을 위해 비즈니스 분석 전문가 활용, 프로토타이핑 등의 기술 도입이 이루어진다.

더 읽어볼만한 페이지

  • 시스템 개발 - 제안요청서
    제안요청서는 구매자가 입찰자에게 요구사항을 전달하여 사업 제안서를 작성하도록 하는 문서로서, 정부 조달에서는 잠재적 계약자에게 요구사항을 전달하고 제안을 요청하는 데 사용되며, 한국 기업 환경에서는 협력업체 선정 및 프로젝트 진행의 중요한 도구로 활용되고 ESG 요소를 평가 항목에 반영하는 사례가 증가하고 있다.
  • 시스템 개발 - 요구사항
    요구사항은 이해 관계자의 필요를 충족시키기 위해 솔루션이 갖춰야 할 조건이나 능력, 또는 그 문서화된 표현을 의미하며, 소프트웨어 공학 및 시스템 공학에서 시스템이 무엇을 해야 하는지를 정의하는 중요한 개념이다.
  • 소프트웨어 요구사항 - 유스 케이스
    유스 케이스는 시스템과 액터 간 상호작용을 통해 시스템 목표 달성에 기여하는 동작들을 나타내는 요구 사항 캡처, 모델링, 명세 기법으로, 객체 지향 소프트웨어 공학에서 기능 요구 사항을 캡처하는 데 중요한 역할을 하며 다양한 분야에서 활용된다.
  • 소프트웨어 요구사항 - 유스 케이스 다이어그램
    유스 케이스 다이어그램은 시스템 요구 사항 정의 및 이해 관계자와의 소통을 위해 시스템 내 액터와 유스 케이스 간 상호 작용을 시각적으로 표현하는 다이어그램이다.
  • 소프트웨어 개발 프로세스 - 버전 관리
    버전 관리는 파일 변경 이력을 체계적으로 관리하는 시스템이며, 다양한 구조와 소스 관리 모델을 통해 협업을 지원하고, 비즈니스 등 다양한 분야에서 활용된다.
  • 소프트웨어 개발 프로세스 - 소프트웨어 개발 수명 주기
    소프트웨어 개발 수명 주기(SDLC)는 시스템 설계자와 개발자가 따르는 일련의 단계로, 예비 분석부터 폐기까지 여러 단계를 거치며, 폭포수 모델, 시스템 분석 및 설계(SAD), 객체 지향 분석 및 설계(OOAD) 등 다양한 방법론을 포함한다.
요구사항 분석
개요
이름요구사항 분석
영어 이름Requirements analysis
관련 분야소프트웨어 공학
관련 활동요구사항 엔지니어링
설명
정의소프트웨어 프로젝트의 필수적인 초기 단계로, 사용자의 요구를 이해하고 명확하게 정의하는 과정임.
중요성프로젝트 실패의 주요 원인 중 하나는 요구사항 분석의 부족이며, 성공적인 소프트웨어 개발을 위해 매우 중요함.
목표이해 관계자들의 요구를 정확히 파악하고 문서화하여 개발 팀이 이해할 수 있도록 하는 것임.
주요 활동
요구사항 식별사용자 인터뷰, 설문 조사, 문서 분석 등을 통해 요구사항을 수집함.
요구사항 분석수집된 요구사항을 분류, 모델링, 우선순위 결정 등을 통해 분석함.
요구사항 명세분석된 요구사항을 명확하고 검증 가능한 형태로 문서화함.
요구사항 검증명세된 요구사항이 실제 사용자의 요구와 일치하는지 확인하고 검토함.
관련 기술 및 도구
모델링 언어UML (Unified Modeling Language) 등
요구사항 관리 도구다양한 상용 및 오픈 소스 요구사항 관리 도구 활용

2. 요구사항 분석의 주요 활동

요구사항 분석은 크게 세 가지 주요 활동으로 구성된다.


  • 요구사항 도출: 고객 및 사용자와 대화하여 요구사항을 결정하는 작업으로, 요구사항 수집이라고도 불린다.
  • 요구사항 분석: 언급된 요구사항의 불명확성, 불완전성, 모호성, 모순 등을 판단하고 해결한다.
  • 요구사항 기록: 자연어 문서, 유스 케이스, 사용자 스토리, 공정 명세서 등 다양한 형식으로 요구사항을 문서화한다.


요구사항 분석은 지루하고 힘든 과정일 수 있으며, 섬세한 심리적 기술이 필요하다. 새로운 시스템은 환경과 사람들 간의 관계를 변화시키므로, 모든 이해 관계자를 식별하고, 그들 모두의 요구를 고려하며, 새로운 시스템의 결과를 이해시키는 것이 중요하다.

분석가는 고객으로부터 요구사항을 도출하기 위해 인터뷰, 포커스 그룹 워크숍, 요구사항 목록 작성, 프로토타이핑, 유스 케이스 작성 등 다양한 기술을 사용할 수 있다. 이러한 기술들을 적절히 조합하여 고객의 요구사항을 충족시켜야 한다.[4][5]

2. 1. 요구사항 도출

요구사항 도출은 고객, 사용자 및 기타 이해 관계자와의 소통을 통해 시스템에 대한 요구사항을 수집하고 파악하는 단계이다. 이 과정에서는 인터뷰, 포커스 그룹, 워크숍, 설문 조사 등 다양한 기법이 활용된다.[4][5] 요구사항 도출은 요구사항 수집이라고도 불리며, 프로젝트 헌장 또는 정의, 비즈니스 프로세스 문서화, 이해 관계자 인터뷰 등을 포함한다.

2. 2. 요구사항 분석

요구사항 분석은 수집된 요구사항의 명확성, 완전성, 일관성, 타당성 등을 검토하고, 모호성, 중복, 충돌 등을 해결하는 단계이다.

개념적으로 요구사항 분석은 다음 세 가지 활동을 포함한다.

  • 요구사항 도출: 프로젝트 헌장(정의), 비즈니스 프로세스 문서화, 이해 관계자 인터뷰 등을 통해 요구사항을 파악한다. 요구사항 수집 또는 발견이라고도 한다.
  • 요구사항 분석: 명시된 요구사항이 명확하고, 완전하고, 중복되지 않고, 간결하며, 유효하고, 일관되고, 모호하지 않은지 확인하고 충돌을 해결한다. 요구사항 크기 조정도 포함될 수 있다.
  • 요구사항 기록: 요구사항은 요약 목록, 자연어 문서, 사용자 시나리오, 사용자 스토리, 프로세스 명세, 데이터 모델 등 다양한 형식으로 문서화된다.


요구사항 분석은 길고 지루한 과정일 수 있으며, 섬세한 심리적 기술이 필요하다. 새로운 시스템은 환경과 사람들의 관계를 변화시키므로, 모든 이해 관계자를 식별하고, 그들의 요구사항을 고려하며, 새로운 시스템의 의미를 이해하도록 하는 것이 중요하다.

분석가는 고객으로부터 요구사항을 도출하기 위해 여러 기술을 사용할 수 있다.

  • 전통적인 방법: 인터뷰, 포커스 그룹(요구사항 워크숍 또는 요구사항 검토 세션), 요구사항 목록 작성
  • 현대적인 방법: 프로토타이핑, 유즈 케이스, 시나리오 개발(애자일 소프트웨어 개발에서 사용자 스토리로 표현됨), 작업장 관찰, 민족지학


필요한 경우 분석가는 이러한 방법을 조합하여 이해 관계자의 정확한 요구사항을 설정하고, 비즈니스 요구사항을 충족하는 시스템을 만든다.[4][5]

요구사항의 품질을 개선하는 방법은 다음과 같다.

  • 시각화: 시각화 및 시뮬레이션 도구를 사용하여 원하는 최종 제품에 대한 이해를 돕는다.
  • 템플릿의 일관된 사용: 일관된 모델 및 템플릿을 사용하여 요구사항을 문서화한다.
  • 의존성 문서화: 요구사항 간의 종속성, 상호 관계, 가정 및 집합체를 문서화한다.

2. 3. 요구사항 기록

분석된 요구사항은 자연어 문서, 유스 케이스, 사용자 스토리, 프로세스 명세 등 다양한 형식으로 문서화된다.[4][5] 요구사항은 일반적으로 요약 목록을 포함할 수 있으며, 자연어 문서, 사용자 시나리오, 사용자 스토리, 프로세스 명세 및 데이터 모델을 포함할 수 있다.

3. 요구사항 분석 기법

요구사항 분석에는 다양한 기법이 활용될 수 있다. 분석가는 고객으로부터 요구사항을 이끌어내기 위해 여러 기술을 사용하는데, 전통적으로는 인터뷰를 하거나 포커스 그룹과의 워크숍을 통해 요구사항 목록을 작성하는 방법을 사용했다. 더 발전된 기술로는 프로토타이핑이나 유스 케이스 작성 등이 있다.[4][5] 분석가는 이러한 기술들을 적절히 조합하여 고객의 요구사항을 충족시켜야 한다.

개념적으로 요구사항 분석은 다음 세 가지 활동을 포함한다.[4][5]


  • 요구사항 도출: 고객 및 사용자와의 대화를 통해 요구사항을 파악한다.
  • 요구사항 분석: 요구사항의 명확성, 완전성, 일관성 등을 검토하고, 모순이나 문제점을 해결한다.
  • 요구사항 기록: 요구사항을 다양한 형식(자연어 문서, 유스 케이스, 사용자 스토리 등)으로 문서화한다.


요구사항 분석은 시간이 오래 걸리고, 섬세한 심리적 기술이 필요할 수 있다. 새로운 시스템은 환경과 사람들 간의 관계를 변화시키므로, 모든 이해관계자를 식별하고, 그들의 요구를 고려하며, 새로운 시스템의 결과를 이해시키는 것이 중요하다.

3. 1. 이해관계자 인터뷰

이해관계자 인터뷰는 요구사항 분석의 전형적인 기법이다. 투입 공수와의 관계를 고려하여 이해관계자 선택이 일반적으로 필요하다. 인터뷰를 통해 프로젝트 시작 시점에는 예상하지 못했던 요구사항이 드러나고, 개별 요구사항 간에 모순이 발생하기도 한다.

3. 2. 요구사항 워크숍 (JRD)

요구사항 워크숍(JRD, Joint Requirement Development)은 여러 이해관계자들이 모여 토론을 통해 요구사항을 도출하고 분석하는 기법이다. 퍼실리테이터가 논의를 주도하고, 서기가 내용을 기록한다.[1]

JRD 세션은 관계자들이 집중할 수 있는 환경에서 진행하는 것이 바람직하다. 사회자는 논의가 벗어나지 않도록 주의하며, 서기는 논의 내용을 기록한다. 사회자는 프로젝터와 그림 작성 소프트웨어나 종이와 마커를 이용한 자료를 사용한다. 사회자는 개별 요구사항의 우선순위 부여가 참가자의 개성에 너무 의존하지 않도록 주의해야 한다.[1]

요구사항은 개별 이해관계자가 알지 못하는, 여러 기능에 걸쳐 영향을 미치는 경우가 많으며, 이해관계자 인터뷰에서 놓치거나 불완전하게 정의되는 경우가 많다. 이러한 영향은 훈련된 퍼실리테이터(비즈니스 분석가)가 주도하는 통제된 환경에서 JRD 세션을 통해 도출할 수 있다. 이 세션에서 이해관계자는 요구사항을 도출하고, 세부 사항을 분석하며, 여러 기능 간의 영향을 파악하기 위해 토론에 참여한다. 전담 기록자는 토론 내용을 기록하여, 비즈니스 분석가가 세션 목표에 부합하는 적절한 요구사항을 생성하도록 돕는다.[1]

JRD 세션은 공동 애플리케이션 설계 세션과 유사하다. 전자는 설계를 안내하는 요구사항을 도출하는 반면, 후자는 도출된 요구사항을 충족하기 위해 구현될 특정 설계 기능을 도출한다.[1]

3. 3. 계약형 요구사항 목록

계약형 요구사항 목록은 시스템이 만족해야 할 요구사항을 목록 형태로 작성하는 전통적인 방법이다. 복잡한 시스템의 경우, 이러한 요구사항 목록은 수백 페이지에 달할 수 있다.

계약형 요구사항 목록의 장점과 단점은 다음과 같다.

장점
단점


3. 4. 측정 가능한 목표

최고의 프로젝트에서는 요구사항 목록을 단서로만 취급하고, "왜 이런 요구가 나왔는가"를 반복적으로 질문하여 진정한 비즈니스 목적을 밝혀낸다. 그리고 관계자와 개발자는 각 목표의 달성 상황을 측정하기 위한 기준을 설정한다. 이러한 목표는 개별적인(기준이 없는) 요구 목록보다 변화하지 않는다. 중요한 목표가 달성되었을 때, 빠른 프로토타이핑과 개발을 통해 프로젝트 중간에도 관계자에게 성과로서 제공하는 경우가 있다.

3. 5. 프로토타이핑

프로토타입은 아직 구축되지 않은 애플리케이션을 사용자가 시각화할 수 있도록 다른 컴퓨터 프로그램의 속성 일부를 나타내는 컴퓨터 프로그램이다. 프로토타입의 일반적인 형태는 목업으로, 미래의 사용자 및 기타 이해 관계자가 시스템의 모습을 파악하는 데 도움이 된다.[4][5] 프로토타입은 애플리케이션을 구축하기 전에 애플리케이션의 측면을 보고 공유할 수 있으므로 설계 결정을 더 쉽게 내릴 수 있다. 사용자와 개발자 간의 의사소통에 있어 프로토타입의 도입으로 큰 개선이 이루어졌으며, 애플리케이션의 초기 모습은 이후 변경 사항을 줄여 전체 비용을 상당히 절감했다.

프로토타입은 평면 다이어그램 (종종 와이어프레임 모델이라고 함) 또는 합성 기능을 사용하는 작동하는 애플리케이션일 수 있다. 와이어프레임은 다양한 그래픽 디자인 문서로 만들어지며, 최종 소프트웨어에 그래픽 디자인이 적용될 것으로 예상되는 경우 디자인에서 모든 색상을 제거하는 경우가 많다 (예: 회색조 색상 팔레트 사용). 이는 프로토타입이 애플리케이션의 최종 시각적 모양과 느낌을 나타내는지 여부에 대한 혼란을 방지하는 데 도움이 된다.

3. 6. 유스 케이스

유스 케이스는 사용자가 시스템을 사용하여 특정 목표를 달성하는 과정을 시나리오 형태로 기술하는 방법으로, 일반적으로 소프트웨어를 포함하는 시스템의 기능 요구 사항을 문서화하는 데 사용된다.[4][5]

유스 케이스는 새로운 시스템이나 변경되는 시스템의 기능 요구사항을 문서화하기 위한 구조이다. 각 유스 케이스는 특정 비즈니스 목표를 달성하기 위해 시스템이 사용자 또는 다른 시스템과 상호 작용하는 방식을 전달하는 일련의 시나리오를 제공한다. 유스 케이스는 기술적인 전문 용어를 피하고, 대신 최종 사용자 또는 도메인 전문가의 언어를 선호하며, 종종 요구 사항 엔지니어와 이해 관계자가 공동으로 작성한다.[4][5]

유스 케이스는 시스템의 내부 작동 방식이나 구현 방식을 설명하지 않고, 순차적인 가정을 하지 않으면서 작업을 수행하는 데 필요한 단계를 보여준다. 1990년대에 기능적 요구사항 명세를 파악하는 기법으로 빠르게 확산되었으며, 특히 객체 지향 세계에서 두드러졌지만, 객체 지향 시스템에 국한된 것은 아니다.[4][5]

각 유스 케이스는 하나의 비즈니스 목표나 태스크를 달성하는 방법을 묘사하며, 전통적인 소프트웨어 공학의 관점에서 보면, 하나의 유스 케이스는 시스템의 하나의 기능을 묘사한다고 할 수 있다. 많은 소프트웨어 프로젝트에서는 시스템 전체를 기술하는 데 수십에서 수백 개의 유스 케이스가 필요하다.

유스 케이스는 시스템을 "블랙 박스"로 취급하여 시스템 외부에서 관찰할 수 있는 상호 작용을 다루며, 이를 통해 요구사항 명세의 기술을 간략화하고, 기능 구현에 대한 전제를 배제한다.

유스 케이스는 다음과 같이 기술되어야 한다.[4][5]

  • 비즈니스 목표를 달성하기 위한 비즈니스 태스크를 기술한다.
  • 적절한 상세도로 기술된다.
  • 소프트웨어 개발자가 한 번의 릴리스로 구현할 수 있는 정도의 분량이다.


유스 케이스는 기능 요구사항 명세에는 좋은 기법이지만, 비기능 요구사항 명세에는 적합하지 않다. 그러나 성능 엔지니어링에서는 중요한 유스 케이스에는 그에 대응하는 비기능 요구사항이 존재한다고 여겨진다.

3. 7. 사용자 스토리

애자일 소프트웨어 개발에서는 요구사항 목록 대신 사용자 스토리를 사용하여 일상적인 언어로 요구사항을 제안한다.[4][5] 사용자 스토리는 사용자의 관점에서 시스템에 대한 요구사항을 간단한 문장으로 표현하는 방법이다.

4. 요구사항 명세

요구사항 명세는 요구사항 분석의 결과물을 종합하여 시스템이 만족해야 할 기능 및 비기능 요구사항을 상세하게 기술한 문서이다. 이는 현재 상태의 비즈니스 요구 사항에 대한 발견 결과를 종합하고, 이러한 요구 사항을 평가하여 초점의 솔루션 범위 내에서 요구 사항을 충족하기 위해 필요한 사항을 결정하고 명시하는 과정이다. 발견, 분석 및 명세는 현재(as-is) 상태에서 미래(to-be) 상태로 이해를 옮긴다.

요구사항 명세는 실현될 미래 상태의 전체 폭과 깊이를 다룰 수 있으며, 우선순위가 높은 소프트웨어 시스템 버그 수정 및 개선과 같이 특정 격차를 채우는 데 초점을 맞출 수도 있다. 모든 대규모 비즈니스 프로세스는 거의 항상 소프트웨어 및 데이터 시스템과 기술을 사용하므로 요구사항 명세는 종종 소프트웨어 시스템 구축, 구매, 클라우드 컴퓨팅 전략, 제품 또는 장치의 임베디드 소프트웨어 또는 기타 기술과 관련된다. 요구사항 명세의 더 넓은 정의는 교육, 문서 안내, 인력, 마케팅 전략, 장비, 공급품 등과 같은 모든 솔루션 전략 또는 구성 요소를 포함하거나 초점을 맞춘다.

개념적으로 요구사항 분석에는 다음 세 가지 활동이 포함된다.


  • 요구 사항 수집: 고객이나 사용자와의 대화를 통해 요구 사항을 파악한다.
  • 요구 사항 분석: 필요에 따라 요구 사항을 명확히 하고 보완하며, 모순점이나 문제점을 밝힌다.
  • 요구 사항 기록: 요구 사항을 문서화한다. 문서 형식에는 일반적인 자연어 문서 외에 유스케이스, 사용자 스토리 등이 있다.


요구사항 분석은 시간이 오래 걸리고 인내심을 필요로 하는 경우가 있으며, 미묘한 심리적 기술이 필요하기도 하다. 새로운 시스템은 인간 관계나 환경을 바꿀 수 있으므로 관계자 모두를 특정해두는 것도 중요하며, 관계자 모두의 요구를 파악하는 동시에, 그들이 시스템과 어떻게 관련되는지를 이해하고 있는지 확인할 필요가 있다. 분석가는 고객으로부터 요구 사항을 수집하기 위해 몇 가지 기법을 활용한다. 인터뷰나 포커스 그룹(요구사항 워크숍)을 통해 요구사항 목록을 작성하는 것은 오래된 기법이다. 비교적 새로운 기법으로는 프로토타이핑과 유스케이스가 있다. 필요에 따라 분석가는 이러한 기법들을 활용하여 관계자의 요구 사항을 정확하게 파악한다. 이를 통해 비즈니스 요구에 맞는 시스템이 개발된다.[1]

4. 1. 소프트웨어 요구사항 명세 (SRS)

'''소프트웨어 요구사항 명세'''는 개발 대상 시스템의 동작을 완벽하게 기술한 것이다. 여기에는 해당 소프트웨어와 사용자의 모든 상호 작용을 기술한 유스 케이스(기능 요구사항 명세)도 포함된다. 유스 케이스 외에도 비기능 요구사항 명세도 포함되는데, 이는 설계 및 구현에 대한 일종의 제한(성능 요구사항, 품질 요구사항, 설계상의 제약 등)이다.

소프트웨어 요구사항 명세 기술에 대한 권장 방법은 IEEE 830-1998에 제시되어 있다. 이 표준은 소프트웨어 요구사항 명세의 가능한 구조, 바람직한 목차, 품질 등에 대해 설명하고 있다.

5. 요구사항의 종류

요구사항은 다양한 기준으로 분류될 수 있다. 다음은 기술적 관리와 관련된 일반적인 요구사항 분류이다.[1]


  • 고객 요구사항: 시스템의 목적, 주어진 환경과 제한 조건, 변경의 유효성과 적합성의 관점에서 시스템의 기대 사항을 정의하는 사실 및 가정을 서술한 것이다.
  • 성능 요구사항: 어떤 기능이 동작해야 하는 한계를 정의한다. 이는 보통 자료의 양이나 질, 동작의 적시성과 민첩성 등의 척도로 기술된다.
  • 설계 요구사항
  • 유도된 요구사항
  • 할당된 요구사항

5. 1. 기능 요구사항

기능 요구사항은 시스템이 제공해야 할 기능, 서비스, 동작 등을 정의하며, 반드시 구현되어야 할 필수적인 작업과 동작을 설명한다.[1]

기능 요구 사항은 수행해야 하는 작업, 행동 또는 활동을 식별한다. 기능 요구 사항 분석은 기능 분석의 최상위 기능으로 사용된다.[1]

요구사항 분석은 개념적으로 다음 세 가지 활동을 포함한다.

  • 요구 사항 수집: 고객이나 사용자와의 대화를 통해 요구 사항을 파악한다.
  • 요구 사항 분석: 필요에 따라 요구 사항을 명확히 하고 보완하며, 모순점이나 문제점을 밝힌다.
  • 요구 사항 기록: 요구 사항을 문서화한다. 문서 형식에는 일반적인 자연어 문서 외에 유스케이스, 사용자 스토리 등이 있다.


요구사항 분석은 시간이 오래 걸리고 인내심을 필요로 하는 경우가 있으며, 미묘한 심리적 기술이 필요하기도 하다. 새로운 시스템은 인간 관계나 환경을 바꿀 수 있으므로 관계자 모두를 특정하는 것이 중요하며, 그들의 요구를 파악하고 시스템과의 관련성을 이해하고 있는지 확인해야 한다. 분석가는 고객으로부터 요구 사항을 수집하기 위해 인터뷰, 포커스 그룹 (요구사항 워크숍), 프로토타이핑, 유스케이스 등 다양한 기법을 활용하여 관계자의 요구 사항을 정확하게 파악하고, 이를 통해 비즈니스 요구에 맞는 시스템을 개발한다.

5. 2. 비기능 요구사항

비기능 요구사항은 특정 동작보다는 시스템의 작동을 판단하는 데 사용할 수 있는 기준을 명시하는 요구사항으로, 전체 시스템의 동작을 평가하는 척도를 정의한다.[1] 성능 요구사항이 이에 해당한다.[1]

5. 3. 사업 요구사항

기업 또는 조직의 목표 달성을 위해 시스템이 갖춰야 할 상위 수준의 요구사항이다.[1] 이는 상세 기능에 대한 언급 없이, 비즈니스 수준의 목표를 진술한 것이며, 일반적으로 비즈니스 성과를 달성하기 위해 필요한 상위 수준의 기능(소프트웨어 및/또는 하드웨어)이다.[1]

5. 4. 고객 요구사항

시스템의 목적, 주어진 환경과 제한 조건, 변경의 유효성과 적합성의 관점에서 시스템의 기대 사항을 정의하는 사실 및 가정을 서술한 것이다(MOE/MOS).[1] 고객은 시스템 엔지니어링의 8가지 주요 기능을 수행하는 사람들로, 핵심 고객으로서 운영자에 특별한 중점을 둔다. 운영 요구 사항은 기본 요구 사항을 정의하며, 최소한 다음 질문에 답한다.[1]

질문내용
운영 분배 또는 배치시스템은 어디에서 사용될 것인가?
임무 프로필 또는 시나리오시스템은 어떻게 임무 목표를 달성할 것인가?
성능 및 관련 매개변수임무를 수행하는 데 필요한 주요 시스템 매개변수는 무엇인가?
활용 환경다양한 시스템 구성 요소는 어떻게 사용될 것인가?
효과 요구 사항시스템은 임무를 수행하는 데 얼마나 효과적이거나 효율적이어야 하는가?
운영 수명 주기시스템은 사용자에 의해 얼마나 오랫동안 사용될 것인가?
환경시스템이 효과적인 방식으로 작동할 것으로 예상되는 환경은 무엇인가?


5. 5. 아키텍처 요구사항

시스템 아키텍처에서 시스템이 무엇을 해야 하는지를 설명하는 것이 아키텍처 요구사항이다.

5. 6. 행위 요구사항

행동 요구 사항은 시스템의 필요한 행동을 식별하여 무엇을 해야 하는지 설명한다.

5. 7. 성능 요구사항

성능 요구사항은 시스템이 특정 기능을 수행할 때 어느 정도의 한계를 가져야 하는지를 정의한다. 이는 자료의 양이나 질, 동작의 적시성과 민첩성 등 다양한 척도로 측정된다.[1]

성능 요구사항은 임무 또는 기능이 얼마나 잘 실행되어야 하는지를 나타내며, 일반적으로 양, 품질, 범위, 적시성, 준비태세와 같은 요소들로 측정된다. 요구사항 분석 과정에서 성능 요구사항은 시스템 수명 주기의 각 요소를 바탕으로 모든 기능에 걸쳐 상호작용적으로 개발된다. 또한, 추정의 확실성, 시스템 성공에 대한 중요도, 그리고 다른 요구사항과의 관계 등 다양한 측면에서 성능 요구사항의 특성이 결정된다.[1]

5. 8. 설계 요구사항

시스템 설계 및 구현 단계에서 고려해야 할 제약 조건 등을 기술하는 요구사항이다.[1]

5. 9. 유도된 요구사항

상위 수준의 요구 사항에서 파생되거나 변환된 요구 사항이다. 예를 들어, 장거리 또는 고속에 대한 요구 사항은 저중량에 대한 설계 요구 사항으로 이어질 수 있다.[1]

5. 10. 할당된 요구사항

요구사항은 상위 수준의 요구사항을 여러 하위 수준의 요구사항으로 분할하거나 할당하여 설정한다. 예를 들어, 두 개의 하위 시스템으로 구성된 약 45.36kg짜리 품목은 두 개의 하위 수준 품목에 대해 각각 약 31.75kg와 약 13.61kg의 무게 요구사항을 가질 수 있다.[1]

6. 이해관계자 식별 및 관리

요구사항 분석은 지루하고 힘든 과정일 수 있으며, 섬세한 심리적 기술이 필요하다. 새로운 시스템은 환경과 사람들 간의 관계를 변화시키기 때문에, 모든 이해관계자를 식별하고 그들의 요구를 모두 고려하는 것이 중요하다. 또한, 새로운 시스템이 그들에게 어떤 영향을 미치는지 이해시키는 것도 중요하다.[1]

분석가는 고객으로부터 요구사항을 이끌어내기 위해 여러 가지 기술을 사용할 수 있다. 전통적으로는 면담을 하거나 포커스 그룹과의 워크숍을 통해 요구사항 목록을 작성하는 방법을 사용해 왔다. 최근에는 프로토타이핑이나 유즈 케이스 작성과 같은 발전된 기술도 활용된다. 분석가는 이러한 기술들을 적절히 조합하여 고객의 요구사항을 정확하게 파악해야 한다.[1]

6. 1. 이해관계자 유형

이해관계자 분석에서 시스템에 유효한 이해관계를 가진 사람 또는 조직(회사와 표준 기구와 같은 법인)에 대한 논의를 볼 수 있다. 이들은 직간접적으로 시스템의 영향을 받을 수 있다.

1990년대에 새롭게 강조된 점은 '이해관계자' 식별에 대한 집중이었다. 이해관계자는 분석가를 고용하는 조직에만 국한되지 않는다는 인식이 점점 더 커지고 있다. 다른 이해관계자에는 다음이 포함된다.

  • 시스템을 운영하는 모든 사람 (정상 및 유지 보수 운영자)
  • 시스템의 혜택을 받는 모든 사람 (기능적, 정치적, 재정적 및 사회적 수혜자)
  • 시스템 구매 또는 조달에 관련된 모든 사람. 대량 시장 제품 조직에서는 제품 관리, 마케팅, 때로는 판매가 제품 개발을 안내하기 위해 대리 소비자(대량 시장 고객) 역할을 한다.
  • 시스템의 측면을 규제하는 조직 (재정, 안전 및 기타 규제 기관)
  • 시스템에 반대하는 사람 또는 조직 (부정적 이해관계자, 오용 사례 참조)
  • 설계 중인 시스템과 인터페이스하는 시스템을 담당하는 조직
  • 분석가가 시스템을 설계하는 조직과 수평적으로 통합되는 조직

6. 2. 한국적 특수성

1990년대에 들어 특히 강조된 것은 "관계자"의 특정이다. "관계자"란 단순히 해당 시스템을 발주한 기업의 사원에만 국한되지 않는다는 점에 유의해야 한다.

한국의 경우, 대기업 중심의 경제 구조, 빠른 기술 변화, 높은 교육 수준, 정부 규제 등의 특성을 고려하여 이해관계자를 식별하고 관리해야 한다. 특히, 더불어민주당의 관점에서는 노동조합, 시민단체 등 사회적 약자의 목소리를 경청하고, 공공 이익을 위한 요구사항을 반영하는 것이 중요하다. 그 외에 고려할 수 있는 "관계자"로는 다음과 같은 사람들이 있다.

  • 해당 기업과 대등한 관계에서 긴밀하게 협력하고 있는 (또는 앞으로 협력이 예정된) 기업
  • 어떤 사무 처리 부문
  • 조직상 상위에 있는 자

7. 요구사항 분석의 문제점 및 해결 방안

요구사항 분석은 지루하고 힘든 과정일 수 있으며, 섬세한 심리적 기술이 필요하다. 새로운 시스템은 환경과 사람들 간의 관계를 변화시키므로, 모든 이해 관계자를 식별하고 그들의 요구를 고려하며, 새로운 시스템의 결과를 이해시키는 것이 중요하다.

분석가는 고객으로부터 요구사항을 이끌어내기 위해 인터뷰, 포커스 그룹과의 워크숍, 요구사항 목록 작성, 프로토타이핑, 유즈 케이스 작성 등 다양한 기술을 사용한다. 분석가는 이러한 기술들을 적절히 조합하여 고객의 요구사항을 정확히 파악해야 한다.

7. 1. 이해관계자 관련 문제

스티브 맥코넬은 그의 저서 《래피드 개발》에서 사용자가 요구사항 수집을 방해할 수 있는 여러 가지 방법을 다음과 같이 설명한다.

  • 사용자는 자신이 무엇을 원하는지 이해하지 못하거나 요구 사항에 대한 명확한 아이디어가 없을 수 있다.
  • 사용자는 일련의 문서화된 요구 사항에 동의하지 않을 수 있다.
  • 사용자는 비용과 일정이 고정된 후 새로운 요구 사항을 주장한다.
  • 사용자와의 의사 소통이 느리다.
  • 사용자는 종종 검토에 참여하지 않거나 참여할 수 없다.
  • 사용자는 기술적으로 세련되지 않다.
  • 사용자는 개발 프로세스를 이해하지 못한다.
  • 사용자는 현재 기술에 대해 알지 못한다.


이러한 문제들은 시스템 또는 제품 개발이 시작되었음에도 사용자 요구 사항이 계속 변경되는 상황으로 이어질 수 있다.

7. 2. 기술자/개발자 관련 문제

기술자와 최종 사용자는 서로 다른 어휘를 사용할 수 있어, 완성된 제품이 나올 때까지 서로 완전히 합의했다고 잘못 생각할 수 있다.[1] 기술자나 개발자는 고객의 요구 사항에 맞는 시스템을 개발하기보다, 기존 시스템이나 모델에 요구 사항을 맞추려고 시도할 수 있다.[1] 분석을 기술자나 프로그래머가 수행하고 대상 분야의 전문가가 참여하지 않아 사용자의 요구가 제대로 반영되지 않는 경우가 있다.[1]

7. 3. 해결 방안

1990년대에 도입된 프로토타이핑, UML, 유스 케이스, 애자일 소프트웨어 개발과 같은 기술들은 이전 방법에서 발생한 문제에 대한 해결책으로 의도되었다.[1] 비즈니스 분석 전문가 또는 시스템 분석 전문가를 활용하는 것도 해결 방안 중 하나였다.[1]

또한 새로운 종류의 애플리케이션 시뮬레이션 또는 애플리케이션 정의 도구들이 시장에 진입했다.[1] 이러한 도구들은 비즈니스 사용자와 IT 조직 간의 커뮤니케이션 격차를 해소하고, 코드를 생성하기 전에 애플리케이션을 '테스트 마케팅'할 수 있도록 설계되었다.[1] 이러한 도구들은 다음과 같은 기능을 제공한다.[1]

  • 애플리케이션 흐름을 스케치하고 대안을 테스트할 수 있는 전자 칠판[1]
  • 비즈니스 로직 및 데이터 요구 사항을 캡처하는 기능[1]
  • 최종 애플리케이션을 밀접하게 모방하는 고품질 프로토타입을 생성하는 기능[1]
  • 상호 작용성[1]
  • 상황별 요구 사항 및 기타 주석을 추가하는 기능[1]
  • 원격 및 분산 사용자가 시뮬레이션을 실행하고 상호 작용할 수 있는 기능[1]

참조

[1] 간행물 Systems Engineering Fundamentals http://www.dau.mil/p[...] Defense Acquisition University Press 2011-07-22
[2] 서적 Requirements Engineering: Processes and Techniques https://archive.org/[...] John Wiley and Sons
[3] 서적 Guide to the software engineering body of knowledge http://www.swebok.or[...] IEEE Computer Society Press 2007-02-08
[4] 논문 Improving requirements elicitation in large-scale software projects with reduced customer engagement: a proposed cost-effective model https://link.springe[...] 2024-09-01
[5] 논문 Requirements elicitation techniques: a systematic literature review based on the maturity of the techniques https://onlinelibrar[...] 2018-08-01
[6] 웹사이트 Why You Need Stakeholder Identification and Analysis {{!}} Acorn https://acorn.works/[...] 2022-06-08


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com