필요

Requirement
이 기사는 제품 및 공정 개발에 관한 것입니다.그 외의 요건의 종류에 대해서는, 「니즈」 「의무」,「인텔리전스 요건」을 참조해 주세요.과거의 용법에 대해서는, 1513 의 스페인어 요건을 참조해 주세요.

제품 개발 및 프로세스 최적화에서 요구사항은 특정 설계, 제품 또는 프로세스가 충족하고자 하는 단일 문서화된 물리적 또는 기능적 요구입니다.일반적으로 시스템 엔지니어링, 소프트웨어 엔지니어링 또는 엔터프라이즈 엔지니어링 등 엔지니어링 설계에서 공식적인 의미로 사용됩니다.이는 고객, 조직, 내부 사용자 또는 기타 이해관계자에게 가치와 효용을 제공하기 위해 필요한(또는 경우에 따라서는 바람직한) 기능, 속성, 기능, 특성 또는 품질에 대해 설명할 수 있는 광범위한 개념입니다.요건은 다양한 수준의 특수성을 수반할 수 있다. 예를 들어, 요건 사양 또는 요건 "spec"(종종 부정확하게 "the" 사양/스펙이라고 불리지만 실제로는 다른 종류의 사양이 있다)은 명시적이고 매우 객관적인/명료한(종종 양적인) 요건(또는 때로는 요건자 집합)을 의미한다.ts) 소재, 디자인, 제품 또는 [1]서비스에 의해 충족되어야 한다.

일련의 요건은 제품 개발의 설계 단계에 대한 입력 자료로 사용됩니다.테스트는 특정 요건으로 거슬러 올라가야 하기 때문에 요건도 검증 프로세스에 중요한 입력이다.요구사항은 특정 프로젝트에 필요한 요소 및 기능을 보여줍니다.소프트웨어 개발의 반복적인 방법 또는 신속한 변화를 위한 방법을 사용할 경우, 시스템 요건은 설계 및 구현과 병행하여 점진적으로 개발됩니다.설계 및 구현에 앞서 폭포수 모델 요건이 개발됩니다.

용어의 기원

이 용어는 적어도 1960년대부터 [2]소프트웨어 엔지니어링 커뮤니티에서 사용되어 왔습니다.

IIBA(BABOK)[3]의 지식®버전 2의 비즈니스 분석 기관 가이드(Guide to the Business Analysis Body of Knowledge® version 2)에 따르면 요구 사항은 다음과 같습니다.

  1. 이해관계자가 문제를 해결하거나 목표를 달성하기 위해 필요한 조건 또는 능력.
  2. 계약서, 표준서, 사양서 또는 기타 정식으로 부과된 문서를 충족하기 위해 솔루션 또는 솔루션 컴포넌트가 충족하거나 보유해야 하는 조건 또는 능력.
  3. (1) 또는 (2)에서와 같은 조건 또는 능력을 문서화한 표현.

이 정의는 IEEE 610.12-1990: IEEE 표준 용어집에 기초하고 있습니다.[4]

제품과 프로세스의 요건

요건은 다음 두 가지 필드에 관련되어 있다고 할 수 있습니다.

  • 제품 요구 사항은 시스템 또는 제품의 속성을 규정합니다.
  • 프로세스 요건은 개발 조직이 수행해야 할 활동을 규정한다.예를 들어, 프로세스 요구사항은 따라야 하는 방법론과 조직이 준수해야 하는 제약 조건을 명시할 수 있습니다.

제품 요건과 프로세스 요건은 밀접하게 관련되어 있습니다.제품 요건은 프로세스 요건을 지원하기 위해 필요한 자동화를 지정하는 것이며 프로세스 요건은 제품 요건을 지원하기 위해 필요한 액티비티를 지정하는 것이라고 할 수 있습니다.예를 들어, 최대 판매 가격 요구사항(제품 요구사항)을 달성하기 위해 최대 개발 비용 요구사항(공정 요구사항)을 부과할 수 있다. 제품이 유지 가능한 요구사항(제품 요구사항)은 종종 특정 개발 스타일(예: 객체 지향 프로그램)을 따르도록 요구사항을 부과함으로써 해결된다.유형 변경 또는 검토/검사 프로세스(공정 요구 사항)를 선택합니다.

