수요 분석 및 수요 조사 방법

넓은 의미에서 수요 분석에는 수요 획득, 분석, 사양 설명, 변경, 검증 및 관리와 같은 일련의 수요 항목이 포함됩니다.

좁은 수요 분석은 수요 분석과 정의의 과정이다.

원인

수요 분석은 소프트웨어 사용자의 수요가 무엇인지 분석하는 것입니다. 대량의 인력, 물력, 재력, 시간을 투입했지만 개발된 소프트웨어를 원하는 사람이 없다면 모든 투자는 헛수고가 될 것이다. 소프트웨어를 개발하는 데 많은 노력을 기울였으나 결국 사용자의 요구에 부합하지 않는다면, 어쩔 수 없이 다시 개발해야 한다. 이런 재작업은 가슴 아픈 일이다. (모두가 체득할 수 있다고 믿는다.) (윌리엄 셰익스피어, 햄릿, 믿음명언) 예를 들어, 사용자는 리눅스 소프트웨어가 필요하고, 소프트웨어 개발 초기에 소프트웨어 운영 환경을 무시하고, 사용자에게 이 질문을 하는 것을 잊고, 당연히 당신이 windows 를 위한 소프트웨어를 개발하고 있다고 생각합니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 남녀명언) 열심히 개발하여 사용자에게 제출했을 때, 당신은 뭔가 잘못되었다는 것을 알게 되었다. (존 F. 케네디, 노력명언) 그때 너는 울고 싶었고, 두부 한 조각을 찾아 죽고 싶었다.

수요 분석이 중요한 이유는 결정적, 방향성, 전략적 역할을 하며 소프트웨어 개발 과정에서 중요한 역할을 하기 때문이다. 모든 사람은 수요 분석을 충분히 중시해야 한다. 대형 소프트웨어 시스템 개발에서는 프로그래밍보다 훨씬 더 큰 역할을 합니다.

일

간단히 말해서, 수요 분석의 임무는' 무엇을 하는가' 문제를 해결하는 것이다. 즉, 사용자의 요구를 충분히 이해하고 수용된 사용자의 요구를 정확하게 표현하는 것이다.

과정

수요 분석 단계의 작업은 문제 식별, 분석 종합, 사양 개발 및 평가의 네 가지 측면으로 나눌 수 있습니다.

문제 식별: 시스템 관점에서 소프트웨어를 이해하고, 개발된 시스템에 대한 종합적인 요구 사항을 결정하고, 이러한 요구 사항의 실현 조건과 요구 사항이 충족해야 하는 기준을 제시하는 것입니다. 이러한 요구 사항에는 기능 요구 사항 (작업), 성능 요구 사항 (달성된 지표), 환경 요구 사항 (예: 모델, 운영 체제 등) 등이 포함됩니다. ), 안정성 요구 사항 (실패 확률), 보안 요구 사항, 사용자 인터페이스 요구 사항, 리소스 사용 요구 사항 (소프트웨어 운영에 필요한 메모리, CPU 등). ), 소프트웨어 비용 소비 및 개발 진행 요구 사항, 향후 시스템 달성 가능한 목표에 대한 예상.

종합 분석: 모든 소프트웨어 기능을 점진적으로 구체화하고, 시스템 요소, 인터페이스 특성, 설계 제한 간의 관계를 파악하고, 요구 사항 충족 여부를 분석하고, 불합리한 부분을 제거하고, 필요한 부분을 늘립니다. 마지막으로 시스템 솔루션을 종합하여 개발할 시스템의 상세한 논리 모델 (무엇을 할 모델) 을 제공합니다.

사양 개발: 요구 사항을 설명하는 문서를 소프트웨어 요구 사항 사양이라고 합니다. 수요 분석 단계의 결과는 수요 사양이며 다음 단계로 제출됩니다.

검토: 기능 및 기타 요구 사항의 정확성, 완전성 및 명확성을 평가합니다. 검토가 통과돼야 다음 단계의 작업을 진행할 수 있습니다. 그렇지 않으면 수요 분석이 다시 수행됩니다.

