what is requirement analysis
이 자습서에서는 SDLC에서 요구 사항 분석, 요구 사항 분석 단계, 예 및 요구 사항 수집 목표가 무엇인지 설명합니다.
소프트웨어 개발은 작동하는 소프트웨어 제품을 만드는 엄청난 작업입니다.
소프트웨어 제품은 고객의 요구 사항에 따라 구축됩니다. 대부분이 소프트웨어 제품은 최종 고객 / 사용자가 기대 한 바를 준수하지만 때때로이 제품은 고객 / 최종 사용자가 기대 한 바를 완전히 준수하지 않습니다.
학습 내용 :
요구 사항 분석이란?
예를 들어 요구 사항 분석을 이해하겠습니다.
고객 / 최종 사용자 기대 :
고객 / 최종 사용자는 다음을받습니다.
위의 이미지에서 분석 할 수 있듯이 최종 제품과 고객의 기대치가 일치하지 않습니다. 이것은 무수한 이유 때문일 수 있습니다. 고객 요구 사항의 잘못된 구현, 잘못된 설계, 프로그래머 및 품질 팀의 잘못된 고객 요구 사항 이해 등
그러나 보시다시피 잘못된 제품 배송의 이유가 무엇이든 주된 이유는 요구 사항입니다. 따라서 올바른 요구 사항 이해, 캡처, 구현 및 테스트가 수행 되었다면 고객 / 최종 사용자에게 잘못되고 불완전한 제품 제공을 완화하는 데 도움이되었을 것입니다.
좋은 제품 전달을 위해서는 정확한 요구 사항 수집, 수집 된 요구 사항의 효율적인 검사, 그리고 마지막으로 명확한 요구 사항 문서화가 전제 조건으로 필요합니다. 이 전체 과정을 소프트웨어 개발 수명주기 (SDLC)의 요구 사항 분석
요구 사항 분석 단계 / 단계
보시다시피 요구 사항 분석은 SDLC의 첫 번째 활동이며 그 다음에는 기능 사양 등이 있습니다. 요구 사항 분석은 고객의 제품 승인에 중요한 승인 테스트와 공감하기 때문에 SDLC에서 중요한 단계입니다.
이 자습서에서는 SDLC에서 요구 사항 분석이 수행되는 방법을 설명합니다. 또한 요구 사항 분석에서 관련된 다양한 단계, 결과, 과제 및 수정 조치를 볼 수 있습니다.
요구 사항 분석은 다음으로 시작됩니다.
- 요구 사항 수집 추출이라고도합니다.
- 다음은 분석하는 이러한 요구 사항을 가능한 제품으로 변환하는 정확성과 타당성을 이해하기 위해 수집 된 요구 사항.
- 그리고 마지막으로, 문서화 수집 된 요구 사항.
# 1) 요구 사항 수집
위에서 언급 한 모든 단계가 적절하게 실행되도록하려면 고객으로부터 명확하고 간결하며 정확한 요구 사항을 수집해야합니다. 고객은 자신의 요구 사항을 적절하게 정의 할 수 있어야하며 비즈니스 분석가는 고객이 전달하려는 것과 동일한 방식으로이를 수집 할 수 있어야합니다.
고객의 비즈니스 분석가가 요구 사항 수집을 효율적으로 수행하는 것은 많은 경우 불가능합니다. 이는 예상되는 최종 제품, 도구, 환경 등과 관련된 많은 사람들에 대한 의존성 때문일 수 있습니다. 따라서 최종 제품에 영향을 줄 수 있거나 영향을받을 수있는 모든 이해 관계자를 항상 참여시키는 것이 좋습니다.
가능한 이해 관계자 그룹은 소프트웨어 품질 엔지니어 (QC 및 QA 모두), 프로젝트에서 지원을 제공 할 수있는 제 3 자 공급 업체, 제품을 대상으로하는 최종 사용자, 소프트웨어 프로그래머, 제공 할 수있는 조직 내 다른 팀일 수 있습니다. 제품 개발을위한 모듈 또는 소프트웨어 플랫폼, 소프트웨어 라이브러리 등.
예: 조직에서 그들은 필요한 ADAS 제품 (유명 OEM을위한 서라운드 뷰 카메라 시스템)을 개발합니다. Autosar 스택 과 부트 로더 다른 공급자로부터받은 바이너리.
요구 사항 수집 단계에서 다양한 이해 관계자를 참여 시키면 서로에 대한 다양한 종속성을 이해하는 데 도움이되며 향후 충돌 가능성을 피할 수 있습니다.
때로는 계획된 제품의 프로토 타입 모델을 만들어 고객에게 보여주는 것이 좋습니다. 이는 고객이 기대하는 제품과 나중에 어떻게 보일지 고객에게 전달할 수있는 훌륭한 방법입니다. 이는 고객이 기대하는 제품을 시각화하는 데 도움이되고 명확한 요구 사항을 제시하는 데 도움이됩니다.
이 프로토 타입 생성은 두 가지 유형의 제품에 따라 다릅니다.
- 고객이 의도 한 유사한 제품이 조직 내에 존재합니다.
- 개발 될 신제품.
(나는) 첫 번째 경우 고객에게 최종 제품의 모양과 개발 방법을 보여주는 것이 더 쉽습니다. 자동차 ADAS에서는 이미 시장에 나와 있고 조직 내에서 개발 된 다른 제품을 고객에게 보여줄 수 있습니다.
예를 들어, OEM (GM, Volkswagen, BMW 등)을 위해 개발 된 서라운드 뷰 카메라 시스템으로 다른 OEM에 선보일 수 있습니다.
참고 , 해당 제품을 개발중인 다른 고객과 체결 한 기밀 유지 계약을 위반할 수 있으므로 개발중인 고객에게 제품 / 프로토 제품을 보여주는 것은 현명하지 않습니다. 또한 불필요한 법적 분쟁을 초래할 수 있습니다.
다른 예시 인포테인먼트 시스템은 조직에서 개발하고 이미 시장에 나와있을 수 있습니다. 조직 내 비즈니스 분석가 및 기타 이해 관계자는 고객을위한 워크숍 데모를 계획하여 유형의 HMI, 장치 커넥터 포트, 샌드 박스 등을 갖춘 인포테인먼트 시스템을 표시 할 수 있습니다.
이를 통해 고객은 최종 제품이 어떻게 보이는지 이해하고 요구 사항을 훨씬 더 명확하게 제공 할 수 있습니다.
(ii) 두 번째 경우는 간단한 코딩 및 조립 (대부분의 기능은 소프트웨어 프로그램에 하드 코딩 됨)을 수행하여 기본 작업 모델을 생성하거나 고객에게 제품이 어떻게 보일지 확신 할 수있는 흐름도 또는 다이어그램을 생성하여 달성 할 수 있습니다.
어쨌든 고객은 이제 원하는 것을 알고 있으므로 요구 사항 수집 프로세스에 대한 호흡이 될 것입니다.
비즈니스 분석가는 이제 모든 이해 관계자가 초대되어 고객이 제공하는 다양한 요구 사항을 기록 할 수있는 공식적인 요구 사항 추출 회의를 구성 할 수 있습니다 (경우에 따라 이해 관계자가 더 많은 경우 별도의 서기를 지정하여 고객을 기록 할 수 있음). 비즈니스 분석가가 회의 중재에 집중할 수 있도록 요구 사항 또는 사용자 스토리).
수집 된 요구 사항은 다음과 같은 형태 일 수 있습니다. 사용자 스토리 (민첩한 개발에서), 사용 사례, 고객 자연어 문서, 다이어그램, 순서도 등. 사용자 스토리는 현대의 소프트웨어 개발 수명주기에서 인기를 얻고 있습니다. 사용자 스토리는 기본적으로 자연어로 된 일련의 고객 입력입니다.
요구 사항 수집 예 : ADAS 서라운드 뷰 카메라 시스템에서 가능한 사용자 스토리 중 하나는 다음과 같습니다. '사용자로서 나는 내 차의 후면에 무엇이 있는지 볼 수 있어야합니다.'
많을 수 있습니다 '왜,' 각 사용자 스토리에 대한 질문으로 고객이 요구 사항에 대한 자세한 정보를 제공하는 데 도움이됩니다.
위의 사용자 스토리에서 고객이 '사용자로서 내 차의 후면에 무엇이 있는지 볼 수 있어야합니다.'라고 말하면 질문을합니다. '왜 ”는“사용자로서 내 차 후면에 무엇이 있는지 볼 수 있어야합니다. 안전하게 주차 할 수 있도록 ”.
질문하기 '왜' 또한 고객이 제공 한 방대한 자연어 진술에서 객관적이고 원자적인 요구 사항을 생성하는 데 도움이됩니다. 이는 나중에 코드에서 쉽게 구현할 수 있습니다.
소프트웨어 테스트의 버그 수명주기
요구 사항을 수집하는 또 다른 방법은 사용 사례 . 사용 사례는 특정 결과를 얻기위한 단계별 접근 방식입니다. 이것은 소프트웨어가 사용자 입력에 대해 작동하는 방식을 알려주지 않고 사용자 입력에 대해 예상되는 내용을 말합니다.
예:
# 2) 수집 된 요구 사항 분석
요구 사항 수집 후 요구 사항 분석이 시작됩니다. 이 단계에서 다양한 이해 관계자가 앉아서 브레인 스토밍 세션을 수행합니다. 수집 된 요구 사항을 분석하고이를 구현할 가능성을 찾습니다. 그들은 서로 논의하고 모호한 부분을 분류합니다.
이 단계는 다음과 같은 주요 이유 때문에 요구 사항 분석 프로세스에서 중요합니다.
(나는) 고객은 다양한 종속성으로 인해 구현이 불가능할 수있는 일부 요구 사항을 제공 할 수 있습니다.
예: 고객후방 카메라 기능이있는 카메라 시스템의 서라운드 뷰를 요청할 수 있습니다. 주차 자동차. 고객은 또한 트레일러 후방 카메라를 사용하여 작동하는 히치 기능.
고객이 후방 카메라에 대한 요구 사항을 언급하는 경우 주차 지원은 예외없이 항상 작동해야합니다. 트레일러 기능은 작동하지 않으며 그 반대의 경우도 마찬가지입니다.
(ii) 비즈니스 분석가는 다음의 요구 사항을 이해했을 수 있습니다. 고객 방법과는 다르게 프로그램 제작자 해석했을 것입니다.
프로그래머는 기술 전문가로 생각하기 때문에 고객 요구 사항이 기능 사양으로 잘못 변환되어 나중에 아키텍처 및 디자인 문서로 잘못 만들어지고 나중에 코드로 변경 될 가능성이 항상 있습니다. 영향은 기하 급수적이므로 확인해야합니다.
가능한 교정 조치는 소프트웨어 개발의 민첩한 방법을 따르고 고객이 제공하는 사용 사례를 따르는 것입니다.
# 3) 분석 된 요구 사항 문서화
요구 사항 분석이 완료되면 요구 사항 문서화가 시작됩니다. 다양한 유형의 요구 사항이 요구 사항 분석에서 나옵니다.
이들 중 일부는 다음과 같습니다.
(나는) 고객 요구 사항 사양.
(ii) 소프트웨어 아키텍처 요구 사항.
예:
(iii) 소프트웨어 설계 요구 사항.
예:
(iv) 기능 요구 사항 사양 (고객 사양에서 직접 파생 됨)
예: '사용자가 Infotainment HMI에서 Bluetooth 아이콘을 탭하면 Bluetooth 화면이 표시되어야합니다.'
(V) 비 기능적 요구 사항 사양 (즉, 성능, 스트레스, 부하 등).
예: “시스템 성능 저하없이 15 개의 Bluetooth 장치를 인포테인먼트 시스템과 페어링 할 수 있어야합니다.”
(우리) 사용자 인터페이스 요구 사항.
예: “튜너 FM 화면에 다른 방송국을 선택할 수있는 버튼이 제공되어야합니다.”
위의 요구 사항은 IBM DOORS, HP QC와 같은 요구 사항 관리 도구에 기록되고 문서화됩니다. 때때로 조직은 비용을 줄이기 위해 맞춤형 요구 사항 관리 도구를 가지고 있습니다.
이제 변환 과정을 살펴 보겠습니다. 비즈니스 요구 사항 ...에 소프트웨어 요구 사항 (기능적 및 비 기능적).
비즈니스 요구 사항을 소프트웨어 요구 사항으로 변환
위에서 설명한 비즈니스 요구 사항은 최종 사용자가 소프트웨어 시스템에 대해 정의 된 작업에서 원하는 것이 무엇인지에 대해 설명하는 높은 수준의 요구 사항입니다. 소프트웨어 시스템 또는 구성 요소가 구현되는 방법에 대한 자세한 설명이 언급되지 않았기 때문에 이러한 요구 사항을 기반으로 전체 소프트웨어 시스템을 개발하는 것은 불가능합니다.
따라서 비즈니스 요구 사항은 기능적 및 비 기능적 요구 사항에 대해 더 자세히 설명되는보다 자세한 소프트웨어 요구 사항으로 분류되어야합니다.
이를 위해 다음 단계를 따를 수 있습니다.
- 높은 수준의 비즈니스 요구 사항을 상세한 사용자 스토리로 분류합니다.
- 활동의 흐름을 정의하는 순서도를 도출합니다.
- 파생 된 사용자 스토리를 정당화하는 조건을 제공합니다.
- 개체의 워크 플로를 설명하는 와이어 프레임 다이어그램.
- 비즈니스 요구 사항 중 비 기능적 요구 사항을 정의합니다.
자동차 인포테인먼트 시스템의 예를 들어 보겠습니다.
비즈니스 요구 사항은 '최종 사용자는 인포테인먼트 시스템 HMI에서 내비게이션 위젯 상자에 액세스 할 수 있어야하며 대상 주소를 설정할 수 있어야합니다.'라고되어 있습니다.
따라서 위에 나열된 단계는 다음과 같이 구현할 수 있습니다.
# 1) 높은 수준의 비즈니스 요구 사항을 상세한 사용자 스토리로 분류합니다.
이 비즈니스 요구 사항을 높은 수준의 사용자 스토리로 전환하겠습니다. ' 사용자로서 목적지 주소를 입력 할 수 있도록 내비게이션 위젯 상자에 액세스 할 수 있어야합니다. ”. 이 사용자 스토리는 최종 사용자에게 필요한 것을 알려줍니다. 이 요구 사항을 구현하는 방법을 정의하려고합니다.
이 사용자 스토리 즉, 가능한 질문을하는 것으로 시작하겠습니다.
- 사용자는 누구입니까?
- 내비게이션, 온보드 (SD 카드) 또는 스마트 폰에 액세스하려면 어떻게해야합니까?
- 어떤 종류의 목적지 항목을 입력 할 수 있습니까?
- 주차장에 차가 있어도 목적지에 들어갈 수 있나요?
이는 높은 수준의 사용자 스토리에서 파생 된보다 상세한 수준의 사용자 스토리이며 비즈니스 요구 사항에 대한 더 많은 통찰력을 얻는 데 도움이됩니다.
이 시점에서 사용자 하위 스토리 중 하나를 선택하고 질문을 시작할 수 있습니다. (3 번) :
- 음성 인식 등을 통해 지리적 좌표, 우편 주소와 같은 목적지 항목을 입력 할 수 있습니까?
- 지리 좌표를 입력하려면 GPS가 필요합니까?
- 주소 내역에서 검색하여 현재 목적지 주소를 입력 할 수 있습니까?
# 2) 활동의 흐름을 정의하기위한 순서도 도출.
이제 비즈니스 요구 사항이 다음과 같이 플로우 차트에 표시 될 수있는 매우 상세한 사용 사례로 분류되었음을 알 수 있습니다.
# 3) 파생 된 사용자 스토리를 정당화하는 조건 제공.
높은 수준의 비즈니스 요구 사항이 세부적인 낮은 수준의 사용자 스토리와 흐름도로 분해됨에 따라 더 자세한 정보가 등장하고 있음을 알 수 있습니다. 이 순서도에서 구현 비주얼리 제이션에 필요한 기술적 세부 정보를 얻을 수 있습니다.
- 목적지 항목을 표시하는 화면 로딩 시간은 1 초 여야합니다.
- 대상 입력 키보드에는 영숫자 문자와 특수 기호가 있어야합니다.
- 내비게이션 목적지 입력 화면에 GPS 활성화 / 비활성화 토글 버튼이 있어야합니다.
위의 정보는 사용자 스토리를 만족시키고 기능으로 구현되는 동안 요구 사항과의 혼동을 방지하면서 요구 사항을 개별적이고 측정 가능하게 테스트 할 수 있도록합니다.
# 4) 개체의 워크 플로를 설명하는 와이어 프레임 다이어그램.
위의 사용 사례에서 사용자 인터페이스를 더 명확하게 만드는 와이어 프레임 다이어그램을 도출합니다.
# 5) 비즈니스 요구 사항 중 비 기능적 요구 사항 정의.
세부적인 소프트웨어 요구 사항은 높은 수준의 비즈니스 요구 사항에서 파생되는 것이 중요하지만 시스템이 특정 사용자 입력 / 작업에 대해 작동하는 방식을 나타내는 기능적 요구 사항 만 식별되는 경우가 많습니다.
그러나 기능적 요구 사항은 시스템 성능 및 가용성, 안정성 등과 같은 기타 정 성적 매개 변수를 명확히하지 않습니다.
예 :
병합 정렬 C ++ 알고리즘
a) 위의 자동차 인포테인먼트 시스템의 예를 들어 보겠습니다.
차량 운전자 (최종 사용자)가 USB에서 음악을 재생하고 내비게이션 안내가 진행 중이면 핸즈프리 모드에서 블루투스를 통해 전화가 걸려 오면 여러 프로세스가 진행됨에 따라 CPU 부하 및 RAM 사용량이 최대 수준으로 증가합니다. 백그라운드에서 실행됩니다.
이 시점에서 운전자가 인포테인먼트 시스템 터치 스크린 인터페이스를 탭하여 자동 응답 SMS를 통해 수신 전화를 거부하는 경우 (휴대폰에서와 같은 방식으로) 시스템이이 작업을 수행 할 수 있어야하며 중단되거나 충돌하지 않아야합니다. 이것은 부하가 높을 때 시스템의 성능이며 가용성과 신뢰성을 테스트합니다.
b) 또 다른 경우는 스트레스 시나리오입니다.
예를 들어, 인포테인먼트 시스템은 연결된 블루투스 전화를 통해 연속 SMS (10 초 이내에 20 개 SMS)를 수신합니다. 인포테인먼트 시스템은 들어오는 모든 SMS를 처리 할 수 있어야하며 인포테인먼트 HMI에서 들어오는 SMS 알림을 놓쳐서는 안됩니다.
위의 예는 기능적 요구 사항만으로는 테스트 할 수없는 비 기능적 요구 사항의 경우입니다. 때때로 고객은 이러한 비 기능적 요구 사항을 제공하지 않습니다. 제품이 고객에게 배송 될 때이 정보를 제공하는 것은 조직의 책임입니다.
비 기능적 요구 사항 사례 이해
아래 표는 비 기능적 요구 사항을 설명합니다.
| SL 아니오 | 기능 / 사용 사례 | CPU 부하 (최대) | RAM 사용량 (최대 512MB) | 성능 매개 변수 |
|---|---|---|---|---|
| 1 | 최대 아니. 인포테인먼트 시스템에 페어링 할 수있는 Bluetooth 장치 수 | 75 % | 300MB | 블루투스 장치 10 개 |
| 두 | 블루투스 페어링 및 연결 후 인포테인먼트 시스템에서 2000 개의 전화 연락처를 다운로드하는 데 걸리는 시간 | 90 % | 315MB | 120 초 |
| 삼 | 인포테인먼트 시스템의 튜너에서 사용 가능한 모든 FM 방송국을 검색하는 시간 | 오십% | 200MB | 30 초 |
기능적 요구 사항과 달리 비 기능적 요구 사항은 각 Agile Sprint에서 점진적으로 구현되거나 다른 반복으로 구현되므로 프로젝트의 전체 수명주기가 구현됩니다.
그래서 이것이 우리가 비즈니스 요구 사항에서 소프트웨어 요구 사항을 도출하는 방법입니다.
비즈니스 요구 사항과 소프트웨어 요구 사항의 차이점
위에서 높은 수준의 비즈니스 요구 사항에서 소프트웨어 요구 사항을 도출하는 방법을 살펴 보았습니다. 소프트웨어 요구 사항을 통해 프로그래머와 테스트 엔지니어는 시스템을 개발하고 효율적으로 테스트 할 수 있습니다. 따라서 이제 우리는 비즈니스 요구 사항이 높은 수준의 고객 자연어 요구 사항이고 소프트웨어 요구 사항은 소프트웨어 시스템 구현에 도움이되는 세부적인 낮은 수준의 요구 사항이라는 것을 알고 있습니다.
두 가지 요구 사항 유형의 세부적인 차이점을 살펴 보겠습니다.
| 비즈니스 요구 사항 | 소프트웨어 요구 사항 |
|---|---|
| 시스템이 '무엇을해야 하는가'라고 말하는 고객의 높은 수준의 요구 사항입니다. 이러한 요구 사항은 요구 사항이 작동해야하는 '방법'을 나타내지 않습니다. | 그들은 고객 요구 사항의 '방법'측면에 집중합니다. 이러한 요구 사항은 시스템 작동 / 구현 방법을 설명합니다. |
| 이러한 요구 사항은 조직의 비즈니스 목표를 다룹니다. 예: 사용자는 내비게이션 목적지를 설정할 수 있어야합니다. | 이러한 요구 사항은 요구 사항의 기술적 노하우를 설명합니다. 예: 사용자가 탐색 대상 아이콘을 클릭하면 데이터베이스는 사용자가 입력 할 대상 세부 정보를로드해야합니다. |
| 비즈니스 요구 사항은 조직의 이점에 중점을 둡니다. 예: 내비게이션이 시스템에없고 사용자가 내비게이션 아이콘을 탭한 경우 인포테인먼트 시스템의 딜러로부터 내비게이션 기능을 업그레이드하기위한 정보를 사용자에게 제공해야합니다. | 소프트웨어 요구 사항은 시스템에서 비즈니스 요구 사항의 구현 세부 사항을 다룹니다. 예: 사용자가 인포테인먼트 시스템에서 탐색 아이콘을 클릭하면 시스템 업그레이드를 위해 사용자에게 메시지를 표시하기 위해 API 호출이 시작되어야합니다. |
| 비즈니스 요구 사항은 일반적으로 자연어 또는 고급 사용자 스토리로 작성됩니다. | 소프트웨어 요구 사항은 기능적이며 작동하지 않습니다. 예: 비 기능적 요구 사항 중에는 성능, 스트레스, 이식성, 유용성, 메모리 최적화, 룩앤필 등이 있습니다. |
결론
요구 사항 분석은 모든 SDLC 모델의 중추입니다.
요구 사항 분석 중에 누락되어 단위 테스트에서 포착 된 문제는 조직에 수만 달러의 비용이들 수 있으며,이 비용이 시장에서 콜백으로 제공되는 경우 수백만 달러로 이어질 수 있습니다 (2017 년 미국에서 에어백 제조업체 인 Takata a 에어백 폭발로 인한 10 억 달러의 벌금).
조직은 결국 소프트웨어 개발 및 품질에 집중하는 대신 근본 원인 분석, 5 가지 이유 문서 준비, 오류 트리 분석, 8D 문서 등과 같은 손상 관리 작업을 수행하게됩니다.
최악의 경우, 영향을받는 기능이 보안 액세스, 에어백, ABS (Anti-Lock 제동 시스템) 등과 같은 보안 / 안전 관련 기능인 경우 조직은 고객이 제기 한 법적 소송으로 끌려 갈 수 있습니다.