요건의 종류

요건은 일반적으로 개발 진행의 여러 단계에서 생성되는 유형으로 분류되며, 사용되는 전체 모델에 따라 분류된다.예를 들면, 다음의 스킴은, 국제 비즈니스 분석 연구소가 「비즈니스 분석 지식[5] 본체」에서 고안한 것입니다(「FURPS」나 「요건의 종류」도 참조).

아키텍처 요건
아키텍처 요건은 시스템 구조와 시스템 동작(시스템 아키텍처)의 필요한 통합을 식별함으로써 무엇을 해야 하는지를 설명합니다.
소프트웨어 엔지니어링에서는 이러한 요건을 아키텍처상 중요한 요건이라고 부릅니다.이것은 소프트웨어 시스템의 [6]아키텍처에 측정 가능한 영향을 미치는 요건이라고 정의됩니다.
비즈니스 요건
조직의 목표, 목표 또는 요구에 대한 개략적인 설명.일반적으로 조직이 실현하고 싶은 기회나 해결하려는 문제를 기술합니다.비즈니스 케이스에 자주 기재되어 있습니다.
사용자(스테크홀더) 요건
특정 이해관계자 또는 이해관계자 그룹의 요구에 대한 중간 수준의 진술.이들은 보통 누군가가 의도한 솔루션과 상호작용하기를 원하는 방법을 기술합니다.높은 수준의 비즈니스 요건과 보다 상세한 솔루션 요건 사이의 중간 지점 역할을 하는 경우가 많습니다.
기능(솔루션) 요건
일반적으로 솔루션에 필요한 기능, 동작 및 정보에 대한 자세한 설명입니다.예를 들어 텍스트 형식 지정, 숫자 계산, 신호 변조 등이 있습니다.기능이라고도 합니다.
서비스 품질(비기능) 요건
통상, 솔루션을 유효하게 유지할 필요가 있는 조건, 솔루션이 가지는 품질, 또는 솔루션이 동작할 [7]필요가 있는 제약에 관한 상세한 기술.예를 들어 신뢰성, 테스트성, 유지보수성, 가용성 등이 있습니다.특성, 제약 또는 특성이라고도 합니다.
구현(이행) 요건
일반적으로 기업의 현재 상태에서 원하는 미래 상태로의 이행을 가능하게 하기 위해서만 기능 또는 동작에 대한 자세한 설명이 필요하지만 그 이후에는 필요하지 않습니다.예를 들어 채용, 역할 변경, 교육, 시스템 간 데이터 이행 등이 있습니다.
규제 요건
법률(연방, 주, 시 또는 지역), 계약(약관 및 조건) 또는 정책(회사, 부서 또는 프로젝트 수준)에 의해 정의된 요건.

양호한 요건의 특징

우수한 요건의 특성은 다양한 저자에 의해 다양하게 설명되며, 각 저자는 일반적으로 일반적인 논의 또는 특정 기술 영역에 가장 적합한 특성을 강조한다.그러나 일반적으로 다음과 같은 특성이 [8]인정됩니다.[9]

