요건 분석

Requirements analysis
이 주제에 대한 자세한 내용은 요구사항 엔지니어링을 참조하십시오.
요구사항 분석에 [1]대한 시스템 엔지니어링 관점.
시리즈의 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
프랙티스
도구들
지식의 표준과 본문
용어집
개요

시스템 엔지니어링 및 소프트웨어 엔지니어링에서 요건 분석은 소프트웨어 또는 시스템 [2]요건을 분석, 문서화, 검증 및 관리하는 다양한 이해관계자의 상충될 수 있는 요건을 고려하여 신규 또는 변경된 제품 또는 프로젝트를 충족하기 위한 요구 또는 조건을 결정하는 작업에 초점을 맞춥니다.

요건 분석은 시스템 또는 소프트웨어 프로젝트의 [3]성패에 매우 중요합니다.요건은 문서화되어 실행가능, 측정가능, 테스트가능, 추적가능, 특정된 비즈니스 요구 또는 기회에 관한 것으로 시스템 설계에 충분한 상세 수준으로 정의되어야 합니다.

개요

개념적으로 요구사항 분석에는 세 가지 유형의 [citation needed]활동이 포함됩니다.

  • 요구사항 도출: (프로젝트 헌장 또는 정의 등), 비즈니스 프로세스 문서 및 이해관계자 인터뷰이를 요건 수집 또는 요건 검출이라고도 합니다.
  • 기록 요건: 요건은 요약 리스트를 포함한 다양한 형태로 문서화할 수 있습니다.또한 자연어 문서, 사용 사례, 사용자 사례, 프로세스 사양 및 데이터 모델을 포함한 다양한 모델을 포함할 수 있습니다.
  • 요건 분석: 기재된 요건이 명확, 완전, 중복, 간결, 유효, 일관성 및 모호하지 않은지 여부를 판단하고 명백한 모순을 해결합니다.분석에는 사이징 요건도 포함될 수 있습니다.

요구사항 분석은 많은 섬세한 심리 기술이 수반되는 길고 피곤한 과정이 될 수 있습니다.새로운 시스템은 환경과 사람 간의 관계를 변화시키므로 모든 이해당사자를 특정하고 그들의 모든 요구를 고려하여 새로운 시스템의 의미를 이해하는 것이 중요합니다.분석가는 고객으로부터 요구사항을 도출하기 위해 몇 가지 기술을 사용할 수 있습니다.여기에는 시나리오 개발(신속한 방법으로 사용자 사례로 표현됨), 사용 사례 식별, 직장 관찰 또는 민족지학 사용, 인터뷰 또는 포커스 그룹(이 문맥에서 요구사항 워크숍 또는 요구사항 검토 세션으로 더 적절하게 명명됨) 및 요구사항 목록 작성 등이 포함될 수 있습니다.프로토타이핑은 이해관계자에게 시연할 수 있는 예제 시스템을 개발하는 데 사용될 수 있습니다.분석가는 필요에 따라 이들 방법을 조합하여 이해관계자의 정확한 요건을 확립하여 비즈니스 요구를 충족하는 시스템을 [citation needed]제작합니다.이러한 방법 및 기타 방법을 통해 요구사항의 품질을 개선할 수 있습니다.

  • 시각화.시각화 및 시뮬레이션 등 원하는 최종 제품을 보다 잘 이해할 수 있는 도구를 사용합니다.
  • 템플릿의 일관된 사용.요건을 문서화하기 위한 일관된 모델 및 템플릿 세트 생성
  • 의존 관계를 문서화합니다.요건 간의 의존관계와 상호관계 및 모든 가정과 집합의 문서화.

요건 분석 항목

이해관계자 식별

시스템에 유효한 이해관계가 있는 사람 또는 조직(회사, 표준기관 등)에 대한 논의는 이해관계자 분석을 참조하십시오.직접적 또는 간접적으로 영향을 받을 수 있습니다.1990년대에 새롭게 강조된 주요 사항은 이해관계자 식별이었다.이해관계자는 분석가를 고용하는 조직에만 국한되지 않는다는 것이 점차 인식되고 있습니다.기타 이해관계자는 다음과 같습니다.

  • 시스템을 운영하는 모든 사람(정상 및 유지관리 작업자)
  • 제도로부터 이익을 얻는 사람(기능, 정치, 재정 및 사회적 수혜자)
  • 시스템 구입 또는 구입에 관련된 모든 사람.매스마켓 제품 조직에서는 제품 관리, 마케팅 및 때때로 판매가 대리 소비자(매스마켓 고객) 역할을 하여 제품 개발을 안내합니다.
  • 시스템의 측면을 규제하는 조직(금융, 안전 및 기타 규제 기관)
  • 시스템에 반대하는 사람 또는 조직(부정적 이해관계자, 오남용 사례 참조)
  • 설계 중인 시스템과 인터페이스하는 시스템을 책임지고 있는 조직.
  • 분석가가 시스템을 설계하는 조직과 수평적으로 통합되는 조직.