방법

수요 분석에는 여러 가지 방법이 있는데, 여기서는 원형법만 강조한다. 구조화 방법 및 동적 분석과 같은 다른 방법은 사용한 적이 없으며 여기서는 논의하지 않습니다.

원형법이 중요하다. 프로토타입은 대상 시스템의 일부 또는 전체 기능을 구현하는 소프트웨어의 이전 실행 가능한 버전입니다.

프로토타입 방법은 목표 시스템의 일부 또는 전체 기능을 달성하기 위해 가능한 한 빨리 대략적인 시스템을 구축하는 것입니다. 그러나 이 시스템에는 안정성, 친숙한 인터페이스 또는 기타 측면에서 결함이 있을 수 있습니다. 이러한 시스템을 구축하는 목적은 알고리즘의 실현 가능성, 기술의 실현 가능성, 사용자의 요구에 부합하는지 여부와 같은 특정 측면의 실현 가능성을 조사하는 것입니다. 예를 들어, 사용자의 요구 사항을 충족하는지 확인하기 위해 일부 소프트웨어 도구를 사용하여 프로토타입 시스템을 신속하게 구축할 수 있습니다. 단지 인터페이스일 뿐, 사용자의 의견을 듣고 이 프로토타입을 개선할 수 있습니다. 미래의 목표 시스템은 프로토타입 시스템을 기반으로 개발될 것이다.

프로토타입은 주로 탐색형, 실험형, 진화형의 세 가지 유형이 있다.

탐구성: 목표 시스템에 대한 요구 사항을 찾고, 원하는 특성을 결정하고, 다양한 시나리오의 실현 가능성을 탐구하는 것을 목표로 한다.

실험형: 대규모 개발 구현 전 검사 방안이 적합한지, 규격이 신뢰할 수 있는지 여부를 확인하는 데 사용됩니다.

진화형: 목적은 규범을 개선하는 것이 아니라 시스템을 쉽게 변경하고 원형을 개선하는 과정에서 원형을 최종 시스템으로 진화하는 것입니다.

프로토타입 방법을 사용할 때 폐기 정책과 추가 정책의 두 가지 전략이 있습니다.

전략 포기: 먼저 기능이 간단하고 품질 요구 사항이 높지 않은 모델 시스템을 구축하고, 반복적으로 수정하여 더 나은 아이디어를 형성하여 보다 완전하고 정확하며 일관되며 신뢰할 수 있는 최종 시스템을 설계합니다. 시스템 구축이 완료되면 원래 모델 시스템은 폐기됩니다. 탐구형과 실험형은 이런 전략에 속한다.

추가 전략: 최종 시스템의 핵심으로 기능적이고 품질 요구 사항이 낮은 모델 시스템을 구축한 다음 지속적인 확장 및 수정을 통해 새로운 요구 사항을 점진적으로 추가하여 최종 시스템으로 발전시킵니다. 진화형은 이런 전략에 속한다.

수요 분석을 위한 20 가지 규칙

고객은 개발자와 교류할 수 있는 좋은 방법이 필요하다. 고객과 개발자가 다음을 검토하여 이해할 수 있는 20 가지 규칙이 있습니다. 의견이 일치하지 않을 경우 협상을 통해 각자의 의무에 대한 상호 이해를 달성함으로써 향후 마찰을 줄일 수 있습니다 (예: 한 쪽이 요구를 하고, 다른 쪽은 요구를 원하지 않거나 충족시키지 못하는 경우).

1. 분석가는 고객의 언어 습관에 맞는 표현을 사용해야 합니다.

수요 토론은 비즈니스 요구 사항과 작업에 초점을 맞추고 있으므로 용어를 사용해야 합니다. 고객은 분석가에게 구매 가격, 인쇄물 등 구매 용어와 같은 용어를 가르쳐야 하지만 고객은 컴퓨터 업계의 용어를 알 필요가 없습니다.

2, 분석가는 고객의 비즈니스와 목표를 이해해야합니다.

