요구 사항 분석 및 수집이란 무엇입니까?

이 자습서에서는 요구 사항 분석,요구 사항 분석 단계,예제 및 요구 사항 수집 목표에 대해 설명합니다.

소프트웨어 제품은 고객 요구에 의하여 건축됩니다. 대부분이 소프트웨어 제품은 최종 고객/사용자가 예상 한 것을 준수하는 반면 때때로이 제품은 고객/최종 사용자가 예상 한 것을 완전히 준수하지 않습니다.

요구 사항 분석 이란 무엇입니까?

예제를 통해 요구 사항 분석을 이해하겠습니다.

고객/최종 사용자 기대:

고객/최종 사용자 수신:

위의 이미지에서 최종 제품에 고객 기대치가 일치하지 않음을 분석할 수 있습니다. 이것은 무수한 이유 때문일 수 있습니다. 고객 요구 사항의 잘못된 구현,잘못된 디자인,프로그래머 및 품질 팀의 고객 요구 사항에 대한 잘못된 이해 등

그러나,당신이 볼 수 있듯이,그것은 잘못된 제품 배달에 대한 이유가 될,주된 이유는 요구 사항에 간다. 따라서 올바른 요구 사항 이해,캡처,구현 및 테스트가 수행 된 경우 고객/최종 사용자에게 잘못되고 불완전한 제품 전달을 완화하는 데 도움이되었을 것입니다.

좋은 제품 납품은 전제 조건으로 정확한 요구 사항 수집,수집 요구 사항의 효율적인 검사,그리고 마지막으로 명확한 요구 사항 문서를 필요로한다. 이 전체 프로세스는 소프트웨어 개발 수명 주기에서 요구 사항 분석이라고도 합니다)

요구 사항 분석 단계/단계

보시다시피 요구 사항 분석은 기능 사양 등이 뒤 따르는 첫 번째 활동입니다. 요구 사항 분석은 고객의 제품 수용에 중요한 수락 테스트와 공명하기 때문에 중요한 단계입니다.

이 자습서에서는 요구 사항 분석이 어떻게 수행되는지 설명합니다. 또한 요구 사항 분석에서 관련된 다양한 단계,결과,과제 및 시정 조치를 볼 수 있습니다.

요구 사항 분석 시작:

1. 또한 도출로 불리는 요구 사항 수집.
2. 그런 다음 수집 된 요구 사항을 분석하여 이러한 요구 사항을 가능한 제품으로 변환하는 정확성과 타당성을 이해합니다.
3. 마지막으로 수집 된 요구 사항을 문서화합니다.

#1) 요구 사항 수집

위에서 언급한 모든 단계가 적절하게 실행되도록 하려면 고객으로부터 명확하고 간결하며 정확한 요구 사항을 수집해야 합니다. 고객은 자신의 요구 사항을 적절하게 정의 할 수 있어야하고 비즈니스 분석가는 고객이 전달하려는 것과 동일한 방식으로 수집 할 수 있어야합니다.

많은 경우 고객의 비즈니스 분석가가 요구 사항 수집을 효율적으로 수행 할 수 없습니다. 이는 예상되는 최종 제품,도구,환경 등과 관련된 많은 사람들에 대한 의존성 때문일 수 있습니다. 따라서,그것은 항상 영향을 미칠 수 또는 최종 제품에 의해 영향을 받을 수 있는 모든 이해 관계자를 포함 하는 것이 좋습니다.

가능한 이해 관계자의 그룹은 소프트웨어 품질 엔지니어(품질 관리와 품질 관리 모두),프로젝트에서 지원을 제공 할 수있는 제 3 자 공급 업체,제품이 의도 된 최종 사용자,소프트웨어 프로그래머,모듈 또는 소프트웨어 플랫폼을 제공 할 수있는 조직 내의 다른 팀,소프트웨어 라이브러리 등이 될 수 있습니다. 제품 개발을 위해.이 제품은 다른 공급업체로부터 받은 자동 스택 및 부트로더 바이너리가 필요합니다.