특성. 설명.
유니터리(코히시브) 이 요건은 단 한 가지뿐입니다.
완성하다 요건은 한 곳에 명기되어 있어 정보가 누락되지 않습니다.
일관된 이 요건은 다른 요건과 모순되지 않으며 모든 권위 있는 외부 문서와 완전히 일치한다.
비결합(원자성) 요건은 원자성이며, 즉 결합을 포함하지 않는다.예: "우편 번호 필드는 미국 및 캐나다 우편 번호를 검증해야 한다"는 두 가지 개별 요구 사항으로 작성해야 합니다. (1) "우편 번호 필드는 미국 우편 번호를 검증해야 한다"와 (2) "우편 번호 필드는 캐나다 우편 번호를 검증해야 한다"입니다.
트레이서블 요건은 이해관계자가 기술하고 권위 있게 문서화된 비즈니스 요구의 전부 또는 일부를 충족합니다.
현재의 그 요구는 시간이 지나도 쓸모없게 되지 않았다.
명확. 요건은 기술 용어, 약어(요건 문서에 정의되어 있지 않은 한) 또는 기타 난해한 용어를 사용하지 않고 간결하게 기술되어 있습니다.주관적인 의견이 아닌 객관적인 사실을 표현하고 있습니다.그것은 오직 한 가지 해석에 의해 좌우된다.막연한 주어, 형용사, 전치사, 동사, 주관어 등은 피한다.부정적인 문장과 복합적인 문장은 피한다.
중요도 지정 많은 요구사항은 이해관계자 정의 특성을 나타내며, 그러한 특성이 없으면 중대하거나 치명적인 결함이 발생할 수 있다.기타 기능은 시간과 예산이 허락하는 경우 구현될 수 있는 기능을 나타냅니다.요건은 중요도 수준을 지정해야 합니다.
검증 가능 요건의 이행은 검사, 시연, 테스트(계기) 또는 분석(검증된 모델링 및 시뮬레이션 포함)과 같은 기본적인 방법을 통해 결정할 수 있습니다.

요구사항의 품질에 기여하는 고려되어야 할 속성이 더 많이 있습니다.요건이 데이터 무결성 규칙(예를 들어)의 적용을 받는 경우 정확성/정확성 및 유효성/허가도 가치 있는 속성입니다.트레이서빌리티를 통해 요건 세트가 요구를 충족하는지 확인합니다(필요한 것 이상 또는 그 이하도 아닙니다).

위의 일부에 외부 관찰 가능을 추가합니다. 즉, 요건은 사용자가 외부에서 관찰하거나 경험할 수 있는 제품의 특성을 지정합니다.이러한 지지자들은 내부 아키텍처, 설계, 구현 또는 테스트 결정을 규정하는 요건은 아마도 제약사항일 것이며 요건 문서의 제약사항 섹션에 명확하게 기술되어야 한다고 주장한다.대조적인 견해는 이 관점이 두 가지 점에서 실패한다는 것이다.첫째, 관점은 사용자 경험이 사용자가 인식할 수 없는 요건에 의해 지원될 수 있다는 것을 인식하지 못한다.예를 들어, 지리 코드화된 정보를 사용자에게 제시하는 요건은 외부 제3자 비즈니스 파트너와의 인터페이스 요건에 의해 지원될 수 있다.인터페이스를 통해 얻은 정보의 표시는 물론 그렇지 않지만, 사용자는 인터페이스를 감지할 수 없습니다.둘째, 제약조건은 설계대안을 제한하는 반면 요구사항은 설계특성을 규정한다.이 예제를 계속하려면 웹 서비스 인터페이스를 선택하는 요구사항이 설계 대안을 Single Sign-On 아키텍처와 호환되는 메서드로 제한하는 제약 조건과 다릅니다.

검증

모든 요건을 검증할 수 있어야 합니다.가장 일반적인 방법은 테스트입니다.그렇지 않은 경우 다른 검증 방법(예: 분석, 시연, 검사 또는 설계 검토)을 사용해야 한다.

특정 요건은 그 구조상 검증할 수 없다.여기에는 시스템이 절대 또는 항상 특정 속성을 보여서는 안 된다는 요건이 포함됩니다.이러한 요건을 적절히 테스트하려면 무한 테스트 사이클이 필요합니다.이러한 요구사항은 검증가능하도록 다시 작성되어야 한다.위에서 설명한 바와 같이 모든 요건은 검증 가능해야 합니다.

소프트웨어 레벨에서는 검증할 수 없는 기능 이외의 요건은, 고객의 의도에 관한 문서로서 보관해 둘 필요가 있습니다.그러나 이러한 요구 사항은 이를 충족하는 실용적인 방법으로 결정된 프로세스 요구 사항으로 추적될 수 있습니다.예를 들어 백도어가 없는 비기능적 요건은 페어 프로그래밍을 사용하는 프로세스 요건으로 대체함으로써 충족될 수 있다.기타 기능하지 않는 요건은 다른 시스템 컴포넌트로 추적되어 해당 수준에서 검증됩니다.예를 들어, 시스템의 신뢰성은 시스템 수준에서 분석을 통해 검증되는 경우가 많습니다.복잡한 안전 요구사항이 있는 항전 소프트웨어는 DO-178B 개발 프로세스를 따라야 합니다.

