Моделиране и дизайн на софтуерни системи

Обектно – ориентиран анализ и проектиране с UML

1 Тема: Въведение в UML
Структурни UML модели:
UML съдържа 8 структурни диаграми:
Диаграма на класовете (Class diagram)
Диаграма на обектите (Object diagram)
Диаграма на компонентите (Component diagram)
Диаграма на профила (Profile diagram)
Диаграма на разгръщането (Deployment diagram)
Диаграма на пакетите (Package diagram)
Композитно-структурна диаграма (Composite structure diagram)
Добри практики за диаграмите:
Диаграматите трябва да бъдат лесно разбираеми и четими.
Но не твърде елементарни.
Комбинация от статичните и динамичните диаграми.
Диаграмата да се именова съобразно предназначенето `и.
Диаграмите се организират йерархично в пакети.
Да се въздържаме от използването на пресичащи се линии.
Логическите свързани елементи се изобразяват близо един до друг.
Използвайте различни цветове и допълнителни бележки, за да фокусирате вниманието върху важни
елементи в диаграмата.
Цели:
Да се запознаем с основните концепции на UML.
Да се разбере значението на UML в софтуерното инженерство.
Съдържание:
Какво е UML?
Определение и история:
UML (Unified Modeling Language) е стандартен език за визуализиране, специфициране, конструиране и документиране на артефакти на софтуерни системи. Разработен през 1990-те години от Grady Booch, Ivar Jacobson и James Rumbaugh, UML съчетава
техните три методологии: Booch, OMT (Object-Modeling Technique) и OOSE (Object-Oriented Software
Engineering).

Основни цели на UML:
Улесняване на разбирането и комуникацията между различните заинтересовани страни (разработчици, клиенти, мениджъри и др.).
Подобряване на качеството на софтуера чрез осигуряване на стандартизирани визуални средства за анализ и дизайн.
Подпомагане на документацията и поддръжката на софтуерните системи.
Версии и еволюция на UML:
UML 1.x: Първоначална версия с базовите диаграми и концепции.
UML 2.x: Разширения и подобрения в диаграмите и спецификациите, добавяне на нови диаграми.
Защо да използваме UML?
Ползи от използването на UML:
Ясна визуализация на софтуерните структури и процеси. Подобрена комуникация между екипа. Лесно идентифициране на грешки и несъответствия в ранните етапи на проектирането. Улеснено управление и поддръжка на софтуерни системи.
Приложения в различни фази на софтуерния жизнен цикъл:
Анализ на изискванията.
Проектиране на системата.
Разработка и тестване.
Поддръжка и обновяване.
UML диаграми:
Преглед на различните типове диаграми:
Структурни диаграми:
Диаграми на класовете.
Диаграми на обектите.
Диаграми на компонентите.
Диаграми на внедряване.
Диаграми на пакетите.
Поведенчески диаграми:
Диаграми на случаите на употреба.
Диаграми на дейностите.
Диаграми на състоянията.
Интеракционни диаграми:
Диаграми на последователността.
Диаграми на комуникацията.
Диаграми на времевите диаграми.
Диаграми на взаимодействията.
Основни елементи на UML:
Актьори, обекти, класове, съобщения и др.:
Актьори: Външни обекти, които взаимодействат със системата (потребители, други системи).
Обекти: Инстанции на класове, които взаимодействат помежду си.
Класове: Определят структурата и поведението на обектите.
Съобщения: Начинът, по който обектите комуникират помежду си.
Символи и нотации в UML:
Описание на основните символи и нотации, използвани в UML диаграмите (например, правоъгълници за класове, линии за асоциации, стрелки за съобщения и т.н.).
Примери за използване на UML:
Примери от реалния свят:
Примери за UML диаграми, използвани в реални проекти.
Обсъждане на това как тези диаграми са подпомогнали процеса на разработка.
Демонстрация на софтуерни инструменти за UML:
Въведение в популярни инструменти за моделиране с UML (например, Enterprise Architect, Rational Rose, Visual Paradigm).
Кратка демонстрация на създаване на UML диаграма с помощта на един от инструментите.

1.1 Въведение в ролята на бизнес анализатора
1. Какво е бизнес анализатор?
Бизнес анализаторът (Business Analyst, BA) е ключова фигура в организацията, отговорна за идентифициране на бизнес нужди и проблеми и предоставяне на решения, които добавят стойност към бизнеса. Те служат като връзка между различни заинтересовани страни, включително мениджъри, разработчици на софтуер и крайни потребители.
1.2. Основни отговорности на бизнес анализатора
Събиране и анализ на изисквания: Бизнес анализаторът събира и документира изискванията на проекта от заинтересованите страни. Това включва интервюта, работни срещи и анализ на документи.
Разработване на решения: Анализаторът работи с екипа, за да разработи и предложи решения на идентифицираните бизнес проблеми. Комуникация с заинтересованите страни: Бизнес анализаторът служи като посредник между техническия екип и бизнес потребителите, като осигурява ясна комуникация и разбиране.
Управление на изискванията: Те управляват и приоритизират изискванията през целия жизнен
цикъл на проекта, като гарантират, че те са ясно дефинирани и разбираеми.
Оценка и валидиране: Анализаторът оценява предложените решения, валидира ги с заинтересованите страни и следи за тяхното изпълнение и ефективност.

1.3. Основни умения на бизнес анализатора
Аналитични умения: Способността да анализират и интерпретират данни, да разбират сложни процеси и да предлагат ефективни решения.
Комуникационни умения: Ефективното общуване със заинтересованите страни е ключово. Бизнес анализаторите трябва да могат да обясняват технически детайли на нетехнически аудитории.
Умения за решаване на проблеми: Способността да идентифицират проблеми и да намират креативни и ефективни решения.
Управление на проекти: Знанията за управление на проекти помагат на бизнес анализатора да координира различни аспекти на проектите и да ги движи напред.
Технически умения: В зависимост от индустрията, бизнес анализаторите може да се нуждаят от
специфични технически знания и умения, включително работа със софтуерни инструменти за моделиране и анализ.

1.4. Процес на бизнес анализ
Процесът на бизнес анализ включва няколко ключови стъпки:
Инициация: Определяне на целите и обхвата на анализа, идентифициране на ключовите заинтересовани страни.
Събиране на изисквания: Използване на различни техники за събиране на изисквания, включително интервюта, анкети, фокус групи и анализ на документи.
Анализ и документация: Анализиране на събраните данни и документиране на изискванията в ясна и структурирана форма.
Разработване на решения: Предлагане на решения, които отговарят на изискванията и добавят стойност към бизнеса.
Валидиране и тестване: Валидиране на решенията със заинтересованите страни и провеждане на тестове, за да се гарантира, че те отговарят на нуждите.
Изпълнение: Подпомагане на екипа при изпълнението на решенията и следене на тяхната ефективност.

1.55. Инструменти и техники
Бизнес анализаторите използват разнообразие от инструменти и техники, за да изпълняват своите задачи:
Диаграми: UML диаграми като Use Case, Activity, Sequence и Class диаграми.
Моделиране на бизнес процеси: BPMN (Business Process Model and Notation) за визуализация на процеси.
Анализ на изисквания: Техники като SWOT анализ, анализ на заинтересованите страни и мозъчна атака.
Софтуерни инструменти: Инструменти като JIRA, Confluence, Microsoft Visio и други, които подпомагат управлението на изискванията и комуникацията.
Ролята на бизнес анализатора – Възможни наименования:
• Бизнес аналитик (Business Analyst)
• Бизнес анализатор (Business Analyst)
• Системен аналитик (System Analyst)
• Функционален aналитик (Functional Analyst)
• Бизнес системен аналитик (Business System Analyst)
• Аналитик
Организациите наричат по различен начин ролята, но най-разпространеното наименование е Бизнес аналитик или Бизнес анализатор.Бизнес анализаторът играе критична роля в успеха на проектите чрез осигуряване на ясна комуникация между бизнес и техническите екипи, събиране и анализ на изискванията и разработване на ефективни решения. Техните умения и знания са незаменими за постигане на бизнес целите и подобряване на процесите в организацията.

2 Методологии и роли в разработката на софтуер. Rational Unified Process (RUP, Унифициран процес за разработка на софтуер).
Разработката на софтуер включва многофазен процес, който изисква различни методологии и роли за успешното реализиране на проекти. Методологиите представляват структурирани подходи за планиране, изпълнение и контрол на софтуерните проекти, докато ролите в проекта определят отговорностите и задачите на членовете на екипа.
2.1. Популярни методологии за разработка на софтуер
Agile (гъвкава методология)
Основни принципи: Гъвкавост и адаптивност към променящите се изисквания.
Сътрудничество между екипа и заинтересованите страни.
Бързи и честни доставки на работещ софтуер.
Непрекъснато подобрение и отворена комуникация.
Основни рамки: Scrum, Kanban, Extreme Programming (XP).
Waterfall (водопадна методология)
Основни принципи: Линейно и последователно изпълнение на фазите на проекта.
Всяка фаза трябва да бъде завършена преди да започне следващата.
Подходяща за проекти с ясно дефинирани изисквания.
Фази: Изисквания, дизайн, имплементация, тестване, внедряване, поддръжка.
DevOps
Основни принципи: Интеграция на разработката (Dev) и операциите (Ops).
Автоматизация на процесите от кодиране до внедряване.
Непрекъсната интеграция и доставка (CI/CD).
Сътрудничество между разработчиците и IT операциите.
2. 2. Rational Unified Process (RUP)
Rational Unified Process (RUP) е методология за разработка на софтуер, разработена от Rational Software, която се фокусира върху итеративен и инкрементален подход. RUP предоставя подробни насоки за целия жизнен цикъл на софтуерния проект.
2.1. Основни принципи на RUP
Итеративен и инкрементален подход: Проектът се развива чрез повтарящи се цикли на разработка, които добавят нови функции и подобрения.
Центрираност върху архитектурата: Изграждането на стабилна и гъвкава архитектура е основен приоритет.
Управление на риска: Рискът се управлява чрез ранно идентифициране и адресиране на потенциални проблеми.
Фокус върху качеството: Качеството на софтуера се осигурява чрез систематични процеси и проверки.
2.2. Жизнен цикъл на RUP
Inception (Инициация): Дефиниране на основните цели и обхват на проекта. Изготвяне на бизнес казус и първоначален план.
Elaboration (Разработване): Детайлно планиране и анализ на изискванията. Разработване на архитектурен прототип.
Construction (Конструиране): Разработка и интеграция на системата. Фокус върху внедряването на функционалности и тестване.
Transition (Преход): Внедряване на системата в реална среда. Финално тестване и подготовка за поддръжка.
2.3. Основни роли в RUP
Project Manager (Мениджър на проекта): Отговаря за планирането, изпълнението и контрола на проекта.
Business Analyst (Бизнес анализатор): Събира и анализира бизнес изискванията. Осигурява връзката между бизнеса и техническия екип. System Architect (Системен архитект): Дефинира архитектурата на системата и осигурява нейното съответствие с изискванията.
Developer (Разработчик): Разработва и интегрира софтуерните компоненти.
Tester (Тестер): Провежда тестове и осигурява качеството на софтуера.
Configuration Manager (Мениджър на конфигурацията): Управлява версиите и конфигурацията на софтуера.
2.4. Запознаване с методологии за разработка на софтуер – Waterfall и Agile, Rational Unified
Process (RUP).
Ако всеки проект има следните фази:
Initiation – Начало (решава се концепцията на проекта)
Analysis – Анализ (изясняване на изисквания)
Design – Дизайн (проектиране на системата)
Development – Разработка
Testing – Тестване
Implementation – Внедряване
Начинът, по който се изпълняват те, определя модела на процеса по разработка на софтуер. Изборът на правилната методология и ясно дефиниране на ролите в софтуерния проект са ключови за успешната му реализация. Методологиите като Agile, Waterfall, DevOps и RUP предлагат различни подходи и инструменти за справяне с предизвикателствата в разработката на софтуер. Бизнес анализаторите, системните архитекти, разработчиците и другите ключови роли трябва да работят съвместно,
за да постигнат високо качество и стойност за бизнеса.

3. Какво е Бизнес анализ? Въведение в бизнес анализа.
Какво е бизнес анализ?
Бизнес анализът е дисциплина, която включва идентифициране на бизнес нужди и определяне на решения за бизнес проблеми. Решенията често включват разработка на софтуерни системи, но могат също така да включват подобряване на процеси, организационни промени или стратегическо планиране и политика.
Основни цели на бизнес анализа
Идентифициране на бизнес проблеми и възможности: Анализаторът трябва да разбере текущото състояние на бизнеса и да идентифицира области за подобрение.
Разработване на решения: На база на анализа на текущите процеси и системи, анализаторът разработва решения за подобряване.
Осигуряване на стойност: Целта е да се осигури стойност за бизнеса чрез ефективни и ефективни
решения.
Процес на бизнес анализ

Събиране на изисквания: Основната задача на бизнес анализатора е да събере изискванията от заинтересованите страни.
Анализ и документиране: След събирането на изискванията, анализаторът ги анализира и документира.
Комуникация: Анализаторът трябва да комуникира изискванията с екипа за разработка и заинтересованите страни.
Валидация и верификация: Проверка на събраните изисквания и предложения, за да се осигури тяхната точност и реалистичност.
Поддръжка: Постоянна поддръжка и актуализация на изискванията по време на проекта.
Основни роли в бизнес анализа
Бизнес анализатор (Business Analyst): Основната роля в процеса на бизнес анализ. Отговаря за събирането, анализа и документирането на изискванията.
Ръководител на проекта (Project Manager): Осигурява планирането и изпълнението на проекта.
Стейкхолдъри (Stakeholders): Лица или групи, които имат интерес или са засегнати от проекта.
Инструменти и техники в бизнес анализа
Интервюта: Провеждане на разговори с ключови заинтересовани страни.
Анализ на документи: Преглед на съществуващи документи и системи.
Семинари и работни срещи: Сесии за съвместна работа с различни заинтересовани страни.
Диаграми и модели: Използване на различни видове диаграми за визуализация на процесите и
системите (например, диаграми на потока на данни, UML диаграми).
Прототипиране: Създаване на визуални или функционални модели на предложените решения.
Важността на бизнес анализа
Подобряване на ефективността: Чрез идентифициране и разрешаване на бизнес проблемите, бизнес анализаторите могат да подобрят ефективността на бизнес процесите.
Намаляване на рисковете: Анализът на изискванията и внимателното планиране помагат за намаляване на рисковете в проекта. Осигуряване на стойност: Бизнес анализаторите осигуряват, че решенията, които се разработват, отговарят на нуждите на бизнеса и добавят стойност. Бизнес анализът е критична дисциплина за успешната реализация на проекти и подобряване на
бизнес процесите. Чрез систематичен подход към събирането и анализа на изискванията, бизнес анализаторите могат да осигурят, че решенията, които се предлагат и реализират, отговарят на нуждите на бизнеса и водят до постигане на бизнес цели.

Business analysis planning and monitoring – задачи и техники по планиране и наблюдение.
Пример: изготвяне на график за писане на изисквания, план за комуникация.
Elicitation – задачи и техники по извличане на изисквания.
Пример: провеждане на интервюта с потребителите на бъдещата система.
Requirements management and communication – задачи и техники по управление на изискванията и
тяхната комуникация.
Пример: Преглед от колеги / Peer review.
Enterprise analysis – задачи и техники за анализ на ниво организация.
Пример: изготвяне на бизнес казус, SWOT (Strengths, Weaknesses,Opportunities, Threads) анализ.
Requirements Analysis – задачи и техники за анализ на изискванията.
Пример: детайлизиране и приоритизиране на изисквания.
Solution Assessment and Validation – задачи и техники по оценка на решението за реализация.

4 Въведение в изискванията. Какво е изискване?
Какво е изискване?
В контекста на бизнес анализа и разработката на софтуер, изискването е изявление относно нужда, функция или ограничение на системата, която трябва да бъде удовлетворена или спазена. Изискванията са основата, върху която се изгражда и развива даден проект. Те описват какво трябва да прави системата, как трябва да работи и какви ограничения трябва да спазва.
Видове изисквания
Изискванията обикновено се разделят на няколко категории, включително:
Функционални изисквания: Описват специфични функции или задачи, които системата трябва да изпълнява.
Примери: „Системата трябва да позволява на потребителите да регистрират профил „Системата трябва да генерира месечни отчети за продажбите“.
Нефункционални изисквания:
Описват качествените аспекти на системата, като производителност, сигурност, използваемост и поддръжка.
Примери: „Системата трябва да обработва до 10 000 транзакции на минута „Системата трябва да бъде достъпна 99.9%

Бизнес изисквания:
Описват високо ниво на цели и нужди на организацията.
Примери: „Увеличаване на онлайн продажбите с 20%
Потребителски изисквания:
Описват нуждите и очакванията на крайните потребители от системата.
Примери: „Потребителят трябва да може да търси продукти по категория „Потребителят трябва да получава известия по електронна поща за нови оферти“.
Системни изисквания:
Описват техническите нужди и ограничения на системата.
Примери: „Системата трябва да бъде съвместима с Windows и macOS „Системата трябва да поддържа база данни MySQL“.

Жизнен цикъл на изискванията
Изискванията преминават през различни етапи в процеса на разработка на софтуер
Събиране на изисквания:
Процесът на идентифициране на изискванията от заинтересованите страни чрез интервюта, анкети,
работни срещи и анализ на съществуващи документи.
Анализ на изискванията: Оценка и прецизиране на събраните изисквания за да се осигури тяхната точност, пълнота и съвместимост.
Документиране на изискванията: Създаване на формална документация, която описва изискванията в детайли.
Комуникация на изискванията:
Споделяне на документацията и обсъждане на изискванията със заинтересованите страни и екипа
за разработка.
Управление на изискванията: Проследяване на промените в изискванията и управление на техния жизнен цикъл.
Примерни техники за събиране на изисквания
Интервюта: Лични срещи със заинтересованите страни за събиране на информация.
Анкети и въпросници: Изпращане на въпроси към голям брой хора за събиране на данни.
Работни срещи и семинари: Съвместни сесии с ключови заинтересовани страни за идентифициране и обсъждане на изискванията.
Анализ на документи: Преглед на съществуващи документи, системи и процеси за идентифициране на изисквания.
Прототипиране: Създаване на ранни версии на системата за демонстрация и събиране на обратна връзка.
Значението на добре дефинирани изисквания
Добре дефинираните изисквания са критично важни за успеха на всеки проект. Те осигуряват ясна представа за това, което трябва да бъде постигнато и служат като основа за планиране, дизайн, разработка и тестване. Лошо дефинирани или непълни изисквания могат да доведат до пропуски, забавяния, увеличаване на разходите и дори провал на проекта.

5 Бизнес анализ документи
Въведение в бизнес анализ документите
Бизнес анализ документите играят ключова роля в процеса на бизнес анализ. Те служат за документиране на нуждите и изискванията на бизнеса, което помага на екипите за разработка да създадат решения, които удовлетворяват тези нужди. В този урок ще разгледаме различните видове документи, които се използват в бизнес анализа.
Видове бизнес анализ документи
Бизнес казус (Business Case): Описание на бизнес проблема или възможност, анализ на възможните решения и препоръка за
действие. Включва оценка на ползи, разходи, рискове и възвръщаемост на инвестицията (ROI).
Документ с изисквания (Requirements Document): Подробно описание на функционалните и нефункционалните изисквания за даден проект. Включва бизнес изисквания, потребителски изисквания и системни изисквания.
Визия и обхват (Vision and Scope Document): Описание на целите на проекта, обхвата на работа и ключовите заинтересовани страни. Включва бизнес цели, ограничения и предположения.
Документ за спецификация на софтуерните изисквания (Software Requirements Specification – SRS):
Техническа документация, която описва поведението на системата, включително функционални и нефункционални изисквания. Използва се от разработчиците и тестерите за създаване и тестване на системата.
Модели и диаграми: Визуални представяния на бизнес процесите, изискванията и архитектурата на системата.
Включва диаграми на случаи на употреба (Use Case Diagrams), диаграми на класовете (Class Diagrams), диаграми на дейностите (Activity Diagrams) и други UML диаграми.
Доклад за анализ на заинтересованите страни (Stakeholder Analysis Report):
Идентификация и анализ на всички заинтересовани страни, включително техните нужди, влияния и интереси. Включва матрица на заинтересованите страни и стратегии за управление на техните очаквания.
План за управление на изискванията (Requirements Management Plan):
Описание на процесите и инструментите за управление на изискванията през целия жизнен цикъл на проекта. Включва методологии за събиране, анализ, документиране и проследяване на изискванията.
Примерни формати за документиране
Бизнес казус
Въведение – Описание на проблема или възможността
Анализ на възможностите – Възможно решение 1 – Възможно решение 2 – Възможно решение 3
Препоръка – Препоръчано решение и обосновка
Анализ на ползи и разходи – Оценка на ползите – Оценка на разходите
Рискове – Идентификация на рисковете и планове за тяхното управление
Документ с изисквания
Въведение – Цел на документа – Обхват
Бизнес изисквания – Описание на бизнес нуждите
Потребителски изисквания – Изисквания от гледна точка на потребителите
Системни изисквания – Технически изисквания и ограничения
Функционални изисквания – Описание на основните функции на системата
Нефункционални изисквания – Описание на качествените аспекти на системата (производителност, сигурност и др.).

Значение на добре документираните изисквания
Добре документираните изисквания са критични за успеха на всеки проект. Те осигуряват ясна представа за нуждите и очакванията на бизнеса и служат като основа за планиране, дизайн, разработка и тестване. Лошо документирани изисквания могат да доведат до пропуски, забавяния, увеличаване на разходите и дори провал на проекта.
Контролни въпроси
Какво представлява бизнес казус и какви са неговите основни компоненти?
Какви са основните разлики между функционалните и нефункционалните изисквания?
Какво включва документът за спецификация на софтуерните изисквания (SRS)?
Какви са основните цели на анализа на заинтересованите страни?
Защо е важно да има план за управление на изискванията?

6 Процесът по писане на изисквания
Писането на изисквания е критична стъпка в жизнения цикъл на разработката на софтуер. Добре написаните изисквания осигуряват ясна и точна комуникация между всички заинтересовани страни и помагат за успешното изпълнение на проекта. Този процес може да бъде разделен на няколко основни етапа:
Идентификация на заинтересованите страни
Първата стъпка е да се идентифицират всички заинтересовани страни, които ще бъдат засегнати от проекта. Това включва клиенти, крайни потребители, проектни мениджъри, разработчици, тестери и други.
Цел: Да се разбере кой има интерес в проекта и какви са техните нужди и очаквания.
Методи: Интервюта, анкети, работни срещи, анализ на документи.
Събиране на изисквания
Събирането на изисквания включва получаването на информация от заинтересованите страни от носно техните нужди и очаквания за системата.
Цел: Да се събере пълна и точна информация за това какво трябва да прави системата.
Методи: Интервюта, работни срещи, фокус групи, наблюдение, прототипиране.
Анализ на изискванията
Анализът на изискванията включва преглед и оценка на събраната информация, за да се иденти фицират основните бизнес нужди и да се изяснят, изчистят и формализират изискванията.
Цел: Да се гарантира, че изискванията са ясни, последователни, непълни и изпълними.
Методи: Диаграми на случаи на употреба, диаграми на потока на данни, моделиране на бизнес процеси.
Документиране на изискванията
След като изискванията са събрани и анализирани, те трябва да бъдат документирани по ясен и организиран начин.
Цел: Да се създаде официален документ, който да служи като основа за разработка и тестване на системата.
Формати: Документ за спецификация на софтуерните изисквания (SRS), диаграми на случаи на употреба, таблици и графики.
Потвърждаване на изискванията
Потвърждаването включва преглед на изискванията с всички заинтересовани страни, за да се уверите, че те са правилно разбрани и съгласувани.
Цел: Да се гарантира, че изискванията отразяват действителните нужди на бизнеса и потребителите.
Методи: Прегледи, одобрения, тестове за съгласуваност и коректност.
Управление на изискванията
Управлението на изискванията включва следене и управление на промените в изискванията през целия жизнен цикъл на проекта.
Цел: Да се поддържа контрол върху промените в изискванията и да се гарантира, че всички промени са правилно документирани и комуникирани.
Методи: Използване на системи за управление на изискванията, регулярни прегледи и актуализации.
Примерен документ за спецификация на софтуерните изисквания (SRS)

Документ за спецификация на софтуерните изисквания (SRS)
1. Въведение

1.1 Цел – Описание на целта на документа и системата.

1.2 Обхват – Описание на обхвата на системата и ограниченията.
2. Обща информация

2.1 Бизнес цели – Описание на бизнес целите, които системата трябва да постигне.

2.2 Заинтересовани страни – Списък на всички заинтересовани страни и техните роли.

Функционални изисквания

Основни функции – Описание на основните функции на системата.
Подфункции – Подробно описание на всяка функция и нейните подфункции.

Нефункционални изисквания

Производителност – Изисквания за производителността на
системата.

Сигурност – Изисквания за сигурността на системата.

Надеждност – Изисквания за надеждността и наличността на системата.

Ограничения – Описание на ограниченията, които трябва да бъдат взети предвид при разработката на системата.
Приложения – Допълнителна информация, диаграми, таблици и други документи.

Контролни въпроси
Какви са основните етапи в процеса на писане на изисквания?
Какви методи могат да се използват за събиране на изисквания?
Защо е важно изискванията да бъдат потвърдени с всички заинтересовани страни?
Какво включва процесът на управление на изискванията?
Какво е предназначението на документа за спецификация на софтуерните изисквания (SRS)?

7 Дефиниране на бизнес проблем
Дефинирането на бизнес проблема е първата и най-важна стъпка в процеса на бизнес анализ. Тази стъпка включва идентифициране и разбиране на съществуващите предизвикателства или възможности, които изискват решения. Ясното дефиниране на бизнес проблема е критично, защото това поставя основата за цялостния анализ и разработване на ефективни решения.
Етапи в дефинирането на бизнес проблема
1. Идентификация на проблема
Първата стъпка е да се идентифицира съществуващият проблем или възможност. Това може да включва събиране на информация от различни източници като служители, клиенти, партньори, финансови отчети и други.
Методи: ,Интервюта, Анкети, Наблюдение, Анализ на документи.
2. Формулиране на проблема
След идентификацията, проблемът трябва да бъде формулиран по ясен и разбираем начин. Това включва описание на текущата ситуация и конкретните предизвикателства или възможности, които трябва да бъдат разгледани.
Компоненти: ,Описание на текущото състояние, Описание на желания резултат, Описание на разликата между текущото и желаното състояние
3. Анализ на проблема
Анализът на проблема включва разглеждане на причините и последствията от съществуващия проблем. Това може да включва събиране и анализ на данни, провеждане на причинно-следствени анализи и използване на различни аналитични инструменти.
Методи: SWOT анализ (Силни страни, Слаби страни, Възможности, Заплахи) Анализ на причинно следствени връзки (Root Cause Analysis) PEST анализ (Политически, Икономически, Социални, Технологични фактори).
4. Определяне на заинтересованите страни
Важно е да се идентифицират всички заинтересовани страни, които са засегнати от проблема и
които ще бъдат засегнати от предложеното решение. Това включва вътрешни и външни заинтересовани
страни.
Примери: Служители, Клиенти, Доставчици, Регулатори.
5. Определяне на цели и критерии за успех
След като проблемът е дефиниран и анализиран, следва да се определят целите и критериите за успех. Това включва идентифициране на конкретни, измерими и постижими цели, които решението трябва да постигне.
Примери за цели: Увеличаване на продажбите с 10%, Намаляване на оперативните разходи с 15%, Подобряване на удовлетвореността на клиентите с 20%.
Примери за критерии за успех: Конкретни метрики и показатели за оценка на резултатите, Времеви рамки за постигане на целите
Определяне на отговорности и роли.
6. Документиране на проблема- Накрая, всички събрани данни, анализи и заключения трябва да бъдат документирани по ясен и организиран начин. Това може да включва създаване на доклад, презентация или друг вид документация, която ще бъде използвана като основа за по-нататъшния анализ и разработване на решения.

Примерен шаблон за дефиниране на бизнес проблема
Доклад за дефиниране на бизнес проблема
1. Въведение 1.1 Цел – Описание на целта на доклада и неговата важност.
2. Идентификация на проблема  2.1 Описание на текущото състояние – Подробно описание на текущата ситуация и съществуващите предизвикателства. 2.2 Описание на желания резултат – Описание на желаното състояние или резултат, който трябва да бъде постигнат. 2.3 Разлика между текущото и желаното състояние – Описание на основната разлика и защо е важно тя да бъде адресирана.
3. Анализ на проблема 3.1 Причинно-следствени анализи – Анализ на основните причини и последствия от съществуващия проблем. 3.2 SWOT анализ – Описание на силните и слабите страни, възможностите и заплахите.
4. Заинтересовани страни 4.1 Идентификация на заинтересованите страни – Списък и описание на всички заинтересовани страни.
5. Цели и критерии за успех 5.1 Определяне на цели – Описание на конкретните цели, които трябва да бъдат постигнати.
5.2 Определяне на критерии за успех – Описание на критериите за успех и как те ще бъдат измервани.
6. Заключение – Обобщение на основните точки и следващи стъпки.

Контролни въпроси
Какви са основните етапи в дефинирането на бизнес проблема?
Какви методи могат да се използват за идентификация на проблема?
Какво включва анализът на бизнес проблема?
Защо е важно да се определят заинтересованите страни при дефинирането на бизнес проблема?
Какво включва определянето на цели и критерии за успех?

8. Дефиниране на обхвата
Дефинирането на обхвата на проекта е критично за успешното му изпълнение, тъй като ясно определя какво ще бъде включено и какво ще бъде изключено от проекта. Това включва описание на целите, резултатите, задачите и границите на проекта. Ясното дефиниране на обхвата помага за предотвратяване на промени в проекта (scope creep) и осигурява общо разбиране сред всички заинтересовани страни.
Основни компоненти на дефинирането на обхвата
1. Цели на проекта
Определянето на конкретните цели на проекта е първата стъпка в дефинирането на обхвата. Това включва ясно и точно формулиране на това, което проектът трябва да постигне.
Примерни цели: Разработване на нов продукт до края на годината. Подобряване на качеството на услугата с 20%.
2. Резултати от проекта
Резултатите са конкретни продукти, услуги или резултати, които проектът трябва да достави. Те трябва да бъдат измерими и специфични.
Примерни резултати: Доставка на нов софтуерен продукт.
Разработване на нова маркетингова стратегия.
3. Граници на проекта
Определянето на границите включва описание на това, което ще бъде включено и изключено от проекта. Това помага да се уточнят ограниченията и да се предотвратят неясноти.
Примери: Включено – Разработка на функционалности за основния продукт. Изключено – Обучение на потребителите.
4. Основни задачи и етапи
Определянето на основните задачи и етапи включва разбиване на проекта на по-малки, управляеми части. Това улеснява планирането и изпълнението на проекта.
Примерни задачи:
Провеждане на пазарно проучване.
Разработка на прототип.
5. Ограничения и предположения
Ограниченията и предположенията са фактори, които могат да влияят на изпълнението на проекта. Ограниченията са фактори, които ограничават възможностите на проекта, докато предположенията са условия, които се приемат за истински за целите на планирането.
Примерни ограничения:, Бюджет от 100,000 лева., Времеви рамки от 6 месеца.
Примерни предположения: Достъпност на необходимите ресурси., Подкрепа от висшето ръководство.
6. Критерии за успех
Определянето на критериите за успех включва описание на как ще бъде измерено успешното изпълнение на проекта. Това може да включва специфични показатели и метрики.
Примери: Завършване на проекта в рамките на бюджета. Постигане на определени нива на клиентска удовлетвореност.
Примерен шаблон за дефиниране на обхвата на проекта
Доклад за дефиниране на обхвата на проекта
1. Въведение: Цел – Описание на целта на проекта и неговата важност.
2. Цели на проекта – Конкретни цели, които проектът трябва да постигне.
3. Резултати от проекта – Описание на конкретните продукти, услуги или резултати, които проектът трябва да достави.
4. Граници на проекта: Включено в обхвата – Подробно описание на това, което ще бъде включено в проекта.
Изключено от обхвата – Подробно описание на това, което няма да бъде включено в проекта.
5. Основни задачи и етапи – Разбивка на проекта на по-малки, управляеми части и описание на основните задачи и етапи.
6. Ограничения и предположения: 6.1 Ограничения – Фактори, които ограничават възможностите на проекта. 6.2 Предположения – Условия, които се приемат за истински за целите на планирането.
7. Критерии за успех – Описание на показателите и метриките, които ще бъдат използвани за измерване на успешното изпълнение на проекта.
8. Заключение – Обобщение на основните точки и следващи стъпки.

Контролни въпроси
Какви са основните компоненти на дефинирането на обхвата на проекта?
Каква е разликата между цели и резултати от проекта?
Защо е важно да се определят границите на проекта?
Какви са ограниченията и предположенията и каква е тяхната роля в планирането на проекта?
Какви критерии за успех могат да бъдат използвани за оценка на проекта?

9. Визуализиране на обхвата
Визуализирането на обхвата на проекта е критично за ясно и ефективно комуникиране на основните елементи на проекта. Визуалните инструменти като диаграми и графики помагат на всички заинтересовани страни да разберат какво ще бъде включено и изключено от проекта. Някои от най-често използваните визуални инструменти за представяне на обхвата включват Work Breakdown Structure (WBS), Gantt диаграми и диаграми на процесите.
Основни визуални инструменти
1. Work Breakdown Structure (WBS)
WBS е визуално представяне на всички задачи и елементи, необходими за завършването на проекта. Той разбива проекта на управляеми части, които могат лесно да бъдат планирани и контролирани.

2. Gantt диаграма
Gantt диаграмата е график, който визуализира времевия обхват на задачите в проекта. Тя показва кога започват и завършват отделните задачи и как те се припокриват.
3. Диаграма на процесите
Диаграмите на процесите визуализират последователността на стъпките в процеса на изпълнение на проекта. Те са полезни за идентифициране на зависимостите между задачите и оптимизиране на работния поток.
Указания за визуализиране на обхвата
Избор на подходящ инструмент: Изберете визуалния инструмент, който най-добре отговаря на нуждите на вашия проект и заинтересованите страни.
Събиране на информация: Съберете необходимата информация за проекта, включително цели, задачи, етапи и ограничения.
Създаване на визуализация: Използвайте събраната информация, за да създадете визуализацията. Уверете се, че е ясно и лесно
за разбиране.
Преглед и одобрение: Прегледайте визуализацията със заинтересованите страни и направете необходимите корекции.
Актуализация: Редовно актуализирайте визуализацията, за да отразявате промените в проекта.

Контролни задачи
Създайте WBS за малък проект по ваш избор и го представете визуално. Разработете Gantt диаграма за проект с минимум 5 задачи и покажете времевите зависимости между тях.
Създайте диаграма на процесите за даден бизнес процес и идентифицирайте ключовите зависимости и решения.
Ролеви игри за групи от 2-3 студенти
Сценарий:
Екип от студенти трябва да планира и организира университетско събитие (например, научна конференция). Те трябва да дефинират обхвата на проекта, да създадат WBS, Gantt диаграма и диаграма на процесите.
Роли: Проектен мениджър: Отговаря за цялостната координация на проекта. Специалист по планиране: Отговаря за създаването на визуалните инструменти.
Комуникационен мениджър: Отговаря за комуникацията със заинтересованите страни и събирането на информация.
Задачи: Дефинирайте обхвата на проекта, включително цели, резултати и граници. Създайте WBS, Gantt диаграма и диаграма на процесите.
Представете визуализациите на групата и обсъдете техните предимства и недостатъци.

10. Потребителски изисквания и изисквания на заинтересованите страни
Потребителските изисквания (User Requirements) и изискванията на заинтересованите страни (Stakeholder Requirements) са ключови елементи в процеса на бизнес анализ. Те се използват за да се определи какво точно трябва да бъде разработено или подобрено в рамките на проекта или системата. В следващите секции ще обясним как да дефинирате и разберете тези изисквания.
Потребителски изисквания
Потребителските изисквания се фокусират върху нуждите и очакванията на крайните потребители на системата или продукта. Тези изисквания описват функционалността и характеристиките, които потребителите очакват да бъдат включени. Включват също така и различни сценарии за използване на системата.
Примери за потребителски изисквания включват:
Възможност за регистрация и вход в системата с потребителско име и парола.
Възможност за търсене и филтриране на продукти по различни критерии.
Възможност за добавяне на продукти към количка за пазаруване и завършване на поръчка.
Изисквания на заинтересованите страни
Изискванията на заинтересованите страни са широк спектър от изисквания, които идват от различни групи, които са заинтересовани от успешното изпълнение на проекта или системата. Те могат да включват бизнес потребности, правни задължения, технически ограничения и др.
Примери за изисквания на заинтересованите страни включват:
Финансови ограничения за разработката на системата.
Съответствие с регулаторни стандарти и нормативни изисквания.
Възможност за интеграция със съществуващи системи и платформи.
Процес на събиране на изисквания
Идентификация на заинтересованите страни: Определете ключовите заинтересовани страни и потребители, които ще бъдат засегнати от проекта или системата.
Събиране на информация: Проведете интервюта, работни срещи и анкети с потребителите и заинтересованите страни, за да разберете техните нужди и изисквания.
Документиране на изискванията: Запишете и организирайте потребителските и заинтересованите страни изисквания. Използвайте ясен и структуриран формат за тяхното представяне.
Преглед и одобрение: Покажете събраните изисквания на заинтересованите страни за преглед и
одобрение. Извършете корекции и добавете необходимите детайли според обратната връзка.

Упражнения
Създайте списък с потребителски изисквания за система за онлайн магазин, като включите функционалности за потребителите.
Идентифицирайте изисквания на заинтересованите страни за система за онлайн банкиране, включващи финансови и регулаторни аспекти. Документирайте процеса по събиране на изисквания за проект за разработка на мобилно приложение за доставка на храна.

11. Техники за извличане на потребителски изисквания
Извличането на потребителски изисквания е критичен етап в процеса на бизнес анализ, който цели да установи нуждите, целите и очакванията на потребителите от системата или продукта. За да се осигури успешно извличане на изискванията, могат да бъдат използвани различни техники и методики.Ето кои са някои от тях:
Интервюта с потребителите
Описание: Интервютата са структуриран процес, при който бизнес анализаторът разговаря директно със заинтересованите страни и потребителите, за да разбере техните нужди, очаквания и предложения.
Приложение: Интервютата са полезни за получаване на дълбоко разбиране за бизнес процесите и операциите, които трябва да бъдат поддържани от системата.
Фокус групи
Описание: Фокус групите са сесии, в които няколко потребители събират мнения и идеи по отношение на системата или продукта.
Приложение: Помагат за идентифициране на общи тенденции и предпочитания сред група от потребители.
Работни срещи и сесии за възможности за дискусия
Описание: Тези сесии включват широко участие на заинтересовани страни и предоставят платформа за открито обсъждане на идеи и предложения.
Приложение: Подобни срещи помагат за изграждане на консенсус и уточняване на различни гледни
точки за бизнес и техническите изисквания.
Анкети и въпросници
Описание: Използват се за събиране на големи обеми от данни и мнения от голяма група потребители.
Приложение: Подходящи за извличане на общи представи и мнения, особено когато е необходимо да се оцени обхватът на употребата на системата.
Brainstorming /Мозъчна атака/
Тази техника се използва обикновено за решаване на отворени въпроси
Стъпки:
Задава се тема
Генериране на идеи: всички идеи се записват без да се критикуват
Категоризиране на идеи: събраните идеи се категоризират и редуцират от екипа
Съвети:
Няма лоша идея, но може тя да е неподходящи за случая
Идеите се редуцират след като е минал етапа на генериране на идеи
Brainstorming-a обикновено протича в рамките на 90 минути, по-дълъг период не е продуктивен
Прототипиране и демонстрации
Описание: Създаване на прототипи и демонстрации на системата или продукта, които позволяват на потребителите да виждат и използват основни функционалности.
Приложение: Помагат за уточняване на изискванията, като потребителите могат да дадат обратна връзка и предложения за подобрения.
SWOT анализ (анализ на силните страници, слабостите, възможностите и заплахите)
Описание: Анализ, който оценява вътрешните и външните аспекти на проекта или продукта, включително изискванията на потребителите.
Приложение: Помага за идентифициране на потенциалните предизвикателства и възможности, свързани с изпълнението на изискванията.
7. Сценарии и случаи на употреба
Описание: Изготвяне на конкретни сценарии и случаи на употреба, които илюстрират как системата или продуктът трябва да се използва.
Приложение: Помагат за конкретизиране на изискванията и уточняване на предпочитанията на потребителите.

Упражнения
Интервю с потребители: Изпълнете интервю с потребители на мобилно приложение за социална мрежа и документирайте техните основни изисквания за усъвършенстване на приложението.
Фокус група: Организирайте фокус група с участие на студенти от университет, за да идентифицирате основните изисквания за система за управление на студентски проекти.
Създаване на прототип: Създайте прототип на онлайн платформа за резервации на ресторанти и демонстрирайте го на група от потенциални потребители за получаване на обратна връзка.

12. Представяне на потребителски изисквания
Представянето на потребителски изисквания е важна стъпка в процеса на бизнес анализ, която цели да обобщи и структурира нуждите и очакванията на потребителите от системата или продукта. Ефективното представяне на изискванията осигурява яснота и съгласуваност между всички заинтересовани страни и улеснява разработката на решения, които отговарят на бизнес целите. В следващите редове ще разгледаме ключовите аспекти на представянето на потребителски изисквания.
Ключови аспекти на представянето на потребителски изисквания:
Документация на изискванията:
Изискванията трябва да бъдат документирани ясно и подробно. Това включва описание на функционалността, нефункционалните изисквания, като производителност, сигурност и устойчивост, и всички други спецификации, които описват как трябва да функционира системата.
Използване на диаграми и модели:
Диаграмите и моделите, като например Use Case диаграми, диаграми на активностите, диаграми на последователностите и диаграми на класовете, са полезни инструменти за визуализиране на изискванията и уточняване на взаимодействията между различните компоненти на системата.
Прототипиране и демонстрации:
Създаването на прототипи и демонстрации на системата помага на потребителите да виждат как системата ще функционира в реалния свят. Това допринася за по-добро разбиране и уточняване на изискванията, като също така позволява на потребителите да дадат обратна връзка преди окончателната имплементация.
Обратна връзка и одобрение:
Важно е потребителите и заинтересованите страни да бъдат включени в процеса на представяне на изискванията. Получаването на обратна връзка и одобрение от тях е от критично значение за увереността в правилността и целесъобразността на изискванията.

Упражнения
Създаване на Use Case диаграма: Разработете Use Case диаграма за система за онлайн магазин, която да илюстрира основните сценарии на потребителското взаимодействие с приложението.
Прототипиране на интерфейс: Създадайте прототип на интерфейс за мобилно приложение за резервации в ресторант, който да демонстрира основните функционалности и потребителските възможности.
Сценарии на употреба: Изгответе сценарии на употреба за система за управление на задачи, които да илюстрират как различни типове потребители (администратори, потребители), използват системата.

13.  Функционални изисквания
Функционалните изисквания са основна част от спецификацията на софтуерния проект и определят каква функционалност трябва да бъде предоставена от системата. Те обикновено се фокусират върху това, какви действия или услуги трябва да може да извършва системата, за да удовлетвори нуждите на потребителите и заинтересованите страни. В следващите редове ще разгледаме ключовите аспекти и примери за функционални изисквания.
Ключови аспекти на функционалните изисквания:
Описание на функционалността:
Функционалните изисквания описват конкретните функции и услуги, които системата трябва да предоставя. Например, ако говорим за онлайн магазин, функционалните изисквания могат да включват функции като регистрация на потребители, добавяне на продукти в кошницата, обработка на плащания и т.н.
Интерфейсни изисквания:
Тези изисквания описват начина, по който потребителите ще взаимодействат с системата. Те могат да включват дизайн на потребителски интерфейс, възможности за навигация, визуализация на данни и др.
Изисквания за данни:
Описват се какви данни системата трябва да обработва, както и как трябва да се управляват тези данни. Това включва формати на данни, структури на бази данни, изисквания за защита на данни и т.н.
Изисквания за производителност:
Тези изисквания определят очакваните нива на производителност на системата, като време за отговор, време за зареждане на страници, обем на трафика и др.
Изисквания за сигурност:
Описват се мерките за защита на данните и достъпа до системата. Включват се изисквания за удостоверяване и авторизация, управление на правата на потребителите, криптографска защита на данни и други.
Примери за функционални изисквания:
Регистрация на потребители:
Потребителите трябва да имат възможност да създават и управляват свои профили в системата. Включва събиране на информация като име, електронна поща, парола и др.
Търсене и филтриране на продукти:
Потребителите трябва да могат да търсят продукти по различни критерии като категория, цена, марка и др. Филтрирането и сортирането на резултатите трябва да бъде бързо и ефективно.
Плащания и поръчки:
Потребителите трябва да могат да добавят продукти в кошницата, да извършват плащания и да преглеждат статуса на своите поръчки. Системата трябва да поддържа различни методи на плащане и да осигурява сигурност при транзакциите.
Управление на съобщения и уведомления:
Системата трябва да има възможност за изпращане на съобщения и уведомления до потребителите, свързани със състоянието на тяхната поръчка, специални оферти и др.
Административен панел за управление:
Администраторите на системата трябва да имат достъп до специален административен панел, от където да управляват продуктите, потребителите, поръчките и други аспекти на системата.

14. Структуриране на изискванията и техните атрибути
Структурирането на изискванията и техните атрибути е критична част от процеса на софтуерна разработка, тъй като осигурява яснота, прецизност и лесно разбиране както за разработчиците, така и за всички участници в проекта. В следващите редове ще разгледаме как да структурираме изискванията и кои са техните основни атрибути.
Структуриране на изискванията:
Идентификация и описание:
Всеки изискване трябва да има уникален идентификатор и ясно описание. Идентификаторът може да бъде номер или символен код, който да улеснява проследяването и управлението на изискванията. Описанието трябва да бъде конкретно и ясно за разбиране от всички заинтересовани страни.
Източник и тип на изискването:
Важно е да се посочи от къде произлиза всяко изискване и какъв е неговият тип. Източниците могат да бъдат потребителски нужди, бизнес процеси, законодателни изисквания, технически стандарти и други. Типът на изискването може да бъде функционално, нефункционално, изисквания за интерфейс и т.н.
Приоритет и важност:
Всеки изискване трябва да има зададен приоритет, който показва колко критично е за успешното завършване на проекта. Приоритетите могат да бъдат висок, среден или нисък, или да бъдат определени чрез други категории, които са важни за конкретния проект.
Състояние и статус:
Изискванията могат да преминават през различни състояния в процеса на разработка, като се маркират като нови, одобрени, в разработка, тествани, приключени и др. Този атрибут помага да се следи напредъка на всяко изискване и да се управляват измененията в тях.
Зависимости и връзки:
Изискванията могат да имат зависимости помежду си или с други части на системата. Важно е да се посочат всички взаимосвързаности, които могат да повлияят на проектирането и разработката на системата.
Атрибути на изисквания:
Яснота:
Изискванията трябва да бъдат формулирани по такъв начин, че да бъдат разбират от всички заинтересовани страни без двусмислие или неясноти.
Измеримост:
Изискванията трябва да бъдат измерими, за да се определят критериите за тяхното удовлетворение и валидност.
Пълнота:
Всички аспекти на функционалността и характеристиките, които трябва да се реализират, трябва да бъдат покрити от изискванията.
Същественост:
Изискванията трябва да бъдат съсредоточени върху съществените и ключовите аспекти на системата или приложението.
Поддържаемост:
Изискванията трябва да бъдат поддържаеми, за да могат да се променят или допълват при нужда в рамките на жизнения цикъл на системата.
Изпълнимост:
Изискванията трябва да бъдат изпълними и технически изводими, така че разработчиците да могат да ги превърнат в действителен софтуер. Структурирането на изискванията и правилното им документиране играят ключова роля за успешната реализация на софтуерния проект, като осигуряват яснота, консистентност и удовлетворяване на нуждите на всички заинтересовани страни.

15.  Извличане на функционални изисквания от потребителски изисквания и use cases
Извличане на функционални изисквания от потребителски изисквания:
Идентифициране на функционалности:
За да извлечем функционалните изисквания, трябва да анализираме потребителските изисквания и да идентифицираме конкретните функции или операции, които системата трябва да поддържа. Това може да включва дейности като добавяне, редактиране, изтриване на данни, автоматизация на процеси и други.
Анализиране на сценариите на потребителите:
Проучването на use cases или сценариите на потребителите е ключово за разбиране на това какви конкретни действия трябва да може да извършва системата. Идентифицирането на основните стъпки и дейности, които потребителите извършват, помага за формулиране на функционални изисквания.
Формулиране на функционални изисквания:
След като сме идентифицирали необходимите функционалности и анализирали сценариите, можем да формулираме конкретни функционални изисквания. Тези изисквания трябва да бъдат ясно описани и да включват кратки описания, като също така могат да се подкрепят с диаграми, ако е необходимо.
Валидация на изискванията:
Един от последните стъпки е валидацията на изискванията със заинтересованите страни. Това включва проверка дали изискванията са изчерпателни и правилно разбрани от всички участници в проекта. Важно е да се уверим, че всички функции, които са включени в изискванията, са наистина необходими за успешното изпълнение на проекта.
Извличане на функционални изисквания от use cases:
Идентифициране на основни действия и актьори:
Първата стъпка е да се идентифицират основните действия или операции, които са част от конкретен use case. Актьорите, които участват в тези действия, също трябва да бъдат ясно идентифицирани.
Разбиране на потребителските цели:
Всеки use case представя конкретна цел или задача, която потребителят трябва да постигне чрез използването на системата. Разбирането на тези цели помага за формулиране на функционални изисквания, които да поддържат тези цели.
Дефиниране на предусловия и следусловия:
Важно е да се определят предусловията (условията, които трябва да бъдат изпълнени, за да се стартира use case) и следусловията (резултатите, които трябва да бъдат постигнати след успешното завършване на use case). Тези условия могат да допринесат за функционалните изисквания на системата.
Извличане на конкретни функционалности:
От всеки use case могат да бъдат извлечени конкретни функционалности или операции, които системата трябва да поддържа. Тези функционалности се формулират като функционални изисквания с подробно описание на това какво трябва да се извършва и какви са входните и изходните данни.
Създаване на диаграми и модели:
За да се подкрепят функционалните изисквания, може да се създадат UML диаграми като use case диаграми или други подходящи модели, които да илюстрират взаимодействията и зависимостите между различните функционалности на системата.
Извличането на функционални изисквания от потребителски изисквания и use cases е процес, който изисква внимание към детайлите, разбиране на нуждите на потребителите и систематичен подход към формулирането на изискванията. Той помага за увереност и яснота в разработката на софтуерни проекти.

16. Нефункционални изисквания
Нефункционалните изисквания в софтуерната инженерия са критерии, които не се отнасят директно до функционалностите на системата, а по-скоро описват как трябва да работи системата, вместо какво трябва да прави. Те играят ключова роля в определянето на качеството, производителността и устойчивостта на софтуерното приложение.
Производителност: Тези изисквания описват времето за отговор на системата, времето за обработка на заявления, скоростта на обновление на данни и други метрики, свързани с ефективността на системата.
Надеждност: Изискванията за надеждност се отнасят до способността на системата да работи без проблеми и да предоставя правилни резултати дори при наличие на грешки или натоварване.
Сигурност: Тези изисквания се отнасят до защитата на данните и системата от неоторизирани достъпи, злоупотреби и други видове заплахи за сигурността.
Устойчивост: Тези изисквания определят как системата трябва да се справя с внезапни промени в натоварването, обема на данните или околната среда, без да се нарушава функционалността й.
Управление на данни: Тези изисквания се отнасят до начина, по който системата трябва да управлява данни, включително съхранението, достъпа, интеграцията и защитата на данните.
Леснота на използване: Тези изисквания определят колко лесно е за потребителите да работят с системата, включително интерфейса на потребителския интерфейс, документацията и обучението.
Мащабируемост: Тези изисквания описват способността на системата да се разшири и да се адаптира към растящи нужди и брой на потребителите или обема на данните.
Съвместимост: Изискванията за съвместимост определят способността на системата да работи с други системи, технологии или стандарти, както и способността й за интеграция.
Локализация и международизация: Тези изисквания се отнасят до способността на системата да поддържа различни езици, култури и регионални настройки.
Поддръжка и управление: Изискванията за поддръжка определят необходимостта от лесно управление, мониторинг, актуализации и поддръжка на системата след пускането й в експлоатация.
Нефункционалните изисквания играят решаваща роля в дефинирането на общата архитектура и проектирането на софтуерни системи, като осигуряват високо качество, надеждност и удовлетворение на потребителите.

Пример за Нефункционални Изисквания с Оценка 

Разбиране на Нефункционалните Изисквания

Нефункционалните изисквания описват качества и ограничения на системата, които не са свързани с конкретна функционалност. Те включват аспекти като сигурност, производителност, използваемост и надеждност.

Роля на Сигурността като Нефункционално Изискване

Сигурността е едно от най-важните нефункционални изисквания, особено в системи, които обработват чувствителна информация или трябва да защитават данни от неоторизиран достъп. Оценката за сигурност включва анализ на риска, уязвимостите и мерките за защита, които трябва да бъдат внедрени.

Представяне на Сигурността в UML Диаграмите

• Use Case Диаграми: За да отразим сигурността, можем да добавим „Актьори“ като „Хакер“ или „Неоторизиран потребител“, които илюстрират потенциални заплахи за системата. Use case-ите могат да включват случаи като „Опит за неоторизиран достъп“, което показва как системата трябва да се справя с такива ситуации.
• Диаграми на Класове (Class Diagrams): Класовете могат да имат атрибути и методи, свързани със сигурността, като например encryptData(), validateUser(), или logAccessAttempt(). Връзките между класовете също могат да бъдат обозначени със спецификации за сигурност, като secureConnection.
• Диаграми на Дейности (Activity Diagrams): Тези диаграми могат да включват стъпки за проверка на автентичността или криптиране на данни. Например, добавяне на условие за „Проверка на правата за достъп“ преди дадено действие да бъде изпълнено.
• Диаграми на Последователности (Sequence Diagrams): Можем да включим съобщения, свързани със сигурността, като например authenticateUser(), authorizeAccess(), и logSecurityEvent(), за да демонстрираме как системата отговаря на различни сигурностни събития.

 Примерен Сценарий за Сигурност

Да предположим, че разработваме информационна система за университетски кампус, която съдържа чувствителни данни за студентите и преподавателите.

Нефункционални изисквания за сигурност:

• Конфиденциалност: Всички лични данни трябва да бъдат криптирани.
• Целостност: Данните не могат да бъдат променяни от неоторизирани лица.
• Достъпност: Системата трябва да бъде защитена срещу атаки от типа „отказ на услуга“.

UML диаграма за сигурност:

• Use Case: „Опит за неоторизиран достъп“ от страна на „Неоторизиран потребител“.
• Диаграма на Класовете: Клас „UserAthentication“ с методи „encryptPassword( )“ и „veryfyCredentials“.
• Диаграма на Дейностите: Включва стъпка „Проверка на правата на потребителя“ преди достъп до определена информация.
• Диаграма на Последователностите: Съдържа взаимодействие между класове  „UserInterface“, „UserAthentication“  и „Database“, като се показват проверките за сигурност.

Заключение

Нефункционалните изисквания за сигурност са критична част от софтуерното планиране и дизайн. Чрез интегрирането им в UML диаграмите, можем да визуализираме и оценим мерките за сигурност, които системата трябва да поддържа, за да бъде ефективна и безопасна за използване.

ЛИТЕРАТУРА ЗА ПОДГОТОВКА

1. Roger S. Pressman, Ph.D. Software Engineering, A PRACTITIONER ’ S APPROACH, SEVENTH EDITION
2. Hassan Gomaa, SOFTWARE MODELING AND DESIGN, UML, Use Cases, Patterns, and Software Architectures
3. https://docs.staruml.io/
4. https://staruml.io/

 

Сподели