공동요건개발(JRD) 세션

요구사항은 종종 개별 이해관계자가 알지 못하는 교차 기능적 영향을 미치며 이해관계자 면담에서 종종 누락되거나 불완전하게 정의된다.이러한 기능 간 영향은 훈련을 받은 퍼실리테이터(비즈니스 분석가)에 의해 촉진되는 통제된 환경에서 JRD 세션을 실시함으로써 도출할 수 있습니다.이 환경에서는 이해관계자가 논의에 참여하여 요건을 도출하고 세부사항을 분석하며 기능 간 영향을 파악할 수 있습니다.토론을 문서화하기 위해 전담 서기가 상주해야 하며, 비즈니스 분석가가 세션 목표에 부합하는 적절한 요건을 생성하는 방향으로 토론을 이끌 수 있도록 해야 합니다.

JRD 세션은 공동 애플리케이션 설계 세션과 유사합니다.전자의 경우 세션은 설계를 안내하는 요건을 도출하는 반면 후자는 도출된 요건을 충족하면서 구현해야 할 특정 설계 특징을 도출한다.

계약 스타일의 요건 리스트

요건을 문서화하는 기존의 방법 중 하나는 계약 스타일의 요건 리스트입니다.복잡한 시스템에서는 이러한 요건 리스트가 수백 페이지에 달할 수 있습니다.

적절한 비유는 엄청나게 긴 쇼핑 리스트일 것이다.그러한 목록은 현대 분석에서 매우 인기가 없다; 그들이 그들의 목표를[citation needed] 달성하는 데 극적으로 실패하였음이 입증되었기 때문이다; 그러나 그것들은 여전히 오늘날까지 보여진다.

힘

  • 요건 체크리스트를 제공합니다.
  • 프로젝트 스폰서와 개발자 사이에 계약을 체결합니다.
  • 대규모 시스템의 경우 낮은 수준의 요건을 도출할 수 있는 높은 수준의 설명을 제공할 수 있습니다.

약점

  • 이러한 목록은 수백 페이지에 달할 수 있습니다.목적의 어플리케이션에 대한 알기 쉬운 설명으로 기능하는 것은 아닙니다.
  • 이러한 요구사항은 모든 요구사항을 추상화하므로 맥락이 거의 없다.비즈니스 분석가는 동봉된 설계 문서에 요건에 대한 컨텍스트를 포함할 수 있습니다.
    • 이 추상화는 요구사항이 어떻게 적합하거나 함께 작동하는지를 설명하기 위한 것이 아닙니다.
    • 목록에는 요구사항 간의 관계 및 종속성이 반영되지 않을 수 있습니다.목록을 통해 각 항목의 우선순위를 쉽게 지정할 수 있지만, 컨텍스트에 맞지 않는 항목 하나를 제거하면 전체 사용 사례 또는 비즈니스 요구사항이 무용지물이 될 수 있습니다.
    • 이 리스트는, 목적의 시스템/애플리케이션의 설계에 있어서의 영향을 보다 잘 이해하기 위해서, 이해관계자와 요건을 주의 깊게 검토할 필요는 없습니다.
  • 단순히 목록을 만든다고 해서 완전한 목록이 보장되는 것은 아닙니다.비즈니스 분석가는 실질적으로 포괄적인 목록을 발견 및 수집하기 위해 성실하게 노력해야 하며, 누락된 요구사항을 지적하기 위해 이해관계자에게 의존해야 합니다.
  • 이러한 리스트는 이해관계자와 개발자 간에 잘못된 상호 이해를 불러일으킬 수 있습니다.비즈니스 분석가는 번역 프로세스에 매우 중요합니다.
  • 개발 및 테스트 프로세스가 시작되기 전에 모든 기능 요건을 파악하는 것은 거의 불가능합니다.이러한 목록이 불변의 계약으로 취급될 경우 개발 프로세스에서 발생하는 요구사항은 논란의 여지가 있는 변경 요청을 발생시킬 수 있습니다.