시스템 또는 소프트웨어 요구 사항을 도출하는 작업입니다.요구 사항 공학 및 요구 사항 도출(모임, 이해, 검토 및 이해 관계자들의 필요성을 분명하게 말하고)과 요구 사항 analysis,[10]분석(일관성과 완전성에 대한 확인), 명세서는(요건을 기록한) 타당성 조사나 그 프로젝트의 개념적 분석 단계 포함할지도 모릅니다.d'v'식별(지정된 요건이 [11][12]올바른지 확인)

요구사항은 모호성, 불완전성 및 불일치 문제가 발생하기 쉽습니다.엄격한 검사와 같은 기법이 이러한 문제에 대처하는 데 도움이 되는 것으로 나타났습니다.요구사항 단계에서 해결할 수 있는 모호성, 불완전성 및 불일치는 일반적으로 제품 개발의 후반 단계에서 이와 같은 문제가 발견되었을 때보다 수정 비용이 훨씬 적게 듭니다.요건 분석은 이러한 문제에 대처하기 위해 노력하고 있습니다.

너무 애매한 요건과 너무 상세한 요건 사이에 고려해야 할 기술적 트레이드오프가 있습니다.

  1. 생산하는 데 오랜 시간이 걸린다 - 때로는 완성되면 쓸모없을 정도로
  2. 사용 가능한 구현 옵션을 제한하다
  3. 생산 비용이 많이 든다

신속한 변화를 위한 접근방식은 이러한 문제를 극복하기 위한 방법으로 발전했습니다.요건을 개략적으로 베이스라인화하고 적시 또는 마지막 책임 있는 순간에 상세하게 기술합니다.

요건 문서화

요구사항은 일반적으로 서로 다른 이해관계자 간의 의사소통을 위한 수단으로 작성된다.즉, 일반 사용자와 개발자 모두 요구사항을 쉽게 이해할 수 있어야 합니다.요건을 문서화하는 일반적인 방법 중 하나는 시스템이 수행해야 할 작업을 기술하는 것입니다.예: '도급업자는 제품을 xyz 날짜까지 납품해야 합니다.'다른 방법으로는 사용 사례와 사용자 사례가 있습니다.

요건의 변경

요건은 일반적으로 시간에 따라 달라집니다.정의 및 승인이 완료되면 요건은 변경 관리 하에 놓입니다.대부분의 프로젝트에서는 시스템이 완료되기 전에 요건이 변경됩니다.이것은 부분적으로 컴퓨터 소프트웨어의 복잡성과 사용자가 무엇을 원하는지 보기 전에 알 수 없다는 사실에 기인한다.이러한 요건의 특성으로 인해 요건 관리 연구 및 실천이 이루어졌습니다.

문제들

경쟁 규격

요건이 무엇이며, 어떻게 관리 및 사용해야 하는지에 대한 여러 가지 견해가 있습니다.업계의 선두 주체는 IEEE와 IIBA입니다.두 그룹 모두 요건이 무엇인지에 대한 정의는 다르지만 유사합니다.

소프트웨어 요건의 필요성과 효과에 관한 분쟁

많은 프로젝트들이 [13]요건에 대한 합의가 거의 또는 전혀 없이 성공했습니다.또한 요건을 지정하면 창의성이 저하되고 설계 성능 요건이 설계자가 제공된 [15][16][17]정보에 지나치게 몰두하기 때문에 창의성과 설계를 방해한다는 증거도 있습니다.보다 일반적으로 일부 연구에 따르면 소프트웨어 요건은 실제 요건이 [18]명확하지 않은 상황에서 설계 결정을 요건으로 잘못 표현함으로써 생기는 환상이라고 합니다.

