Техники за анализ на изискванията с пример: Пълен урок
Като бизнес анализатор, анализът на изискванията е най-важната част от вашата работа. Ще стане да ви помогне да определите действителните нужди на заинтересованите страни. В същото време ви дава възможност да общувате със заинтересованите страни на език, който те разбират (като диаграми, модели, блок-схеми) вместо сложен текст.
Анализът на изискванията има a
- Конкретна цел
- Специфичен вход
- Специфичен изход
- Използва ресурси
- Има редица дейности, които трябва да бъдат извършени в определен ред
- Може да засегне повече от една организационна единица
- Създава някаква стойност за клиента
Техники за анализ на изискванията
Техниките за анализ на изискванията се използват главно за картографиране на работния поток на бизнеса, така че да можете да анализирате, разберете и направите необходимите промени в този работен поток или процес.
Има различни техники за анализ на изискванията, които могат да се използват според разработка на софтуер процес като
1. Нотация за моделиране на бизнес процеси (BPMN)
BPMN (Business Process Modeling & Notation) е графично представяне на вашия бизнес процес с помощта на прости обекти, което помага на организацията да комуникира по стандартен начин. Различни обекти, използвани в BPMN, включват
- Поточни обекти
- Свързване на обекти
- Алеи за плуване
- Артефакти.
Един добре проектиран BPMN модел трябва да може да даде подробности за дейностите, извършвани по време на процеса, като,
- Кой извършва тези дейности?
- Какви елементи от данни са необходими за тези дейности?
Най-голямата полза от използването на BPMN е, че е по-лесно да се споделя и повечето инструменти за моделиране поддържат BPMN.
2. UML (унифициран език за моделиране)
UML е стандарт за моделиране, използван предимно за спецификация, разработка, визуализация и документиране на софтуерна система. За улавяне на важни бизнес процеси и артефакти UML предоставя обекти като
- Област
- Обект
- Дейност
- Класова диаграма
Има 14 UML диаграми, които помагат при моделирането като диаграма на случаи на използване, диаграма на взаимодействие, диаграма на класове, диаграма на компоненти, диаграма на последователност и т.н. UML моделите са важни в ИТ сегмента, тъй като той се превръща в средство за комуникация между всички заинтересовани страни. Базиран на UML бизнес модел може да бъде директен вход към инструмент за изисквания. UML диаграмата може да бъде от два типа поведенчески модел и структурен модел. Поведенческият модел се опитва да даде информация за това какво прави системата, докато структурният модел ще даде от какво се състои системата.
3. Техника на диаграмата
Блок-схемата е визуално представяне на последователния поток и контролна логика на набор от свързани дейности или действия. Има различни формати за блок-схеми, които включват линейни, отгоре надолу и кръстосано функционални (алеи за плуване). Блок-схема може да се използва за различни дейности като представяне на потоци от данни, системни взаимодействия и т.н. Предимството на използването на блок-схема е, че тя може да бъде лесна за четене и писане дори от нетехнически членове на екипа и може да показва паралелния процес по функция , критични атрибути на процес и др.
4. Диаграма на потока от данни
Диаграмите на потока от данни показват как данните се обработват от системата по отношение на входове и изходи. Компоненти на диаграмата на потока от данни включва
- Процес
- Състояние на Поток
- Магазин
- Терминатор
Диаграмата на логическия поток от данни показва дейностите на системата, докато диаграмата на физическия поток от данни показва инфраструктурата на системата. Диаграмата на потока от данни може да бъде проектирана рано в процеса на извличане на изискване на фазата на анализ в рамките на SDLC (Жизнен цикъл на развитие на системата), за да определите обхвата на проекта. За лесно анализиране диаграмата на потока от данни може да бъде разширена до нейните подпроцеси, известни като „нивелирана DFD“.
5. Диаграми на ролевите дейности (RAD)
Диаграмата на дейността на ролята е подобна на нотацията на типа блок-схема. В диаграмата на ролевите дейности екземплярите на ролите са участници в процеса, който има начално и крайно състояние. RAD изисква задълбочено познаване на процеса или организацията, за да идентифицира ролите. Компонентите на RAD включват
- Дейности
- Външни събития
- членки
Ролите групират дейностите заедно в единици на отговорност, според набора от отговорности, които изпълняват. Дейност може да се извършва изолирано с роля или може да изисква координация с дейности в други роли.
Външните събития са точките, в които настъпват промени в състоянието.
Състоянията са полезни за картографиране на дейности на роля, докато тя напредва от състояние в състояние. Когато се достигне определено състояние, това показва, че определена цел е постигната.
RAD е полезен в подкрепа на комуникацията, тъй като е лесен за четене и паралелно представя подробен изглед на процеса и разрешителните дейности.
6. Диаграми на Гант
Диаграмата на Гант е графично представяне на график, който помага за координиране, планиране и проследяване на конкретни задачи в даден проект. Той представлява общия период от време на обекта, разбит на стъпки. Диаграмата на Гант представлява списък на всички задачи, които трябва да бъдат изпълнени по вертикалната ос, докато по хоризонталната ос изброява прогнозната продължителност на дейността или името на лицето, назначено за дейността. Една диаграма може да демонстрира много дейности.
7. IDEF (Интегрирана дефиниция за функционално моделиране)
IDEF или интегрирана дефиниция за функционално моделиране е общоприето име, отнасящо се до класове корпоративни езици за моделиране. Използва се за дейности по моделиране, необходими за подпомагане на системния анализ, проектиране или интеграция. Има около 16 метода за IDEF, най-полезните версии на IDEF са IDEF3 и IDEF0.
8. Цветни мрежи на Петри (CPN)
CPN или цветните мрежи на Петри са графично ориентиран език за спецификация, проверка, проектиране и симулация на системи. Цветните мрежи на Петри са комбинация от графика и текст. Основните му компоненти са Места, преходи и дъги.
Обектите на мрежите на Петри имат специфичен надпис като for
- места: Има надпис като .Name, .Color Set, .Initial маркировка и др.
- Преход : има надпис като .Name (за идентификация) и .Guard (булев израз се състои от някои от променливите)
- дъги: Има надпис като .Arc. Когато изразът на дъгата се оценява, той дава множество цветове на токени.
9. Техника на работния процес
Техниката на работния процес е визуална диаграма, която представя един или повече бизнес процеси, за да се изясни разбирането на процеса или да се направят препоръки за подобряване на процеса. Подобно на други диаграми като блок-схеми, UML дейност и карта на процеси, техниката на работния поток е най-старата и популярна техника. Той дори се използва от BA за водене на бележки по време на извличане на изисквания. Процесът се състои от четири етапа
- Събиране на информация
- Моделиране на работния процес
- Моделиране на бизнес процеси
- Внедряване, проверка и изпълнение
10. Обектно ориентирани методи
Методът за обектно-ориентирано моделиране използва обектно-ориентирана парадигма и език за моделиране за проектиране на система. Акцентът е върху намирането и описанието на обекта в проблемната област. Целта на обектно-ориентирания метод е
- За да помогне за характеризирането на системата
- Да знаете какви са различните релевантни обекти
- Как се свързват помежду си
- Как да специфицираме или моделираме проблем, за да създадем ефективен дизайн
- Да се анализират изискванията и техните последици
Този метод е приложим за система, която има динамични изисквания (чести промени). Това е процес на извличане на случаи на използване, поток от дейности и поток от събития за системата. Обектно ориентиран анализ може да се направи чрез текстови нужди, комуникация със заинтересованите страни в системата и документ с визия.
Обектът има състояние, а промените в състоянието са представени чрез поведение. Така че, когато обектът получи съобщение, състоянието се променя чрез поведение.
11. Анализ на пропуските
Gap Analysis е техниката, използвана за определяне на разликата между предложеното състояние и текущото състояние за всеки бизнес и неговите функционалности. Той отговаря на въпроси като какво е текущото състояние на проекта? Къде искаме да бъдем? и т.н. Различни етапи на Gap Analysis включват
- Revсистема iew
- Изисквания за развитие
- сравнение
- Последици
- Препоръки