요건 리스트 대체

요구 사항 목록의 대안으로 신속한 변화를 위한 소프트웨어 개발은 사용자 사례를 사용하여 일상적인 언어로 요구 사항을 제안합니다.

측정 가능한 목표

주요 기사: 목표 모델링

베스트 프랙티스는, 요건의 구성 리스트를 힌트로 삼아, 실제의 비즈니스 목적이 밝혀질 때까지 「왜」라고 반복해 묻습니다.그런 다음 이해관계자와 개발자는 지금까지 달성한 각 목표의 수준을 측정하기 위한 테스트를 고안할 수 있습니다.이러한 목표는 구체적이지만 측정되지 않은 요구사항의 긴 목록보다 더 느리게 변화한다.측정되고 중요한 목표의 작은 세트가 설정되면 프로젝트의 절반이 끝나기 훨씬 전에 실질적인 이해관계자 가치를 제공하기 위해 신속한 프로토타이핑 및 짧은 반복 개발 단계가 진행될 수 있습니다.

시제품

주요 기사:소프트웨어 프로토타이핑

프로토타입은 다른 컴퓨터 프로그램의 속성 일부를 보여주는 컴퓨터 프로그램으로, 사용자가 아직 구성되지 않은 애플리케이션을 시각화할 수 있도록 합니다.인기 있는 프로토타입의 형태는 목업입니다.목업은 미래의 사용자와 다른 이해관계자들이 시스템이 어떻게 보일지 알 수 있도록 도와줍니다.프로토타입을 사용하면 애플리케이션을 구축하기 전에 애플리케이션의 측면을 보고 공유할 수 있기 때문에 설계 결정을 쉽게 내릴 수 있습니다.프로토타입을 도입하면서 사용자와 개발자 간의 의사소통이 크게 개선되었습니다.애플리케이션을 초기에 볼 수 있었기 때문에 나중에 변경 사항이 적었기 때문에 전체적인 비용이 [citation needed]크게 절감되었습니다.

프로토타입은 평면 다이어그램(종종 와이어프레임이라고 함) 또는 합성 기능을 사용하는 작동 애플리케이션일 수 있습니다.와이어 프레임은 다양한 그래픽 설계 문서로 제작되며 최종 소프트웨어에서 그래픽 설계가 적용될 것으로 예상되는 경우 설계에서 모든 색상을 제거하는 경우가 많습니다(회색조 색상 팔레트 사용).이를 통해 프로토타입이 애플리케이션의 [citation needed]최종적인 시각적 모양과 느낌을 나타내는지에 대한 혼동을 방지할 수 있습니다.

사용 사례

주요 기사:사용 사례

유스케이스는 시스템의 기능요건을 문서화하는 구조입니다.보통 새로운 소프트웨어인지 변경되고 있는지 여부에 관계없이 소프트웨어가 관련되어 있습니다.각 사용 사례는 특정 비즈니스 목표를 달성하기 위해 시스템이 인간 사용자 또는 다른 시스템과 어떻게 상호작용해야 하는지를 전달하는 일련의 시나리오를 제공합니다.일반적으로 사용 사례는 기술 전문 용어를 사용하지 않고 최종 사용자 또는 도메인 전문가의 언어를 선호합니다.사용 사례는 대부분의 경우 요구사항 엔지니어와 이해 관계자가 공동으로 작성합니다.

사용 사례는 소프트웨어 또는 시스템의 동작을 설명하는 믿을 수 없을 정도로 단순한 도구입니다.사용 예에는 사용자가 소프트웨어 또는 시스템을 사용하는 방법에 대한 텍스트 설명이 포함되어 있습니다.사용 사례는 시스템의 내부 작동을 설명해서는 안 되며 시스템의 구현 방법을 설명해서는 안 됩니다.대신 순차적 가정 없이 작업을 수행하는 데 필요한 단계를 보여 줍니다.

요건사양서