한편, 대부분의 신속한 변화를 위한 소프트웨어 개발 방법론에서는 소프트웨어 요건을 사전에 엄격하게 기술할 필요가 있는지 의문을 제기하고 있으며, 이를 이동 대상으로 간주하고 있습니다.대신, 극단적인 프로그래밍은 사용자 스토리를 비공식적으로 사용하는 요건(시스템이 해야 할 일의 한 측면을 설명하는 인덱스 카드에 맞는 짧은 요약)을 기술하고 개발자가 고객에게 직접 설명을 요구하는 것을 의무로 간주합니다.신속한 변화를 위한 방법론은 일련의 자동화된 수용 테스트에서 요구사항을 파악하려고 시도합니다.

요건이 변화하다

스코프 크리프는 시간이 지남에 따라 변화하는 요건에 의해 발생할 수 있습니다.요건관리에서는요건의변경은허용되지만적절하게추적되지않거나이전단계(비즈니스목표)가추가적인감독에의해제되지않거나비용및프로그램장애로처리되지않으면요건변경이쉽고발생가능성이높습니다.요구사항 변경은 개발자가 작업을 생성할 수 있는 속도보다 더 빨리 이루어지기 쉬우며, 그 결과 이전으로 되돌아가려는 노력이 필요합니다.

복수의 요건 분류법

어떤 프레임워크에서 동작하는가에 따라 요건에 대한 여러 분류법이 있다(예를 들어 IEEE, IIBA 또는 미국 국방성 접근방식의 기술 표준).장소나 격의 없는 말투에 따라 언어와 프로세스가 다르면 혼란과 바람직한 프로세스로부터의 이탈이 발생할 수 있습니다.

프로세스 파손

인간에 의해 운영되는 과정은 통치에 있어 인간의 결함에 노출될 수 있으며, 여기서 편리함이나 욕망 또는 정치는 과정의 예외나 완전한 전복으로 이어질 수 있고 과정이 진행되어야 하는 교과서적인 방식에서 벗어날 수 있다.예를 들어 다음과 같습니다.

  • 엄격하지 않은 프로세스는 존중받지 못합니다.예를 들어, 이 프로세스를 실행하는 조직이 독립성이나 힘이 거의 없거나, 기록에 대한 신뢰성과 투명성이 떨어지는 등 예외나 변경이 일반적인 경우에는 프로세스 전체가 무시될 수 있습니다.
  • 재도약을 원하는 새로운 선수 - 예:이미 개발 중인 것(소프트웨어 솔루션 등)에 대한 전임 CEO의 계획을 변경하고 싶거나 새로 만든 오피스 오브젝트를 현재의 프로지 개발로 바꾸는 등 전임 CEO의 힘이나 가치 주장을 보여주기 위해 전임자의 작업을 바꾸고 싶은 새로운 사람들의 자연스러운 경향사용자 요구 사항이 작성되었을 때 존재하지 않았기 때문에 프로젝트를 역추적하고 재추적하기 위한 노력을 시작합니다.
  • 라인 외 색칠 - 예를 들어, 보다 많은 제어를 필요로 하는 사용자는 "사용자 요건" 또는 우선순위 수준의 요건 관리 정의를 충족하는 것을 입력할 뿐만 아니라 설계 세부사항이나 선호하는 벤더 특성을 사용자 요건 또는 사무실에서 가장 높은 우선순위로 삽입할 수 있습니다.
  • 늦게 나타나는 경우 - 예를 들어, 개발 전에 요구사항 도출에 거의 또는 전혀 노력하지 않는 경우.이것은, 개인의 참가에 관계없이 같은 메리트를 얻을 수 있다고 생각하기 때문이거나, 테스트 단계나 다음 회전에 요구를 삽입하는 것만으로 의미가 없거나, 또는 작업 후의 평가를 기다려 항상 옳고 싶다고 생각하고 있기 때문일 가능성이 있습니다.

미국 국방부 프로세스에서 요건 문제의 몇 가지 과거 예는 다음과 같습니다.

  • 펜타곤 전쟁에서 묘사된 M-2 브래들리 캐주얼 요구 운동 문제
  • F-16이 경량 전투기 개념의 파이터 마피아에서 성장한 것은 F-15 프로그램이 경쟁을 방해하거나 지역적인 욕구를 불어넣어 경량화 및 저비용화 개념을 잠식했기 때문이다.
  • 「Net-Ready」에 대한 열의 ca. 1998년, 「Net-Ready」에 대한 열의는, Net-Ready 오피스의 주요 퍼포먼스 파라메타로서 그 오피스의 요건 정의 프로세스로부터, 또 이전에 정의한 프로세스와 일관성이 없는 것, KPP의 정의, 또는 「Net-Read」를 구성하는 일부의 정의가 적절하지 않거나, 또는 불가능할 가능성이 있는 것을 요구하게 했다.'Y'

