Досега в PMI-PBA® серията от статии ви запознах с домейните Оценка на Нуждите и Планиране. Тази седмица ще обясня и ще представя повече подробности около третия бизнес анализ домейн – Събиране на изисквания и Анализ (Elicitation and Analysis). Това е домейнът, който предполага значителни бизнес анализ активности – извличане на изискванията, анализ, документиране, валидиране, верифициране, приоритизиране и одобрение.
Първо нека разгледаме значението на термина извличане (elicitation), който означава откриване, екстракция. Идеята зад употребата на този термин вместо чистото значение на събиране (gathering) е, че ако използваме събиране, това означава, че изискванията са вече дефинирани и ‘чакат‘ да бъдат събрани. В действителност това почти никога не се случва – изискванията не са готови и не чакат в съзнанието на заинтересованите страни или пък в бизнес документите и затова ние трябва да ги извлечем. Ако може да опишем това метафорично – събирането на изисквания може да бъде сравнено със събиране на цветя, а извличането може да бъде сравнено с археологията – тоест значително ровене и изследване. 🙂
Сега след като вече знаем какво е извличане, нека погледнем различните методи, които имаме за ‘екстракция‘ на изискванията. PMI-PBA® сертификацията признава десет техники за извличане на изискванията, изобразени в диаграмата по-долу:
Независимо от метода, който ще изберете, не се ограничавайте само до един. Опитайте се да използвате комбинация – например facilitated workshop, подкрепен от prototyping и brainstorming, а защо не и observation. Не забравяйте и най-простата и в същото време най-добрата техника – ЗАДАВАНЕТО НА ВЪПРОСИ. 🙂 Бизнес анализаторът трябва да бъде способен да поисква необходимата информация от заинтересованите страни по ясен начин и да не се страхува да ги предизвиква.
Тъй като събраната информация по време на извличането идва в различни формати и нейният обем расте бързо, бизнес анализаторът се нуждае от начин да структурира нейното представяне. Бизнес анализ моделите например диаграми, таблици или структуриран текст са средствата, които улесняват ясното представяне и предаване на информация.
За да подсигури качеството на извлечените изисквания, бизнес анализаторът трябва да може да извърши валидиране и верифициране, активности, които са често грешно разбирани като едно и също действие. Всъщност, и двете са правилни методи, но всеки от тях има специфично значение и приложение. Валидиране (validation) се отнася до подсигуряването, че изискванията отговарят на очакванията на заинтересованите страни, докато верифициране (verification) подсигурява, че изискванията отговарят на стандартите за качество и че не съдържат грешки. Няма специфичен ред, по който тези проверки да бъдат извършени, но като цяло е най-добре първо изискванията да бъдат утвърдени със заинтересованите страни и по-късно само ‘правилните‘ изисквания да бъдат потвърдени.
Много малко на брой софтуерни проекти могат да предоставят всички функционалности, които заинтересованите страни изискват и същевременно да се вместят в първоначално дефинирания период за изпълнение. Тъй като всеки проект има ограничения (обхват, бюджет, време), е необходимо да се дефинират приоритети на зададените функционалности и характеристики на продукта. Приоритизацията помага разкриването на конкуриращи се цели, разрешаването на конфликти, планирането на частични резултати, управлението на обхвата и вземането на необходимите решения отнасящи се до какво трябва да бъде изпълнено и кога трябва да бъде изпълнено. Има няколко развити техники, които се следват от различни бизнес анализатори за приоритизиране на изискванията, най-известни от които са следните:
- In or Out
- Three-level scale
- MoSCoW
- Weighted ranking
- Ranking
- 100 $
- Time-boxing
- Multivoting
- Prioritization matrix based on value, cost, and risk
След като изискванията са приоритизирани, финалната стъпка в този домейн е одобрението им, което може да бъде формално или неформално и честотата и методите му е добре да бъдат предварително одобрени в домейна бизнес анализ планиране.
Веднъж като установените изисквания са одобрени, те са поставени в изходно ниво и всяка промяна по тях трябва да бъде контролирана. Повече за процеса за контрол на промените ще разкажа в следващата статия от PMI-PBA® серията за домейна Проследяване и Контролиране (Traceability and Monitoring). Освен как да се организира процесът за проследяване на промените, ще разгледаме и матрица за проследяване и как ефективно да проследяваме изисквания обратно до оригиналната цел на продукта/ проекта, как да идентифицираме и управляваме зависимости.
Вижте повече тук за:
- PMI Professional In Business Analysis (PMI-PBA)® Certification Preparation Training
- Насоки за PMI-PBA сертификационния изпит
PMI-PBA е регистрирана марка на Project Management Institute, Inc.