요건 사양이란, 현재의 비즈니스 요구에 관한 검출 결과를 종합해, 이러한 요구에 대한 평가를 실시해, 초점을 맞춘 솔루션 범위내의 요구를 만족시키기 위해서 필요한 것을 특정하는 것입니다.검출, 분석 및 사양에 의해 이해는 현재 상태에서 미래의 상태로 이행됩니다.요건 사양은 실현해야 할 미래 상태의 전체 범위와 깊이를 망라하는 경우가 있습니다.또, 수정해야 할 소프트웨어 시스템의 우선적인 버그나 개선 사항 등, 특정의 갭을 메우는 것을 목표로 하는 경우도 있습니다.대규모 비즈니스 프로세스에서는 소프트웨어 및 데이터 시스템과 테크놀로지가 거의 항상 채용되고 있기 때문에 요건 사양은 소프트웨어 시스템 구축, 구매, 클라우드 컴퓨팅 전략, 제품 또는 디바이스에 내장된 소프트웨어 또는 기타 테크놀로지와 관련된 경우가 많습니다.요건 사양의 광범위한 정의에는 트레이닝, 문서 가이드, 담당자, 마케팅 전략, 기기, 서플라이 등 솔루션 전략 또는 컴포넌트가 포함됩니다.

요건의 종류

요건은 몇 가지 방법으로 분류됩니다.다음은 기술 [1]관리와 관련된 일반적인 요구사항 분류입니다.

비즈니스 요건
상세한 기능을 고려하지 않고 비즈니스 레벨의 목표를 기술합니다.이러한 기능은 일반적으로 비즈니스 성과를 달성하기 위해 필요한 높은 수준의 기능(소프트웨어 및/또는 하드웨어)입니다.
고객의 요건
미션 목표, 환경, 제약 및 효과 및 적합성 측정(MOE/MOS) 측면에서 시스템의 기대를 정의하는 사실과 가정 진술.고객은 시스템 엔지니어링의 8가지 주요 기능을 수행하는 고객이며, 운영자를 주요 고객으로 특별히 강조합니다.운용요건에 따라 기본적인 요구가 정의되며 적어도 다음 목록에 [1]제시된 질문에 답변합니다.
  • 운용 배포 또는 도입:시스템은 어디에 사용됩니까?
  • 미션 프로파일 또는 시나리오:시스템이 미션 목표를 어떻게 달성할 것인가?
  • 퍼포먼스 및 관련 파라미터:임무를 수행하기 위한 중요한 시스템 파라미터는 무엇입니까?
  • 사용 환경:다양한 시스템 컴포넌트를 어떻게 사용합니까?
  • 유효성 요건:시스템이 임무를 수행할 때 얼마나 효과적 또는 효율적이어야 하는가?
  • 운용 라이프 사이클:사용자가 시스템을 얼마나 오래 사용할 수 있습니까?
  • 환경:시스템이 효과적으로 작동해야 하는 환경은 무엇입니까?
아키텍처 요건
아키텍처 요건은 시스템에 필요한 시스템 아키텍처를 식별하여 수행해야 하는 작업을 설명합니다.
구조요건
구조적 요건은 시스템의 필요한 구조를 식별함으로써 무엇을 해야 하는지를 설명합니다.
동작요건
동작요건은 시스템의 필요한 동작을 식별함으로써 무엇을 해야 하는지를 설명합니다.
기능요건
기능요건은 수행해야 할 작업, 행동 또는 활동을 식별하여 수행해야 할 사항을 설명합니다.기능요건 분석은 기능분석의 [1]최상위 기능으로 사용됩니다.
기능하지 않는 요건
비기능적 요건은 특정 동작이 아닌 시스템 동작 판단에 사용할 수 있는 기준을 지정하는 요건입니다.
퍼포먼스 요건
임무 또는 기능을 수행해야 하는 범위. 일반적으로 수량, 품질, 범위, 적시성 또는 준비성의 관점에서 측정됩니다.요건 분석 중에는 시스템 라이프 사이클 요인에 따라 특정된 모든 기능에 걸쳐 퍼포먼스(어느 정도의 퍼포먼스) 요건이 인터랙티브하게 개발됩니다.또, 그 예측의 확실도, 시스템의 성공에 대한 중요도, 및 그 외의 요건과의 관계에 의해서 특징지어집니다.nts를 [1]클릭합니다.
설계 요건
제품의 "빌드 대상", "코드 대상" 및 "구매 대상" 요건과 기술 데이터 패키지 및 기술 [1]매뉴얼에 기재된 프로세스의 "실행 방법" 요건입니다.
파생 요건
더 높은 수준의 요구사항에서 암시되거나 변형된 요구사항입니다.예를 들어 장거리 또는 고속에 대한 요건은 [1]저중량에 대한 설계 요건이 될 수 있다.
할당된 요건
높은 수준의 요건을 여러 하위 수준의 요건으로 분할하거나 할당함으로써 확립되는 요건.예:두 개의 하위 시스템으로 구성된 100파운드 항목은 70파운드와 두 개의 하위 수준 [1]항목에 대해 30파운드의 중량 요건을 가질 수 있다.