「 」를 참조해 주세요.

레퍼런스

  1. ^ Form and Style of Standards, ASTM Blue Book (PDF). ASTM International. 2012. Retrieved 5 January 2013.
  2. ^ Boehm, Barry (2006). "A view of 20th and 21st century software engineering". ICSE '06 Proceedings of the 28th international conference on Software engineering. University of Southern California, University Park Campus, Los Angeles, CA: Association for Computing Machinery, ACM New York, NY, USA. pp. 12–29. ISBN 1-59593-375-1. Retrieved January 2, 2013.
  3. ^ "1.3 Key Concepts - IIBA International Institute of Business Analysis". www.iiba.org. Retrieved 2016-09-25.
  4. ^ "IEEE SA - 610.12-1990 - IEEE Standard Glossary of Software Engineering Terminology".
  5. ^ Iiba; Analysis, International Institute of Business (2009). A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 2.0. ISBN 978-0-9811292-1-1.
  6. ^ Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). "Characterizing Architecturally Significant Requirements". IEEE Software. 30 (2): 38–45. doi:10.1109/MS.2012.174. hdl:10344/3061. S2CID 17399565.
  7. ^ Ralph, P. 및 Wand, Y. 디자인 컨셉의 정식 정의를 위한 제안.Lytinen, K., Loucopoulos, P., Mylopoulos, J. 및 Robinson, (에드), 디자인 요건 엔지니어링: 10년 전망: Springer-Verlag, 2009 페이지 103-136.
  8. ^ Davis, Alan M. (1993). Software Requirements: Objects, Functions, and States, Second Edition. Prentice Hall. ISBN 978-0-13-805763-3.
  9. ^ IEEE Computer Society (1998). IEEE Recommended Practice for Software Requirements Specifications. Institute of Electrical and Electronics Engineers, Inc. ISBN 978-0-7381-0332-7.
  10. ^ Stellman, Andrew; Greene, Jennifer (2005). Applied Software Project Management. O'Reilly Media. p. 98. ISBN 978-0-596-00948-9. Archived from the original on 2015-02-09.
  11. ^ Wiegers, Karl E. (2003). Software Requirements, Second Edition. Microsoft Press. ISBN 978-0-7356-1879-4.
  12. ^ Young, Ralph R. (2001). Effective Requirements Practices. Addison-Wesley. ISBN 978-0-201-70912-4.
  13. ^ Checkland, Peter (1999). Systems Thinking, Systems Practice. Chichester: Wiley.
  14. ^ Ralph, Paul; Mohanani, Rahul (May 2015). "Is Requirements Engineering Inherently Counterproductive?". Proceedings of the 5th International Workshop on the Twin Peaks of Requirements and Architecture. Florence, Italy: IEEE. pp. 20–23.
  15. ^ Jansson, D.; Smith, S. (1991). "Design fixation". Design Studies. 12 (1): 3–11. doi:10.1016/0142-694X(91)90003-F.
  16. ^ Purcell, A.; Gero, J. (1996). "Design and other types of fixation". Design Studies. 17 (4): 363–383. doi:10.1016/S0142-694X(96)00023-3.
  17. ^ Mohanani, Rahul; Ralph, Paul; Shreeve, Ben (May 2014). "Requirements Fixation". Proceedings of the International Conference on Software Engineering. Hyderabad, India: IEEE. pp. 895–906.
  18. ^ Ralph, Paul (2012). "The Illusion of Requirements in Software Development". Requirements Engineering. 18 (3): 293–296. arXiv:1304.0116. doi:10.1007/s00766-012-0161-4. S2CID 11499083.

외부 링크

무료 사전인 Wiktionary에서 요구 사항을 검색합니다.