분석가가 고객의 업무에 대해 더 잘 이해해야만 제품이 수요를 더 잘 충족시킬 수 있다. 이를 통해 개발자는 고객의 요구와 기대에 부합하는 우수한 소프트웨어를 설계할 수 있습니다. 고객은 개발자와 분석가를 돕기 위해 자신의 워크플로우를 관찰하도록 초대할 수 있습니다. 새 시스템으로 전환하는 경우 개발자와 분석가는 기존 시스템을 사용해야 합니다. 이를 통해 시스템의 작동 방식, 프로세스 및 개선 가능한 측면을 이해할 수 있습니다.

3, 분석가는 소프트웨어 요구 사항 보고서를 작성해야합니다.

분석가는 비즈니스 요구 사항과 사양, 기능 요구 사항, 품질 목표, 솔루션 및 기타 정보를 구분하기 위해 고객으로부터 얻은 모든 정보를 정리해야 합니다. 이러한 분석을 통해 고객은 "요구 사항 분석 보고서" 를 통해 개발자와 고객이 개발할 제품 내용에 동의할 수 있습니다. 보고서는 고객이 쉽게 읽고 이해할 수 있다고 생각하는 방식으로 구성하고 작성해야 합니다. 고객은 이 보고서를 검토하여 보고서 내용이 정확하고 완벽하게 표현되었는지 확인해야 합니다. 고품질' 수요 분석 보고서' 를 통해 개발자는 실제로 필요한 제품을 개발할 수 있습니다.

필요한 작업의 결과에 대한 설명을 요청하십시오.

분석가는 다양한 차트를 텍스트 "수요 분석 보고서" 에 대한 추가 설명으로 사용할 수 있습니다. 작업 다이어그램은 시스템 동작의 일부 측면을 명확하게 설명할 수 있기 때문에 보고서의 차트는 큰 가치가 있습니다. 이해하기 어렵지는 않지만 고객은 익숙하지 않을 수 있으므로 고객은 분석가에게 각 차트의 기능, 기호의 의미 및 요구 사항 개발 작업의 결과, 차트에 오류와 불일치가 있는지 확인하는 방법을 설명할 수 있습니다.

개발자는 고객의 의견을 존중해야합니다.

사용자와 개발자가 서로 이해할 수 없다면 수요 논의에 장애가 있을 수 있다. * * * * 협력을 해야만 모두가' 들을 수 있다' 고 할 수 있다. 수요 개발 프로세스에 참여하는 고객은 개발자에게 프로젝트 성공에 소요되는 시간을 존중하고 소중히 여기도록 요청할 권리가 있습니다. 마찬가지로 고객은 프로젝트 성공의 동일한 목표에 대한 개발자의 노력을 존중해야 합니다.

6. 개발자는 요구 사항 및 제품 구현에 대한 권장 사항과 솔루션을 제공해야 합니다.

일반적으로 고객이 "요구 사항" 이라고 부르는 것은 실행 가능한 구현 시나리오입니다. 분석가는 이러한 솔루션을 통해 실제 비즈니스 요구 사항을 이해하는 동시에 기존 시스템이 현재 비즈니스와 일치하지 않는 점을 파악하여 제품이 고장나거나 비효율적이지 않도록 해야 합니다. 비즈니스 분야에 대해 철저히 파악한 후 분석가는 상당히 좋은 개선 방법을 제시할 수 있으며, 경험 있고 창의적인 분석가는 사용자가 발견하지 못한 가치 있는 시스템 기능을 추가할 수 있습니다.

7. 제품의 사용 특성을 설명합니다

고객은 기능 요구 사항을 충족하면서 분석가에게 소프트웨어의 사용 편의성에 초점을 맞추도록 요청할 수 있습니다. 이러한 사용 편이성 또는 품질 특성을 통해 고객은 보다 정확하고 효율적으로 작업을 수행할 수 있기 때문입니다. 예를 들어, 고객은 때때로 제품 "사용자 친화적인" 또는 "강력한" 또는 "효율적인" 을 요구하지만 개발자에게는 너무 주관적이고 실용적인 가치가 없습니다. 올바른 접근 방식은 분석가가 문의와 조사를 통해 고객이 원하는' 친선, 견고성, 효율성' 의 구체적인 특징을 이해하고, 어떤 특징이 어떤 특성에 부정적인 영향을 미치는지 구체적으로 분석하고, 제안된 솔루션의 성능 비용과 예상 수익 사이의 균형을 조정하여 합리적인 선택을 보장하는 것입니다.