요구 사항 수집 단계에서 다양한 이해 관계자를 참여 시키면 서로에 대한 다양한 종속성을 이해하는 데 도움이되며 향후 발생할 수있는 충돌을 피할 수 있습니다.

경우에 따라 계획된 제품의 프로토타입 모델을 만들어 고객에게 보여주는 것이 좋습니다. 이것은 어떤 제품을 그들은 기대 하 고 어떻게 나중에 보일 수 있습니다 고객에 게 전달 하는 훌륭한 방법. 이것은 그들이 기대하는 제품을 시각화하는 고객을하는 데 도움이 명확한 요구 사항을 마련하는 데 도움이됩니다.

이 프로토타입 제작은 두 가지 유형의 제품에 따라 달라집니다:

1. 고객이 의도 한 유사한 제품이 조직 내에 존재합니다.
2. 신제품 개발.

(첫 번째 경우에는 최종 제품이 어떻게 생겼는지,어떻게 개발되는지 고객에게 보여주는 것이 더 쉽습니다. 자동차 산업에서는 고객에게 이미 시장에 나와 있고 조직 내에서 개발 된 다른 제품을 보여줄 수 있습니다.

예를 들어,서라운드 뷰 카메라 시스템은 스마트 폰을 위해 개발되었습니다.)그리고 다른 사람에 전시될 수 있습니다.

제품 개발 중인 다른 고객과 체결된 비공개 계약을 위반할 수 있으므로 개발 중인 고객에게 제품/프로토 제품을 표시하는 것은 현명하지 않습니다. 또한 불필요한 법적 싸움이 발생할 수 있습니다.

또 다른 예는 조직에 의해 개발되고 있으며 이미 시장에 나와있는 인포테인먼트 시스템 일 수 있습니다. 조직 내의 비즈니스 분석가 및 기타 이해 관계자는 고객을위한 워크샵 데모를 계획 할 수 있으며,가시적 인 인포테인먼트 시스템,장치 커넥터 포트,샌드 박스 등을 표시 할 수 있습니다.

이것은 최종 제품의 모양과 훨씬 더 명확하게 자신의 요구 사항을 제공하는 방법을 이해하는 고객을 도움이 될 것입니다.

두 번째 경우는 간단한 코딩 및 조립(주로 소프트웨어 프로그램에서 하드 코딩 됨)을 수행하여 기본 작업 모델을 만들거나 제품이 어떻게 보이는지 고객을 설득 할 수있는 흐름도 또는 다이어그램을 작성하여 달성 할 수 있습니다.

어떤 경우에,그것은 고객이 지금 자신이 원하는 것을 알고 요구 사항 수집 프로세스에 대한 브리더 것입니다.

비즈니스 분석가는 이제 모든 이해 관계자를 초대 할 수있는 공식적인 요구 사항 도출 회의를 구성 할 수 있으므로 고객이 제공하는 다양한 요구 사항을 기록 할 수 있습니다(경우에 따라 이해 관계자가 더 많은 경우 비즈니스 분석가가 회의를 중재하는 데 집중할 수 있도록 고객 요구 사항 또는 사용자 스토리를 기록하도록 별도의 서기관을 임명 할 수 있음).

수집 된 요구 사항은 사용자 스토리(애자일 개발),사용 사례,고객 자연어 문서,다이어그램,플로우 차트 등의 형태 일 수 있습니다. 사용자 스토리는 현대 소프트웨어 개발 라이프 사이클에서 인기를 얻고 있습니다. 사용자 스토리는 기본적으로 자연 언어로 된 고객 입력 집합입니다.

요구 사항 수집 예:서라운드 뷰 카메라 시스템에서 한 가지 가능한 사용자 스토리는 다음과 같습니다.

각 사용자 스토리에 대해 많은”이유”질문이 있을 수 있으며,이는 고객이 요구 사항에 대한 자세한 정보를 제공하는 데 도움이 될 것입니다.

위의 사용자 이야기에서 고객이”사용자로서 내 차의 후면에 무엇이 있는지 볼 수 있어야합니다”라고 말하면”왜”가”사용자로서”내 차의 후면에 무엇이 있는지 볼 수 있어야합니다.

