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