8. 기존 소프트웨어 구성 요소를 재사용할 수 있습니다.

요구 사항은 일반적으로 유연합니다. 분석가는 기존 소프트웨어 구성 요소가 고객이 설명한 요구 사항을 충족한다는 것을 알 수 있습니다. 이 경우 분석가는 개발자가 원래 요구 사항을 엄격하게 따르지 않고도 새 시스템의 개발 비용을 절감하고 시간을 절약할 수 있도록 요구 사항을 수정할 수 있는 옵션을 제공해야 합니다. 따라서 제품에 기존 상용 구성 요소를 사용하고 싶지만 필요한 기능에 완전히 맞지 않는 경우 어느 정도의 수요 유연성이 매우 중요합니다.

9. 변경 비용에 대한 실제적이고 신뢰할 수 있는 평가가 필요합니다.

다른 선택이 있다. 이때 비즈니스 의사 결정을 돕기 위해 수요 변화의 영향을 평가해야 합니다. 따라서 고객은 개발자에게 영향, 비용, 득실 등 분석을 통해 신뢰할 수 있는 평가를 제공하도록 요청할 권리가 있습니다. 개발자는 변경을 원하지 않기 때문에 평가 비용을 임의로 과장해서는 안 됩니다.

10, 고객의 기능 및 품질 요구 사항을 충족하는 시스템을 얻습니다.

모든 사람은 프로젝트가 성공하기를 바라지만, 이를 위해서는 고객이 개발자 시스템에 대해 무엇을 하는 모든 정보를 명확하게 알려야 할 뿐만 아니라, 개발자가 의사 소통을 통해 균형과 제한을 명확하게 이해하고, 당신의 가설과 잠재적 기대를 명확하게 설명해야 합니다. 그렇지 않으면 개발자가 개발한 제품이 만족스럽지 않을 수 있습니다.

1 1. 분석가에게 당신의 업무를 설명하십시오.

분석가는 고객에 의존하여 비즈니스 개념과 용어를 설명하지만, 고객은 분석가가 이 분야의 전문가가 될 것으로 기대할 수 없으며, 고객의 문제와 목표만 이해할 수 있습니다. 분석가가 고객 업무의 미묘한 잠재력을 포착할 것이라고 기대하지 마라. 그들은 고객이 당연하다고 생각하는' 상식' 을 모를 수도 있다.

12, 서둘러 명확하게 말하고 요구 사항을 개선하십시오.

고객은 바쁘지만 어쨌든 고객은' 뇌정상 회의' 토론, 인터뷰 또는 기타 행사에 시간을 내어 수요를 얻어야 합니다. 일부 분석가들은 먼저 당신의 관점을 이해하고 나중에 그들이 당신의 설명이 필요하다는 것을 알게 될 것입니다. 수요를 구체화하는 과정에서, 소프트웨어 제품의 성공에 매우 중요한 사람과 소통하는 자연현상이기 때문에, 일부 수요와 반복을 참을성 있게 다루십시오.

13. 요구 사항을 정확하게 설명합니다.

명확하고 정확한 수요 문서를 작성하기가 어렵다. 디테일을 처리하는 것은 번거롭고 시간이 많이 걸리기 때문에 모호한 수요를 남기기 쉽다. 그러나 개발 과정에서 우리는 이러한 모호함과 부정확성을 해결해야 하며, 고객은 이러한 문제를 해결하기 위한 최선의 선택입니다. 그렇지 않으면 개발자의 정확한 추측에 의존해야 합니다.