“왜”라는 질문을 하는 것은 고객이 제시한 거대한 자연어 진술로부터 객관적이고 원자적인 요구사항을 만드는 데에도 도움이 된다. 이것은 나중에 코드에서 쉽게 구현할 수 있습니다.

요구 사항을 수집하는 또 다른 방법은 사용 사례 형식입니다. 사용 사례는 특정 결과를 얻기 위한 단계별 접근 방식입니다. 이 소프트웨어는 오히려 말한다 사용자 입력에 작동하는 방법을 말하지 않는다,사용자 입력의 예상 무엇.

예:

#2) 수집 된 요구 사항 분석

요구 사항 수집 후 요구 사항 분석 시작. 이 단계에서 다양한 이해 관계자가 앉아서 브레인 스토밍 세션을 수행합니다. 그들은 수집 된 요구 사항을 분석하고이를 구현하는 타당성을 찾습니다. 그들은 서로 토론하고 어떤 모호함도 정리됩니다.

이 단계는 다음과 같은 주요 이유로 인해 요구 사항 분석 프로세스에서 중요합니다.

예:고객은 주차에 도움이 될 후방 카메라 기능을 사용하여 카메라 시스템을 서라운드 뷰하도록 요청할 수 있습니다. 고객은 또한 후방 카메라를 사용하여 작동하는 트레일러 히치 기능을 요청할 수 있습니다.

고객이 주차 지원을위한 후방 카메라가 예외없이 항상 작동해야한다는 요구 사항을 명시하면 트레일러 기능이 작동하지 않으며 그 반대도 마찬가지입니다.

(2)비즈니스 분석가는 프로그래머가 해석 한 방법과 다르게 고객의 요구 사항을 이해했을 수 있습니다.

프로그래머는 기술 전문가로 생각하기 때문에 고객 요구 사항이 기능 사양으로 잘못 변환되어 나중에 아키텍처 및 디자인 문서로 잘못 변환되고 나중에 코드로 변환 될 수 있습니다. 영향은 지수 적이므로 확인해야합니다.

가능한 개선 조치는 민첩한 소프트웨어 개발 방법,고객이 제공하는 사용 사례 등을 따르는 것일 수 있습니다.

#3)분석 된 요구 사항 문서화

요구 사항 분석이 완료되면 요구 사항 문서가 시작됩니다. 다양한 유형의 요구 사항이 요구 사항 분석에서 나옵니다.

이들 중 일부는 다음과 같습니다:

(나는)고객 요구 사항 사양.

(2)소프트웨어 아키텍처 요구 사항.

예:

(3)소프트웨어 설계 요구 사항.

예:

(4)기능 요구 사항 사양(고객 사양에서 직접 파생 됨.2623>예:”사용자가 인포테인먼트에서 블루투스 아이콘을 탭하면 블루투스 화면이 표시되어야 합니다.”

성능,스트레스,부하 등).

예:”시스템 성능 저하없이 15 개의 블루투스 장치를 인포테인먼트 시스템과 페어링 할 수 있어야합니다.”

(6)사용자 인터페이스 요구 사항.

예: 위의 요구 사항은 요구 사항 관리 도구에 기록되고 문서화되어 있습니다. 때때로 조직은 비용을 줄이기 위해 맞춤형 요구 사항 관리 도구를 갖추고 있습니다.

이제 비즈니스 요구 사항을 소프트웨어 요구 사항(기능 및 비 기능)으로 변환하는 프로세스를 살펴 보겠습니다.

비즈니스 요구 사항을 소프트웨어 요구 사항으로 변환

비즈니스 요구 사항,위에서 설명한 대로 최종 사용자가 소프트웨어 시스템에 정의 된 작업에서 원하는 것에 대해 이야기 하는 높은 수준의 요구 사항입니다. 이러한 요구 사항을 기반으로 전체 소프트웨어 시스템을 개발하는 것은 소프트웨어 시스템 또는 구성 요소가 구현되는 방법에 대한 자세한 설명은 언급되지 않았기 때문에 불가능합니다.