잘 알려진 요구사항 분류 모델에는 Hewlett-Packard에서 개발된 FURPS 및 FURPS+가 있습니다.

요건 분석 문제

이해관계자의 문제

Steve McConnell은 저서 Rapid Development에서 사용자가 요구사항 수집을 억제할 수 있는 여러 가지 방법을 자세히 설명합니다.

  • 사용자가 원하는 것을 이해하지 못하거나 사용자가 자신의 요구 사항을 명확하게 알지 못함
  • 사용자는 일련의 서면 요건을 준수하지 않습니다.
  • 비용과 일정이 정해진 후 사용자가 새로운 요건을 요구함
  • 사용자와의 통신이 느리다
  • 사용자는 리뷰에 참여하지 않거나 참여할 수 없는 경우가 많다.
  • 사용자는 기술적으로 미숙하다
  • 사용자가 개발 프로세스를 이해하지 못함
  • 사용자는 현재의 테크놀로지에 대해 모른다.

이로 인해 시스템 또는 제품 개발이 시작되어도 사용자 요구 사항이 계속 변경되는 상황이 발생할 수 있습니다.

엔지니어/개발자의 문제

요건 분석 중 엔지니어와 개발자에 의해 발생할 수 있는 문제는 다음과 같습니다.

  • 코드 작성에 대한 자연스러운 경향으로 인해 요건 분석이 완료되기 전에 구현이 시작될 수 있으며, 이를 알게 되면 실제 요건을 충족하도록 코드가 변경될 수 있습니다.
  • 기술 담당자와 최종 사용자의 어휘는 다를 수 있습니다.결과적으로, 그들은 완제품이 공급될 때까지 완전히 일치한다고 잘못 생각할 수 있다.
  • 엔지니어와 개발자는 고객의 요구에 맞는 시스템을 개발하는 것이 아니라 기존 시스템 또는 모델에 맞는 요건을 만들려고 할 수 있습니다.

시도된 솔루션

통신 문제의 해결 방법 중 하나는 비즈니스 또는 시스템 분석 전문가를 고용하는 것입니다.

1990년대에 도입된 프로토타이핑, UML(Unified Modeling Language), 사용 사례 및 신속한 변화를 위한 소프트웨어 개발과 같은 기술도 이전 방법에서 발생하는 문제에 대한 해결책으로 사용됩니다.

또한 새로운 종류의 애플리케이션 시뮬레이션 또는 애플리케이션 정의 툴이 시장에 출시되었습니다.이러한 툴은, 비즈니스 유저와 IT조직간의 커뮤니케이션의 갭을 해소하는 것과 동시에, 코드를 작성하기 전에 애플리케이션을 「테스트 마케팅」할 수 있도록 설계되어 있습니다.이러한 툴의 장점은 다음과 같습니다.

  • 응용 프로그램 흐름을 스케치하고 대안을 테스트하기 위한 전자 화이트보드
  • 비즈니스 로직과 데이터 요구를 포착하는 능력
  • 최종 애플리케이션을 매우 잘 모방하는 충실도 높은 프로토타입을 생성할 수 있는 능력
  • 인터랙티브
  • 상황별 요건 및 기타 코멘트를 추가하는 기능
  • 원격 사용자 및 분산 사용자가 시뮬레이션을 실행하고 상호작용할 수 있는

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b c d e f g h Wayback Machine Defense Acquisition University Press, 2001에서 2011-07-22 시스템 엔지니어링 기초 자료 아카이브
  2. ^ Kotonya, Gerald; Sommerville, Ian (1998). Requirements Engineering: Processes and Techniques. Chichester, UK: John Wiley and Sons. ISBN 9780471972082.
  3. ^ Alain Abran; James W. Moore; Pierre Bourque; Robert Dupuis, eds. (March 2005). "Chapter 2: Software Requirements". Guide to the software engineering body of knowledge (2004 ed.). Los Alamitos, CA: IEEE Computer Society Press. ISBN 0-7695-2330-7. Retrieved 2007-02-08. It is widely acknowledged within the software industry that software engineering projects are critically vulnerable when these activities are performed poorly.

참고 문헌

외부 링크

Wikimedia Commons에는 요건 분석과 관련된 미디어가 있습니다.