수요 분석에 일시적으로 "대기중" 플래그를 추가하는 방법입니다. 이 로고를 사용하여 추가 논의, 분석 또는 정보가 필요한 부분을 나타내며, 특정 요구 사항을 해결하기가 어렵거나 처리할 사람이 없기 때문에 "보류 중" 으로 표시될 수 있습니다. 고객은 분석가가 software requirements report 에 정확하게 기록할 수 있도록 각 요구 사항의 내용을 가능한 한 명확하게 파악해야 합니다. 고객이 일시적으로 정확하게 표현할 수 없는 경우 일반적으로 프로토타입 기술을 사용해야 합니다. 프로토타입 개발을 통해 고객은 개발자와 반복적으로 수정하여 수요의 정의를 지속적으로 개선할 수 있습니다.

14, 제때에 결정

분석가는 고객에게 여러 사용자가 제시한 처리 방법 또는 품질 특성 충돌과 정보 정확도 사이의 절충안을 선택하는 등 몇 가지 선택과 결정을 내릴 것을 요청합니다. 결정권이 있는 고객은 이 모든 것을 적극적으로 처리하고, 가능한 한 빨리 처리하고, 결정을 내려야 한다. 개발자들은 일반적으로 고객이 결정을 내릴 때까지 기다려야 하기 때문이다. 이런 기다림은 프로젝트의 진도를 늦출 수 있기 때문이다.

15. 개발자의 요구 사항, 타당성 및 비용 평가를 존중합니다

모든 소프트웨어 기능에는 비용이 있습니다. 일부 고객이 원하는 제품 기능은 기술적으로 가능하지 않거나, 구현에 많은 비용이 들 수 있으며, 일부 요구 사항은 운영 환경에서 달성할 수 없는 성능을 달성하거나 전혀 얻을 수 없는 데이터를 얻으려고 할 수 있습니다. 개발자는 이에 대해 부정적인 평가를 할 것이며 고객은 그들의 의견을 존중해야 한다.

16. 수요의 우선 순위 지정

대부분의 프로젝트는 기능의 모든 세부 사항을 실현할 수 있는 시간이나 자원이 부족합니다. 필요한 특성과 중요한 특성을 결정합니다. 이는 수요 개발의 주요 부분이며 개발자가 고객의 관점을 기준으로 수요 우선 순위를 결정할 수 없기 때문에 고객만 설정할 수 있습니다. 개발자는 각 수요의 비용 및 위험에 대한 정보를 제공하여 우선 순위를 지정할 수 있습니다.

시간과 자원의 제한 하에, 얼마나 많은 필요한 기능을 완성할 수 있을지 개발자의 의견을 존중해야 한다. 아무도 자신이 원하는 요구가 프로젝트에서 실현되지 않은 것을 보고 싶어하지 않지만, 결국 현실에 직면해야 한다. 상업적 결정은 때때로 프로젝트 범위를 좁히거나 건설 주기를 연장하거나 자원을 늘리거나 우선 순위에 따라 품질에 대한 절충안을 찾아야 할 때가 있다.

17, 요구 사항 문서 및 프로토타입 검토

고객 검토 요구사항 문서는 분석가에게 피드백을 제공할 수 있는 기회입니다. 고객이' 수요 분석 보고서' 가 정확하지 않다고 판단한 경우 가능한 한 빨리 분석가에게 통보하고 개선 방안을 제시해야 한다. 더 좋은 방법은 먼저 제품의 원형을 개발하는 것이다. 이를 통해 고객은 개발자에게 보다 가치 있는 피드백을 제공하여 요구 사항을 더 잘 이해할 수 있습니다. 프로토타입은 실제 애플리케이션은 아니지만 개발자는 이를 완전한 기능을 갖춘 시스템으로 변환하고 확장할 수 있습니다.

18. 요구 사항이 변경되면 바로 연락 주세요.

끊임없는 수요 변화는 예정대로 완성되는 양질의 제품에 심각한 악영향을 미칠 수 있다. 변화는 불가피하지만, 개발 주기 중에 변화가 늦을수록 그 영향은 커진다. 변경으로 인해 비용이 많이 드는 재작업이 발생할 뿐만 아니라 공사 기간이 지연될 수 있습니다. 특히 일반 구조가 완료된 후 새로운 기능을 추가해야 하는 경우 더욱 그렇습니다. 따라서 고객이 요구 사항을 변경해야 한다는 것을 알게 되면 분석가에게 즉시 통보해 주십시오.