따라서 비즈니스 요구 사항은 기능 및 비 기능 요구 사항에 대해 더 자세히 설명 할보다 자세한 소프트웨어 요구 사항으로 분류되어야합니다.

이렇게 하려면 다음 단계를 따를 수 있습니다:

1. 높은 수준의 비즈니스 요구 사항을 세부적인 사용자 스토리로 분류합니다.
2. 활동 흐름을 정의하는 플로우차트를 파생합니다.
3. 파생된 사용자 스토리를 정당화하는 조건을 제공합니다.
4. 개체의 워크플로를 설명하는 와이어프레임 다이어그램.
5. 비즈니스 요구 사항에서 비 기능 요구 사항을 정의합니다.

자동차 인포테인먼트 시스템의 예를 들어 보겠습니다.

비즈니스 요구 사항에 따르면”최종 사용자는 인포테인먼트 시스템에서 탐색 위젯 상자에 액세스 할 수 있어야하며 대상 주소를 설정할 수 있어야합니다.”

따라서 위의 입대 단계는 다음과 같이 구현 될 수 있습니다:

#1) 높은 수준의 비즈니스 요구 사항을 세부적인 사용자 스토리로 분류합니다.

이 비즈니스 요구 사항을”사용자로서 대상 주소를 입력 할 수 있도록 탐색 위젯 상자에 액세스 할 수 있어야합니다”라는 고급 사용자 스토리로 변환하겠습니다. 이 사용자 스토리는 최종 사용자에게 필요한 것을 알려줍니다. 이 요구 사항을 구현하는 방법을 정의하려고 노력할 것입니다.

이 사용자 스토리 즉 가능한 질문으로 시작하겠습니다.

1. 사용자는 누구입니까?
2. 내비게이션,온보드(카드)또는 스마트 폰에서 어떻게 액세스 할 수 있습니까?
3. 어떤 종류의 대상 항목을 입력 할 수 있습니까?
4. 차량이 주차 중일 때에도 목적지를 입력해야 합니까?

이들은 높은 수준의 사용자 스토리에서 파생 된보다 자세한 수준의 사용자 스토리이며 비즈니스 요구 사항에 대한 통찰력을 얻는 데 도움이됩니다.

이 시점에서 사용자 하위 스토리 중 하나를 차지하고 질문을 시작할 수 있습니다. 우리가(더. 3):

1. 지리적 좌표,우편 주소,음성 인식 등을 통해 대상 항목을 입력 할 수 있습니까??
2. 지리적 좌표를 입력해야 합니까?
3. 주소 기록에서 검색하여 현재 목적지 주소를 입력할 수 있습니까?

#2) 활동의 흐름을 정의하는 순서도를 파생.

이제 우리는 비즈니스 요구 사항은 다음과 같이 순서도에 표시 할 수있는 매우 상세한 사용 사례로 분류되는 것을 볼 수 있습니다:

#3) 파생 사용자 스토리를 정당화하는 조건 제공.

높은 수준의 비즈니스 요구 사항을 세부적인 낮은 수준의 사용자 스토리와 순서도로 분해하여 더 자세한 정보가 나타나고 있음을 알 수 있습니다. 이 순서도,우리는 구현 즉 필요한 기술적 인 세부 사항을 얻을 수 있습니다.

대상 입력 키보드에는 영숫자와 특수 기호가 있어야 합니다.

내비게이션 대상 입력 화면에 토글 활성화/비활성화 버튼이 있어야 합니다.

위의 정보는 사용자 스토리를 만족시키고 기능으로 구현되는 동안 요구 사항과의 혼동을 피하기 위해 요구 사항을 이산 적으로 테스트 할 수있게합니다.

#4)객체의 워크 플로우를 설명하는 와이어 프레임 다이어그램.

위의 사용 사례에서 사용자 인터페이스를 더 명확하게 만드는 와이어 프레임 다이어그램을 도출합니다.

