수요는 도대체 무엇입니까? -Volere 요구 사항 프로세스
수요가 존재하거나, 이러한 유형의 제품에 특정 기능과 품질이 필요하거나, 고객이 이러한 요구를 납품된 제품의 일부라고 부르기를 원하기 때문입니다.
1. 기능 요구 사항은 제품이 반드시 완성해야 하는 일이다.
비 기능성 수요는 제품의 속성과 품질입니다. 소유자 및 운영자가 제품을 수락하려면 이러한 속성이나 품질이 있어야 합니다. 비기능적 요구사항은 모양과 느낌, 가용성, 보안 및 법적 제한과 같은 요구 사항을 설명합니다.
3. 제한 사항
제약 조건은 글로벌 요구 사항입니다. 프로젝트 자체나 제품의 최종 설계에 대한 제한일 수 있습니다. 제약은 또 다른 요구 사항일 뿐이다.
둘째, Volere 요구 사항 프로세스
이 프로세스의 목적은 요구사항을 성공적으로 수집, 검증 및 문서화하는 것입니다.
Volere 는 이탈리아어로' 희망' 과' 원한다' 를 의미한다.
이 프로세스를 통해 수행하는 작업은 프로세스가 아닌 관련 제출 제품에 의해 구동됩니다. (제품 요구 사항에 따라 이 프로세스의 각 작업 세트에 대해 서로 다른 상세 수준이 있습니다.)
셋째, 수요 과정의 기본 틀
사용자 정의 시스템 구축, 구성 요소 통합 시스템 구축, 상업용 패키지 사용, 오픈 소스 소프트웨어 사용, 아웃소싱 개발, 기존 소프트웨어 수정 등 요구 사항을 검색, 캡처 및 전달해야 합니다.
Volere 요구 사항 프로세스를 사용하는 고객은 제품 개발 시 RUP, 증분, 반복, 나선형, Scrum 또는 기타 유형의 반복 개발 프로세스를 채택하고, 일부 고객은 더욱 공식적인 폭포 프로세스나 맞춤형 개발 프로세스를 채택하고 있습니다. 올바른 제품을 구축하려면 올바른 요구 사항을 찾아야 합니다. 정확하고 완전한 수요를 찾기 위해서는 질서 정연한 과정이 필요하다.
프로젝트 시작-수요 수집-빠르고 불완전한 모델링-장면-작성 요구 사항-품질 관리-재사용 요구 사항-검토 요구 사항-반복 및 증분 프로세스-수요 반사-수요 진화-템플릿-SNS
① 회의 시작은 업무 문제의 범위를 정하고 이해 관계자의 합의를 위해 노력한다. 이 가운데 이해 관계자들은 모두 그것에 대한 수요가 있는 사람들이다.
② 프로젝트의 시작은 또한 프로젝트의 목표를 수립했다.
③ 이 단계에서는 프로젝트 수요 부분에 관련된 비용을 초보적으로 산정할 수 있는데, 이는 좋은 프로젝트 관리 관행이다. 이 작업은 작업 범위 모델에 포함된 정보를 통해 수행할 수 있습니다.
④ 조기 평가 프로젝트가 직면할 수 있는 위험도 좋은 프로젝트 관리 관행이다.
⑤ 마지막으로, 팀원들은 프로젝트가 실현 가능한지 여부에 대해 합의를 보았다. 이것은' 가든지 멈추든지' 의 결정이다. 또는 이 시점에서 아직 알 수 없는 것이 많은 경우 창업팀은 수요 조사를 시작한 다음 신속하게 수요를 검토하여 프로젝트의 가치를 재평가할 수 있습니다.
수요를 끌어들이다
동원회 이후 수요 분석가들은 업무 중인 기능을 배우고 이해하기 시작했다. 작업 환경 맵을 비즈니스 사용 사례로 나눕니다. 각 비즈니스 사용 사례는 기능의 일부입니다. 각 업무 이벤트에는 수요 분석가가 지정됩니다.
분석가는 견습생, 장면 분석 및 사용 사례 세미나와 같은 기술을 사용하여 작업의 진정한 성격을 발견할 수 있습니다.
문제의 본질은 이 제품의 밑바닥 업무를 가지고 있는 이유이거나, 우리가 그것을 작업 전략으로 삼을 수도 있고, 기술 없이는 어떤 일이 벌어질지 상상할 수도 있다. (존 F. 케네디, 일명언)
3. 빠르고 불완전한 모델링
일부 공식 모델은 UML 또는 BPMN 에서 제작되었지만 비즈니스 분석가가 빠른 스케치를 사용하여 연구 작업을 효과적으로 모델링할 수 있는 경우가 많습니다.
이 시나리오는 비즈니스 프로세스의 기능을 보여줍니다. 장면은 수요의 기초입니다.
5. 쓰기 요구 사항
분석가는 개발에 참여하는 모든 당사자가 무엇을 해야 하는지에 대한 합의에 도달할 수 있도록 요구 사항을 작성합니다. 이것은 수요의 본질이 기록되고 교류되고 납품된 제품을 테스트할 수 있는 가장 효과적인 방법이다.
분석가는 두 가지 메커니즘을 사용하여 수요 사양 작성을 단순화합니다. 첫 번째 메커니즘은 수요 사양의 요약인 수요 사양 템플리트입니다.
두 번째 메커니즘은 각 수요에 올바른 구성 요소가 있는지 확인하기 위해 "스노우 카드" 라고도 하는 수요 항목 프레임워크입니다.
6. 품질 관리
수요는 뒤의 모든 일의 기초이므로 반드시 정확성을 보장해야 한다. 품질 관리 검사 요구 사항.
보통 1-2 명으로 구성되며 수석 수요 분석가이거나 테스터일 수 있습니다. 오직 그들만이 수요가 품질 관문을 통과할 수 있도록 허락할 권리가 있다. 수요 사양에 수요를 추가할 수 있도록 허용하기 전에 각 수요의 무결성, 종속성, 테스트 가능성, 일관성, 추적 가능성 및 기타 품질 속성을 함께 확인합니다.
7. 재사용 요구 사항
새로운 요구 사항 프로젝트를 시작하기 전에 이전 프로젝트의 사양을 살펴보고 재사용 가능한 항목을 찾습니다. 때로는 많은 수요를 재사용 할 수 있다는 것을 알게됩니다.
8. 요구 사항 검토
검토는 규범이 완전하고 적절하다는 것을 보장하여 우리가 다음 개발 단계로 들어갈 수 있도록 한다. 이 프로세스는 위험을 평가하고 비용을 계산하여 수요에 대한 합리적인 검토를 수행합니다.
9. 반복 및 증분 프로세스
수요업계에는 수요가 전통적인 폭포수 프로세스를 채택하는 것이라는 일반적인 오해가 있는데, 이는 어떤 경우에는 옳지만, 지금은 항상 그런 것은 아니다. (윌리엄 셰익스피어, 윈스턴, 수요명언)
제품은 작은 증분으로 개발할 수 있다. 이렇게 하면 가능한 한 빨리 몇 가지 용례를 실현하고 관계자들의 피드백을 받을 수 있다는 장점이 있다.
10. 수요 반영
수요 반성의 과정은 발견 과정의 장점과 단점이다. 이 과정에는 이해 관계자와의 면담 및 개발자와의 그룹 회담이 포함됩니다.
반성은 비공식적인 방식으로 진행될 수 있습니다. 커피를 마시는 시간에 프로젝트 팀과 대화를 나누거나 프로젝트 책임자가 이메일을 통해 프로젝트 참가자로부터 정보를 수집하는 것입니다.
1 1. 수요 진화
수요는 제품 개발 과정에 따라 발전한다. 처음에는 상당히 모호한 생각이었습니다. 시간이 지남에 따라 제품 아이디어가 등장하면서 수요는 정확하고 테스트 가능해졌다. 진화는 전후할 수 있다. (기능 요구 사항, 비기능 요구 사항, 제약)
12. 템플릿
Volere requirements specification 템플릿-제품 기능 및 기능에 대한 완전한 청사진입니다.
템플릿 디렉토리:
프로젝트 중심-프로젝트의 원인과 동기를 설명합니다.
1. 프로젝트의 목표-제품 구축에 투자한 이유와 이를 통해 얻을 수 있는 상업적 이익.
2. 고객, 고객 및 기타 이해 관계자-제품은 그들의 이익이나 그들에게 미치는 영향을 포함한다.
3. 제품 사용자-예상 최종 사용자 및 제품 가용성에 미치는 영향.
프로젝트 제약-프로젝트 및 제품에 대한 제약
4. 수요 제약-프로젝트 제한 및 제품 제약.
5. 명명 기준 및 정의. 프로젝트 용어
6. 관련 사실과 가정-제품에 영향을 미치는 외부 요소 또는 개발자가 만든 가정.
기능 요구 사항-제품의 기능
7. 작업 범위-대상 업무 영역
8. 제품 범위-예상 제품의 경계 및 인접 시스템과의 연계를 정의합니다.
9. 기능 및 데이터 요구 사항-제품이 무엇을 해야 하는지, 기능적으로 작동하는 데이터.
비기능 요구 사항-제품 품질
10. 인식 요구 사항-예상 모양
1 1. 사용 편의성 및 인간화 요구 사항-예상 사용자가 성공적으로 사용하려면 제품이 어떻게 보여야 합니까?
12. 구현 요구 사항-속도, 크기, 정확성, 개인 안전, 신뢰성, 견고성, 확장성, 내구성 및 용량.
13. 운영 및 환경 요구 사항-제품의 예상 운영 환경
14. 서비스 및 지원 요구 사항-제품 수정성은 어느 수준에 도달해야 하며 어떤 지원이 필요합니까?
15. 보안 요구 사항-제품의 정보 보안, 기밀성 및 무결성.
16. 문화 및 정책 요구 사항-인문학 및 사회적 요인
17. 법적 요구 사항-관련 법률 준수?
프로젝트 문제-건축 제품에 적용되는 프로젝트입니다.
18. 열린 문제-해결되지 않은 문제들이 프로젝트의 성공에 영향을 줄 수 있습니다.
19. 기성품 솔루션-처음부터 개발하는 대신 기존 구성 요소를 사용합니다
20. 새로운 문제-신제품 도입으로 인한 문제.
2 1. 임무-제품을 사용에 투입하기 위해 반드시 해야 할 일.
22. 신제품으로 마이그레이션-기존 시스템에서 전환하는 작업
위험-프로젝트가 직면 할 가능성이 가장 큽니다.
24. 비용-제품 구축 비용 또는 작업량에 대한 조기 추정
25. 사용 설명서-사용 설명서 및 문서에 대한 계획을 만듭니다.
26. 후속 릴리즈의 요구 사항-제품의 향후 릴리스에 포함될 수 있는 요구 사항.
27. 솔루션 아이디어-우리가 놓치고 싶지 않은 디자인 아이디어.
13. 스노우 카드
템플릿은 무엇을 쓰는지, 스노우 카드가 어떻게 쓰는지에 대한 안내서입니다.
요구 사항을 기록, 분석 및 추적하는 데 사용할 수 있는 자동화 도구가 있습니다.
14. 사용자 정의 요구 사항 프로세스
15. 공식 안내서