다음에서는 주로 수요 개발과 수요 관리라는 두 가지 측면에서 요구 사항을 분석합니다. 1. 현재 실제 업무 상황으로 볼 때 수요 개발은 주로 다음과 같은 부분으로 나누어집니다. 업계 전문가와 상담하십시오. 업계 고객의 정보화 요구가 점점 더 세분화되고 있으며 전문성과 업계 역량에 대한 포괄적인 요구 사항이 있습니다. 점점 더 높이 올라갑니다. 업계에 깊이 파고들어 해당 업계의 요구 사항을 이해하고 고객 요구에 더욱 적합한 제품을 개발해야만 성공할 수 있습니다. 따라서 먼저 해당 분야의 업계 전문가에게 문의하여 프로세스 관점에서 고객의 비즈니스 요구 사항을 정리하는 것이 필요합니다. 고객에게 직접 이야기를 나누고 실제 요구 사항을 파악하는 대신 업계 전문가를 초대하는 이유는 무엇입니까? 개인적으로 현재 다양한 정부 부처, 기업 및 기관이 정보화와 업계 요구를 통합하는 경험이 부족하고 대부분의 상황을 완전히 정리할 수 없기 때문이라고 생각합니다. . 완전하고 명확한 시스템 요구사항을 생각해 보세요. 업계 전문가를 통해 실제 비즈니스 프로세스를 정리해야만 고객과 공감하기가 더 쉽고, 지식의 차이로 인해 오해되는 니즈의 발생도 크게 줄일 수 있습니다. 고객과의 대화 다양한 수준과 부서의 고객을 상대하고, 고객을 분류하고, 요구사항의 우선순위를 정해야 합니다. 당신이 하고 있는 프로젝트 사업이 익숙하다면 괜찮습니다. 익숙하지 않다면, 업계 전문가를 고용해야 한다고 위에서 언급한 이유입니다. 첫 번째. 결국 고객이 체계적으로 비즈니스를 소개하는 것은 불가능합니다. 업계 비즈니스를 잘 알아야 사용자와 소통하고 고객을 정확하고 효과적으로 안내할 수 있으며 수요 분석도 잘 할 수 있습니다. 고객이 자신의 요구 사항을 명확하게 설명하는 것을 기대할 수는 없습니다. 물론 이는 시스템 분석가의 책임이기도 하다. 요구사항 작성을 시작할 때, 현재 접촉하고 있는 고객이 실제 비즈니스 고객인지 여부를 파악하는 데 시간을 투자해야 합니다. 당신은 약간의 곤경에 처해 있습니다. 아마도 그는 클라이언트 회사에서 파견한 IT 부서의 사람일 수도 있습니다. 그는 많은 것을 언급할 것이지만 이러한 것들은 실제 비즈니스에서 요구되는 기능이 전혀 아닐 수도 있으며 일반적으로 그는 몇 가지 기술 구현 제안을 열정적으로 제공할 것입니다. . 이때 주의해야 할 점은, 그의 말을 듣다 보면 결국 자신이 해결하는데 많은 에너지를 쏟은 문제가 실제로는 고객이 필요로 하는 문제가 아니라는 것을 알게 될 수도 있습니다. 하지만 실제로 주의를 기울여야 할 사항은 충분하지 않습니다. ? 다른 유사한 소프트웨어 및 시스템을 참조하십시오. 고객과 소통하고 예비 요구 사항을 형성한 후, 먼저 일부 이전 시스템을 참조하여 학습된 요구 사항과 원래 시스템의 차이점을 파악하십시오. 요구 사항에 대한 오해로 이어질 수 있습니다. ?비즈니스 모델링요구 사항에 대한 그래픽 분석 모델은 소프트웨어 요구 사항 사양을 훌륭하게 보완합니다. 부정확하고, 일관성이 없으며, 누락되고 중복되는 요구 사항을 찾는 데 도움이 되는 다양한 정보와 관계를 제공할 수 있습니다. 이러한 모델에는 데이터 흐름 다이어그램, 엔터티 관계 다이어그램, 상태 전환 다이어그램, 대화 다이어그램, 개체 클래스 및 상호 작용 다이어그램이 포함됩니다. ? 요구 사항을 모아서 요구 사항 사양을 작성합니다. 회사마다 다르며 동일할 필요는 없지만 각 요구 사항 사양에는 최소한 검토를 통과한 소프트웨어 요구 사항이 포함되어야 한다고 생각합니다. 기준을 설정하고 구성 관리 라이브러리에 통합합니다. 구성 관리 라이브러리의 문서나 코드는 더 이상 쉽게 수정할 수 없습니다. 변경수요가 있는 경우 반드시 신청서를 제출하고 수요변경계획을 작성한 후 승인을 거쳐야 변경권한이 부여됩니다. 그런 다음 구성 관리자는 요구 사항을 잘 추적해야 합니다. , 변경 요구 사항에 관련된 모든 개발자와 테스터는 동기적으로 통보되어야 하며 적시에 해당 부분의 다양한 문서를 수정할 수 있도록 허용되어야 합니다. ? 요구사항 변경 관리 저는 개인적으로 요구사항 변경 관리가 문제를 일으킬 가능성이 가장 높다고 생각하며, 이는 주로 일반 프로젝트를 완료할 수 없는 이유입니다. 요구 사항 변경은 주로 사용자가 프로젝트의 요구 사항 결정 단계에서 필요한 것을 정확하게 정의할 수 없기 때문에 발생합니다. 사용자는 종종 자신이 그것을 알고 있다고 생각하지만 실제로 그들이 제시하는 요구 사항은 현재 작업 요구 사항에만 기반을 두고 있으며 채택된 새로운 장비와 새로운 기술은 일반적으로 작업 방식을 변경하거나 개발할 시스템도 사용자에게 알려지지 않습니다. 그들은 그것에 대한 이전 경험이 없습니다. 개발 작업이 계속 진행됨에 따라 시스템은 기능의 프로토타입을 보여주기 시작하고 사용자는 점차 시스템에 대한 더 깊은 이해를 얻게 됩니다.
결과적으로 그들은 다양한 새로운 기능과 특징을 생각하거나 이전에 요청한 내용을 변경할 수도 있습니다. 더 많이 배울수록 더 많은 새로운 요구 사항이 발생하므로 요구 사항의 변경은 필연적으로 반복해서 발생합니다. 수요 변화를 효과적으로 관리하는 방법은 다음과 같습니다. 우리 회사의 현재 관행은 다음과 같습니다. 회사에서는 수요 관리 도구로 Test Director를 사용하고 있으며, 수요 담당자는 고객과의 모든 커뮤니케이션 후 수요 설문지를 작성하여 Test Director에 입력하고 이를 종합 및 정리하여 수요 사양을 형성한 후 R&D 부서에서 검토합니다. 제품부서, 영업사원(고객이 참여하면 더 좋을 것 같습니다.) 니즈 검토를 실시하고 니즈 기준선을 수립합니다. 간단하고 효과적인 변경 제어 프로세스를 개발하고 문서화합니다. 수요 기준선이 설정된 후 제안된 모든 변경은 변경 제어 프로세스에 따라 제어되어야 합니다. 동시에 모든 중요한 수요 변경에는 수요 변경이 유효한 것으로 간주되기 전에 확인을 위한 고객의 서명이 필요합니다. 요구 사항이 변경된 후에는 업데이트된 요구 사항과의 일관성을 유지하기 위해 영향을 받는 소프트웨어 계획, 제품 및 활동도 그에 따라 변경되어야 합니다.