#5) 비즈니스 요구 사항에서 비 기능 요구 사항을 정의합니다.

자세한 소프트웨어 요구 사항은 높은 수준의 비즈니스 요구 사항에서 파생되는 것이 필수적이지만,시스템이 특정 사용자 입력/동작에 대해 어떻게 동작하는지를 나타내는 기능 요구 사항 만 식별되는 경우가 많습니다.

그러나 기능 요구 사항은 시스템 성능 및 가용성,안정성 등과 같은 기타 질적 매개 변수를 명확히하지 않습니다.

예:

에이)우리는 위의 자동차 인포테인먼트 시스템의 예를 취할 것입니다.

경우 드라이버(end-user)의 자동차에서 음악을 재생 USB 및 탐색 지도에서 진행,또한 전화를 통해 블루투스 핸즈프리드 로드에 CPU RAM 소비 증가를 최대로 여러 프로세스는 백그라운드에서 실행됩니다.

이 시점에서,드라이버는 자동 응답 문자(우리가 우리의 휴대 전화에서 어떻게 같은 방식으로)를 통해 수신 전화를 거부하기 위해 인포테인먼트 시스템 터치 스크린 인터페이스에 도청 경우,시스템은이 작업을 수행 할 수 있어야하고 중단 또는 충돌하지 않아야합니다. 이는 부하가 높고 가용성 및 안정성을 테스트 할 때 시스템의 성능입니다.

비)또 다른 경우는 스트레스 시나리오입니다.

예를 들어,인포테인먼트 시스템은 연결된 블루투스 전화를 통해 10 초 이내에 20 개의 문자를 다시 수신합니다. ***********

위의 예는 기능 요구 사항만으로는 테스트할 수 없는 비기능 요구 사항의 경우입니다. 때때로 고객은 이러한 비 기능적 요구 사항을 제공하지 않습니다. 제품이 고객에게 배달될 때,이 정보에 그들을 제공하는 조직의 책임 이다.

비기능 요구 사항 이해 사례

아래 표에서는 비기능 요구 사항에 대해 설명합니다:

기능적 요구 사항과 달리 비 기능적 요구 사항, 각각의 민첩한 스프린트 또는 다른 반복에서 점진적으로 구현되므로 프로젝트의 전체 라이프 사이클을 구현하십시오.

따라서 이것이 비즈니스 요구 사항에서 소프트웨어 요구 사항을 도출하는 방법입니다.

비즈니스 요구 사항과 소프트웨어 요구 사항의 차이

우리는 높은 수준의 비즈니스 요구 사항에서 소프트웨어 요구 사항을 도출하는 방법을 위에서 보았다. 소프트웨어 요구 사항을 통해 프로그래머와 테스트 엔지니어는 시스템을 개발하고 효율적으로 테스트 할 수 있습니다. 따라서 비즈니스 요구 사항은 높은 수준의 고객 자연어 요구 사항이고 소프트웨어 요구 사항은 소프트웨어 시스템의 구현에 도움이되는 상세한 낮은 수준의 요구 사항이라는 것을 알고 있습니다.

두 요구 사항 유형 간의 자세한 차이점을 살펴 보겠습니다.

결론

요구 사항 분석은 모든 모델의 중추입니다.

요구 사항 분석 중에 누락되어 단위 테스트에서 발견 된 문제는 조직에 수만 달러의 비용이 소요될 수 있으며,이 비용은 시장에서 콜백으로 발생하는 경우 수백만 달러가 발생할 수 있습니다(2017 년 미국 충전 에어백 제조업체,타카 타 에어백 폭발로 인해 10 억 달러의 벌금).

조직은 근본 원인 분석,왜 문서 준비,오류 트리 분석,8 차원 문서 등과 같은 손상 관리 작업을 수행하게됩니다. 소프트웨어 개발 및 품질에 집중하는 대신.

최악의 경우,보안 액세스,에어백,복근(안티 록 제동 시스템)등과 같은 보안/안전 관련 기능이 영향을 받으면 조직이 고객이 제기 한 법적 소송에 끌려 갈 것입니다.