Лекція №6. Аналіз. Аналіз вимог

Аналіз – це процес розкладання складної системи на більш дрібніші частини для кращого її розуміння. Аналіз вимог (requirements process) – це процес трансформації інформації, отриманої від користувачів та інших зацікавлених сторін, у чітко та однозначно визначені вимоги, що передаються розробникам для реалізації у програмному коді. Мета аналізу вимог – розкладання (розчленування) виявлених вимог поки вони не будуть конкретними, повними і зрозумілими для всіх зацікавлених сторін. Аналіз вимог включає:

1) Виявлення та вирішення конфліктів між вимогами

2) Визначення границь задач, що вирішуються створюваним програмним забезпеченням

3) Деталізація системних вимог для установки програмних вимог

Результатом аналізу вимог є набір артефактів, що представляється у вигляді текстових документів, моделей та прототипів програмного забезпечення.

Цілі процесу аналізу вимог:

1. Досягнення однакового розуміння замовниками та користувачами того, що повинна робити система

2. Дати розробникам найкраще розуміння вимог до системи

3. Визначити границі системи

4. Визначити інтерфейс користувача та системи

Аналіз вимог слугує мостом між неформальним описом вимог, що виконуються замовником, і проектуванням системи.

Структурний аналіз – один із формалізованих методів аналізу вимог до ПЗ. Його засоби:

1) Діаграми потоку даних (DFD) – це графічний засіб для зображення інформаційного потоку і перетворень, які зазнають дані при русі від входу до виходу системи. Діаграми можуть використовуватися для представлення на будь-якому рівні абстракції. DFD є основним засобом моделювання функціональних вимог. Для їх зображення використовуються дві нотації (див. у своїх писаних пером або нашкрябаних яким-небудь кутнім зубом на шкірі якоїсь бідної тваринки конспектах).

На діаграмі функціональні вимоги представляються за допомогою процесів, сховищ, пов’язаних потоками даних. Процес фактично перетворює дані, позначається у вигляді еліпса або круга, усередині якого зазначаються його назва і номер. Кожен процес має фіксоване число вхідних та вихідних даних. Процеси реалізуються у вигляді методів і відповідають операціям конкретних класів.

Потоки даних з’єднують вихід якогось об’єкту та процесу із входом іншого та представляють проміжкові дані обчислень.

Зовнішні сутності являються джерелом або приймачем системних даних. Об’єкти, представлені такими вузлами, не повинні приймати участь у ніякій обробці.

Сховище даних – це пасивний об’єкт у складі діаграми потоку даних, у якому дані зберігаються для послідуючого доступу.

Контекстна діаграма моделює систему найбільш загальним чином; вона відображає інтерфейс системи із зовнішнім світом, тобто інформаційні потоки між системою і зовнішніми сутностями, з якими вона повинна бути зв’язана. Крім того, контекстна діаграма встановлює границі системи, що аналізується. Кожний проект повинен мати тільки одну контекстну діаграму, на якій, до речі, процес не нумерується.

ПРИИИИИИИИИИИИИИИИКЛАААААААААААААААД!!!! Відкрийте свої зошити і почиткайте, удачі.

2) Діаграми сутність-зв’язок (ERD)

3) Діаграми переходів станів (STD)

Усі ці засоби містять графічні та текстові засоби моделювання: перші використовуються для зручності демонстрації основних компонент моделі, а другі – для забезпечення точного визначення її компонент і зв’язків.

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Лекція №5. Методи збору та виявлення вимог	\|	Лекція №7. SADT та IDEF

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.026 сек.