19. 개발 팀이 요구 사항 변경을 처리하는 절차를 따릅니다.

변경의 부정적인 영향을 최소화하려면 모든 참여자가 프로젝트 변경 제어 프로세스를 따라야 합니다. 이를 위해서는 제안된 모든 변경 사항을 포기하지 않고 필요한 각 변경 사항을 분석하고 종합적으로 고려한 후 프로젝트에 도입해야 할 변경 사항을 결정하는 적절한 결정을 내려야 합니다.

20. 개발자가 채택한 수요 분석 프로세스를 존중합니다.

소프트웨어 개발의 가장 어려운 부분은 수요를 수집하고 정확성을 확인하는 것입니다. 분석가가 사용하는 방법은 합리적입니다. 고객은 요구 사항 수집 과정이 비용 효율적이지 않다고 생각할지 모르지만, 요구 사항 개발에 소요되는 시간은 매우 소중하다는 점을 명심하십시오. 분석가가 요구 사항 문서를 수집하고 작성하는 데 사용하는 기술을 이해하고 지원하며 품질을 보장한다면 전체 프로세스가 더욱 원활해질 것입니다.

수요 확인이란 무엇을 의미합니까?

수요 분석 보고서 서명은 일반적으로 고객이 수요 분석에 동의하는 상징으로 간주됩니다. 그러나 실제로 고객은 "서명" 이 무의미하다고 생각하는 경우가 많습니다. "요구 문서의 마지막 줄 아래에 서명하라고 했습니다. 서명하겠습니다. 그렇지 않으면 개발자가 코딩을 시작하지 않을 것입니다."

이런 태도는 번거로움을 초래할 수 있다. 예를 들어, 고객이 수요를 바꾸거나 제품에 만족하지 않을 때, 그들은 이렇게 말합니다. "네, 수요 분석 보고서에 서명했지만, 모든 내용을 다 볼 시간이 없었습니다. 나는 너를 믿지만 너는 나에게 서명하라고 했다. "

같은 문제가' 서명 확인' 만 임무 완수로 삼는 분석가에게도 발생한다. 수요가 바뀌면, 그는 "수요 분석 보고서" 를 가리키며 "당신은 이미 수요에 서명했습니다. 그래서 이것이 우리가 개발한 것입니다." 라고 말했다. 만약 네가 다른 것을 원한다면, 너는 일찍 우리에게 말해야 한다. "

이 두 태도는 모두 틀렸다. 프로젝트 초기에 모든 수요를 알 수 없고 수요가 바뀔 수 있다는 데는 의심의 여지가 없기 때문에 수요 분석 보고서에 서명하는 것이 수요 분석 프로세스를 종료하는 올바른 방법이므로 서명이 무엇을 의미하는지 반드시 이해해야 합니다.

"수요 분석 보고서" 의 서명은 수요 계약의 베이스라인을 기반으로 하며 서명을 이해해야 합니다. "이 요구 사항 문서는 프로젝트 정의 변경 프로세스를 통해 추가 변경을 수행할 수 있는 프로젝트의 소프트웨어 요구 사항에 대한 이해를 표현하는 데 동의합니다. 나는 이러한 변화가 우리가 비용, 자원, 프로젝트 임무 등을 재협상할 수 있다는 것을 알고 있다. " 수요 분석에 대한 이해를 이루면 프로젝트 개선과 수요의 실수 또는 시장과 비즈니스의 새로운 요구 사항에서 비롯되는 미래의 마찰을 쉽게 용인할 수 있습니다. 수요 확인은 안개를 없애고, 수요의 진면목을 밝히고, 초기 수요 개발 작업에 명확한 마침표를 찍고, 지속적이고 좋은 고객과 개발자 ONT>； 를 형성하는 데 도움이 된다.