Що собою представляють нефункціональні вимоги.

· вимога продуктів, наприклад, повинна бути доступна клавіатура,

· вимога процесів, наприклад, процес планувальника повинен виконуватись за стандартом XXXA/06,

· зовнішні вимоги, наприклад, система планування повинна використовувати маркетингове відділення баз даних описане в документі YYYB/95. Ніяких змін до бази даних не застосовано.

·

53.Причини формулювання нефункціональні вимоги?

· Системні функції: ієрархія функцій, що виконуються системою,

· Об’єм: скільки користувачів працюватимуть одночасно? скільки терміналів буде встановлено? скільки сенсорів буде керовано? скільки інформації буде збережено?

· Швидкість: час для виконання операції (або черги операцій), кількість операцій за одиницю часу, максимальний час виконання операції,

· Точність: вимірювання масштабування і продуктивності, точність результату, заміна кількісних показників якісними,

· обмеження: обмеження інтерфейсу, якості, блоку часу, устаткування, засобів програмування і т.п.,

· Інтерфейс зв'язку: мережа, протоколи, представлення мережі, рівень абстракції, протоколів і т.п.,

· Програмний інтерфейс: специфікація устаткування, фізичні обмеження, продуктивність (швидкість процесора, пам'ять), вимоги до офісу, вологість, температура, тиск

· Програмний інтерфейс: сумісність з іншим ПЗ, ОС, мова програмування, компілятори, редактори, система управління базами даних (СУБД),

· Взаємодія людини з системою: всі аспекти призначеного для користувача інтерфейсу, мова програмування, апаратне забезпечення (монітор, миша, клавіатура), формати (звіти, їх зміст), визначення повідомлень (мова, форма), допомога, повідомлення про помилки і т.п.,

· Адаптивність: специфікація відповіді системи на зміни - нові команди, нове вікно і т.п.,

· Безпека: конфіденційність, приватність, інтеграція, специфікація надійності і т.п.,

· Гнучкість невдач: наслідки помилок ПЗ, помилка живлення, частота збережень, зміна розкладу і т.п.,

· Стандарти: специфікація стандартів документів, форматів файлів, розміри шрифтів, стандарти процесів і продуктів і т.п.,

· Ресурси: бюджет, людський ресурс і обмеження матеріальних ресурсів,

Час: необхідний час для створення системи, тренування і установки

 

54.Критерії перевірки вимог?

Характеристика	Міра
Продуктивність	Кількість транзакцій за секунду Час відгуку
Розмір	Кількість записів у базі даних Потрібний розмір пам'яті
Зручність для користувача	Час, потрібний для навчання Розмір документації
Надійність	Вірогідність помилки транзакції Час між виконаннями Доступність (час, коли програма доступна для користувача) Час перезавантаження програми після помилки Вірогідність втрати даних після помилки
Переносимість	Розмір платформозалежного коду Кількість платформ Вартість перенесення

 

55.Структура документу з вимогами до системи?

План Тіло документу Стандарт: ANSI/IEEE std 830-1993 Рекомендований порядок специфікації вимог програмного забезпечення	Резюме (не більше 200 слів) Зміст Статус документу: автори, компанії, дати і т.д. Зміни, зроблені після останньої версії
1. Вступ 1.1 Ціль 1.2 Контекст 1.3 Визначення, скорочення, абревіатури 1.4 Посилання 1.5 Короткий огляд 2. Загальний опис 2.1 Зручність роботи з програмою 2.2 Загальні характеристики 2.3 Характеристики користувача 2.4 Умови роботи 2.5 Припущення та взаємозв'язки 3. Вимоги 3.1 Функціональні вимоги 3.2 Нефункціональні вимоги Доповнення

 

Чинники успіху при формуванні документу з вимогами?

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

Приклад такого документа:

План Тіло документу Стандарт: ANSI/IEEE std 830-1993 Рекомендований порядок специфікації вимог програмного забезпечення	Резюме (не більше 200 слів) Зміст Статус документу: автори, компанії, дати і т.д. Зміни, зроблені після останньої версії
1. Вступ 1.1 Ціль 1.2 Контекст 1.3 Визначення, скорочення, абревіатури 1.4 Посилання 1.5 Короткий огляд 2. Загальний опис 2.1 Зручність роботи з програмою 2.2 Загальні характеристики 2.3 Характеристики користувача 2.4 Умови роботи 2.5 Припущення та взаємозв'язки 3. Вимоги 3.1 Функціональні вимоги 3.2 Нефункціональні вимоги Доповнення

Послідовність дій, застосованих до документа, повинна бути наступною:.

Якщо немає інформації, записати "не додається".

Повинна бути описана причина виконання кожної з вимог. Призначення проекту може залежати від вимог, нестача цієї специфікації може спричинити невдачу виконання.

Будь-який матеріал, що не ввійшов до секції, повинен бути доданий в "Додаток".

Часто до документа додаються:

· Вимоги апаратного і програмного забезпечення,

· Модель системи (архітектура),

· Словник (термінологія, акроніми, абревіатури),

· Зміст.

Якість документа з вимогами

Найбільш важливі чинники для якісних вимог:

Стиль

· Ясність: однозначне формулювання, ясне для користувача і розробника,

· Структура документа,

· Відповідність: ніяких протиріч у формуванні вимог,

· Змінність: формулювання по ключових моментах.

Гнучкість

· Можливість додавання нових вимог.

Специфікація ролей

· Можливість пов'язати особу з вимогою, описувати дію вимоги.

Помірність

· Паперовий або електронний варіант,

· Контроль версії документа.

Словник

Не може бути незрозумілих термінів для якої-небудь із сторін.

Всі специфічні треміни повинні бути додані в словник.

Всі невизначеності повинно бути уточнено. Приклад:

Термін	Визначення	Синоніми
Банківський рахунок	Послідовність номерів, записаних через дефіс, що визначають ресурси та операції клієнта	рахунок

 

 

Чинники успіху етапу формулювання вимог?

Ключові чинники успіху етапу формулювання вимог:

· Надання клієнту зразків для усунення неясності,

· повна ідентифікація вимог, виявлення специфічних і виняткових вимог,

· завершеність і перевірка змісту,

· формулювання нефункціональних вимог в певній формі.

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

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

Що собою являє модель системи?

Модель - це представлення концепції якоїсь реальності. Розум людини завжди займався розробкою моделей, будь то математичні моделі, фізичні, моделі машин, будинків. Полегшує планування і моніторинг рекомендується спочатку створити модель перед розробкою систем, для якої формулювання є дуже просте, а потім її модифікувати.Що протягом розробки є дороге або зовсім неможливе (наприклад, для космічних програм). Типовим прикладом систем, які можуть прототипуватися, - інформаційні системи, які обробляють дані роботи організації за нескладними алгоритмами, тобто здійснюють зберіганням даних, їх пошук на виконання простих операцій. Такі системи виконують функції, які раніше виконувалися без комп'ютера.

 

Що є метою побудови моделі?

Відповідь не проста, оскільки існує безліч цілей, для яких створюються моделі навколишнього світу. Одна з них - поліпшити розуміння системи перед тим, як її побудувати. Модель дозволяє експериментувати: вносити зміни, додавати і видаляти частини і елементи. Вносити зміни до моделі набагато простіше, ніж в систему. Наслідки неправильних рішень зменшуються і їх простіше виявити перед тим, як вони завдадуть шкоди самій системі.

Розробники інформаційних систем використовують моделі.

Зазвичай створюють наступні моделі:

· модель вимог - описується, наприклад, випадками використання,

· аналітична модель - статика і динаміка системи описуються мовою UML; деталями реалізації нехтують,

· модель дизайну - описується мовою UML більш деталізовано. Наприклад, присутні фізичні діаграми.

Головна мета проектування такої моделі - надати повний, послідовний і зрозумілий опис системи з точки зору функцій, але не деталей реалізації. Модель використовується для кращого розуміння системи, виправлення помилок, додавання елементів,яких не вистачає і є основою моделі дизайну.

Які існують моделі?

Розробники інформаційних систем використовують моделі.

Зазвичай створюють наступні моделі:

· модель вимог - описується, наприклад, випадками використання,

· аналітична модель - статика і динаміка системи описуються мовою UML; деталями реалізації нехтують,

· модель дизайну - описується мовою UML більш деталізовано. Наприклад, присутні фізичні діаграми.

Головна мета проектування такої моделі - надати повний, послідовний і зрозумілий опис системи з точки зору функцій, але не деталей реалізації. Модель використовується для кращого розуміння системи, виправлення помилок, додавання елементів,яких не вистачає і є основою моделі дизайну.

Логічна модель:

· показує, що повинна робити система,

· показує ієрархію системи,

· уникає термінології реалізації,

· дозволяє ухвалювати рішення "від причини до наслідків" і назад.

Моделі об'єктів

· Об'єктно-орієнтована методологія використовує базовий компонент на етапах аналізу і дизайну, тобто діаграму відносин класів - це розширення діаграми відносин "сутність-зв'язок". У діаграмах класів описуються класи, їх атрибути, методи, узагальнення, асоціації, агрегації, кількісні характеристики відносин і обмеження. Як допоміжні діаграми модель показує діаграми взаємодії, функціональні діаграми і т.д. Випадки використання описують структуру системи з точки зору користувача.