Основні питання Класифікація вимог до програмного забезпечення та програмних систем



Дата конвертації24.12.2016
Розмір445 b.



Основні питання

  • Класифікація вимог до програмного забезпечення та програмних систем.

  • Специфікація вимог

  • Що означає процес формулювання вимог?



Класифікація вимог до програмного забезпечення та програмних систем.

  • Класифікація вимог до програмного забезпечення та програмних систем.

  • Специфікація вимог

  • Що означає процес формулювання вимог?



Класифікація вимог.

  • Функціональні- перелік функцій, які система повинна чи не повинна виконувати, її поведінка в певних умовах.

    • Автоматизація функцій персоналу;
    • Керування пристроями;
    • Узагальнення та надання певної інформації для прийняття рішень.
  • Не функціональні характеристики системи та її оточення, обмеження на функції, але не поведінка,

  • Функціональні та не функціональні вимоги предметної області – характеристики предметної області експлуатації системи.



Приклад функціональних вимог для підсистеми “бронювання місць у готелі”

  • Користувач повинен мати можливість пошуку місць згідно критеріїв: ціна, тип номера, кількість осіб, зручності, додаткові послуги, розміщення, термін.

  • Система повинна надавати користувачу необхідний засіб для перегляду місць.

  • Кожне бронювання повинно мати ідентифікатор, який записується у формуляр.

  • Система повинна забезпечувати оплату броні усіма доступними платіжними системами та готівкою.

  • Система повинна анулювати бронь у випадку несплати за тиждень до вказаного терміну.



Не функціональні вимоги

  • Основні проблеми: важко перевірити їх виконання; нечіткість формулювання

  • Відображають цілі замовника: простота в експлуатації; можливість відновлення після збоїв; швидка відповідь на запити.

    • Вимоги до продукту
      • Продуктивність системи, об'єм пам'яті, надійність, можливість перенесення на різні платформи.
    • Організаційні вимоги
      • Стандарти розробки програмного продукту, вимоги до реалізації, мови програмування терміни виготовлення та вимоги до супроводжуючої документації.
    • Зовнішні вимоги
      • Вимоги до взаємодії даної системи з іншими системами, юридичні вимоги (система буде розроблятися та функціонувати в межах існуючого законодавства), етичні вимоги.


Приклад не функціональних вимог для підсистеми “бронювання місць у готелі”

    • Вимоги до продукту
      • Усі взаємодії між інтерфейсом середовища програмування та користувачем здійснюються на основі стандартної множини символів мови С++.
    • Організаційні вимоги
      • Розробка системи та супровідної документації здійснюється на основі стандарту ДСТУ-95
    • Зовнішні вимоги
      • Системні оператори не повинні мати доступу до інформації про паспортні дані, платіжні можливості осіб, що забронювали номер.


Кількісні показники для не функціональних вимог.

  • Швидкодія

    • К-ть транзакцій за секунду;
    • Час реакції на дії користувача, обновлення екрану;
  • Об'єм пам'яті

  • Складність експлуатації

    • Час навчання персоналу
    • Обсяг довідкової системи
  • Надійність

    • Проміжок часу між послідовністю помилок
    • Ймовірність виходу з ладу
  • Стійкість до збоїв

    • Час відновлення після збою;
    • Відсоток подій, що призводять до збоїв;
    • Ймовірність спотворення чи втрати даних при збоях;
  • Можливість перенесення в інші середовища

    • Відсоток машинно-залежних операторів;
    • К-ть машинно-залежних підсистем;.


Функціональні та не функціональні вимоги предметної області

  • Проблеми опису- використовується мова та позначення даної предметної області.

      • ускладнення розуміння розробниками ПЗ
  • Нові функціональні вимоги;

    • Приклад: Данні про особу, яка бронювала місця повинні вилучатися після виконання замовлення та друку платіжних документів.
  • Нові чи додаткові обмеження на виконання функцій;

    • Приклад: Користувацький інтерфейс базується на інтерфейсі 1С Бухгалтерія.
  • Вказівки на порядок проведення обчислень

    • Приклад: Нарахування оплати проводиться за формулою…


Класифікація вимог за рівнями

  • Вимоги користувачів - описи на звичайній мові функцій та обмежень

      • Менеджери, користувачі, спеціалісти від замовника, розробники архітектури системи.
  • Системні вимоги- детальний опис функцій та обмежень- системна специфікація.

    • Основа для укладання угоди між замовником та розробником ПЗ.
      • Користувачі, спеціалісти від замовника, розробники архітектури системи, розробники системи
  • Системна специфікація проекту – узагальнений опис структури ПС – основа для детального проектування та реалізації, деталізує та доповнює специфікацію системних вимог.

      • спеціалісти від замовника, розробники архітектури системи, розробники системи


Вимоги користувачів

  • Особливості: функціональні та не функціональні; описують зовні поведінку системи.

  • Проблеми:

    • Відсутність чіткості та багатозначність опису;
    • Вимоги змішані;
    • Об'єднані різноманітні вимоги.
  • Рекомендації при складанні вимог

    • Використання стандартної форми для формулювання із додатковим обґрунтуванням;
    • У формулюванні необхідно виділяти обов'язкові вимоги та описові, наприклад послідовність дій користувача;
    • Ключові частини вимоги необхідно виділяти в документі;
    • Використання технічних термінів предметної області, а не комп'ютерного сленгу.


Приклади опису вимог користувачів

  • Приклад для опису вимог ПС для екологічного моніторингу

    • 3.1. Вимоги до підсистеми виведення полів концентрацій шкідливих викидів.
    • Для визначення значення концентрації шкідливих викидів у точці, користувач повинен мати можливість виводити сітку, параметри, якої задаються: крок вертикальних ліній - в метрах чи кілометрах; горизонтальних – в мг/м.куб чи мікр.г./м.куб шляхом вибору опції на панелі управління. По замовчуванню сітка не відображається. Крок сітки настроюється автоматично під розмір ділянки та рівня концентрацій.
  • У прикладі змішано різні вимоги, зокрема:

    • Важлива функціональна вимога: “Система повинна надавати можливість виведення сітки”
    • Не функціональна вимога (обмеження на функцію): “Стосовно того в яких одиницях буде вимірюватися крок горизонтальних та вертикальних ліній”
    • Нефункціональна вимога “стосується інтерфейсу - у який спосіб користувач буде вибирати режими відображення /невідображення сітки”


Приклад реалізації інтерфейсу до підсистеми виведення полів концентрацій шкідливих викидів



Уточнення вимог до підсистеми виведення полів концентрацій шкідливих викидів

  • 3.1. Вимоги до підсистеми виведення полів концентрацій шкідливих викидів

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

    • Виділення виключно функціональних вимог
    • Відсутня надмірна деталізація, яка не на користь замовнику обмежує можливості розробника.
    • Введено обґрунтування, яке дозволяє замовнику зрозуміти потребу у цій вимозі і наскільки ця вимога може змінюватися в майбутньому.


Системні вимоги

  • Це деталізований опис вимог користувачів і є основою для початку проектування системи

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

  • Показують в першу чергу що повинна робити система, а також можливість відображення системної архітектури:

    • Повинні описувати підсистеми із яких складається система
    • Вказувати обмеження на архітектуру системи, яка буде взаємодіяти із іншими системами
    • Можуть включати умову використання для даної системи спеціальної архітектури


Класифікація вимог до програмного забезпечення та програмних систем.

  • Класифікація вимог до програмного забезпечення та програмних систем.

  • Специфікація вимог

  • Що означає процес формулювання вимог?



Способи специфікації системних вимог

  • Структурована природна мова

  • Мови опису програм

    • Структуровані мови, подібні до мов програмування
  • Графічні нотації

    • Діаграми, блок-схеми, описані текстом.
      • Використання UML
  • Математичні специфікації

    • Базуються на теорії скінченних автоматів та теорії множин.


Структурована природна мова

  • Структурованість досягається: використанням спеціальної термінології; шаблонів для опису вимог. Мовні конструкції взяті із мов програмування.

  • Шаблони враховують на основі чого розробляється система: на основі об'єктів, які керуватимуть системою, на основі функцій, виконуватиме система, на основі подій, які опрацьовуватиме система.

  • Форми для специфікації функцій включають:

    • Опис функції чи об'єкта;
    • Опис вхідних даних та їх джерела;
    • Опис вихідних даних із вказівкою пункту призначення;
    • Вказівка, що необхідно для виконання функції;
    • Опис попередніх умов до виконання функції та кінцевих умов після її завершення;
    • Опис сторонніх побічних ефектів, якщо вони виникають.


Приклад специфікації структурованою природною мовою

  • Функція: Внесення джерела забруднень на карту

  • Опис: Внесення додаткових джерел забруднення на існуючу карту міста. Користувач вибирає тип джерела забруднень та координати його розміщення переміщенням курсору миші по карті.

  • Вхідні дані: Тип джерела, позиція на карті, розміри СЗЗ, ідентифікатор карти

  • Джерела даних: Тип джерела, позиція на карті, задаються користувачем, розміри СЗЗ, ідентифікатор карти – з баз даних, відповідно “довідники СЗЗ” та “карти”

  • Вихідні дані: ідентифікатор карти.

  • Пункт призначення: база даних “карти”. Ідентифікатор розміщується після завершення функції.

  • Для виконання функції необхідна карта, яка визначається вхідним ідентифікатором.

  • Передумова: карта відкрита на екрані користувача.

  • Післяумова: карта не змінюється за виключенням нанесеного об'єкта.

  • Побічні ефекти : відсутні.



Документування системних вимог

  • Документ, який включає системні вимоги - специфікація системних вимог за Хеннінгером:

    • Описує зовнішню поведінку;
    • Задає обмеження на процес реалізації системи;
    • Передбачає можливість внесення змін до специфікації;
    • Служить довідником в процесі супроводу системи;
    • Відтворює життєвий цикл системи;
    • Передбачає реакцію системи та групи супроводу на нештатні ситуації.


Складові специфікації системних вимог (стандарт IEEE/ANSI 830-1993)

  • Передмова

    • Особи, для яких розробляють документ;
    • Попередні версії та зміни внесені в ПЗ
    • Обґрунтування нової версії
  • Вступ

    • Потреби в створенні системи
    • Системні функції та пояснення роботи із іншими системами
    • Пояснення, який ефект для організації після впровадження системи
  • Глосарій – опис технічних термінів документу

  • Вимоги користувачів

    • Опис сервісів (функцій), які надаються користувачу;
    • Не функціональні системні вимоги;
    • Стандарти на ПЗ та на процес створення;
  • Системна архітектура

    • Високорівневе представлення архітектури із розподілом функцій по компонентах системи із виділенням існуючих компонент
  • Системні вимоги: Функціональні та не функціональні

  • Системні моделі

    • Показують взаємодію між компонентами та зовнішнім середовищем
    • Типи: моделі потоків даних; об'єктні; моделі даних
  • Еволюція системи

    • Припущення на яких базується система
    • Зміна апаратних засобів, необхідна для реалізації системи
    • Зміна системи відповідно до потреб користувачів в майбутньому
  • Додатки

    • Опис апаратних засобів (мінімальна та максимальна конфігурація) та баз даних(логічна структура із якою працюватиме ПЗ) із якими працюватиме система


Підсумки Класифікація вимог до програмного забезпечення та програмних систем. Специфікація вимог

  • Вимоги до ПС –це описи того, що повинна виконувати система, а також обмеження на її поведінку та реалізацію

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

  • Вимоги предметної області – це функціональні вимоги предметної області, де буде експлуатуватися система

  • Не функціональні вимоги – це обмеження, які накладаються на систему, на процес її розробки та зовнішні вимоги, які описують властивості системи в цілому.

  • Вимоги користувачів призначені для осіб, які будуть експлуатувати систему – формулюються звичайною мовою із використанням графічних матеріалів.

  • Системні вимоги – максимально точно описують функції системи. Для їх опису використовують структуровані мови, або спеціальні мови для специфікації вимог.

  • Специфікація вимог- офіційний документований їх опис, який використовують розробники та користувачі.



Класифікація вимог до програмного забезпечення та програмних систем.

  • Класифікація вимог до програмного забезпечення та програмних систем.

  • Специфікація вимог

  • Що означає процес формулювання вимог?



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

  • Діючі особи процесу

    • Замовники, чи носії їх інтересів;
    • Користувачі системи (оператори, обслуговуючий персонал);
    • Розробники системи.
  • Основні етапи процесу:

    • Аналіз технічної можливості створення системи
      • Звіт про технічну можливість створення;
    • Формування та аналіз вимог;
      • Моделі системи;
    • Специфікація вимог
      • Вимоги користувачів та системні вимоги
    • Атестація вимог.
      • Документація зі специфікацією вимог.


Аналіз технічної можливості створення системи

  • Чи система відповідає загальним і функціональним цілям замовника та розробника?

  • Чи можливою є її реалізація із використанням існуючих технологій і не виходячи за межі розумної вартості?

  • Чи можливо об'єднати розроблювану систему із існуючими в експлуатації?

  • Аналіз технічної можливості також включає:

    • Які зміни відбудуться в організації, якщо система буде введена в дію?
    • Які існують поточні проблеми в організації і як з допомогою нової системи вони можуть бути розв'язані?
    • Яким чином система буде забезпечувати функціональні цілі?
    • Чи може бути система створена в межах технологій, які раніше використовувалися в даній організації?
    • Які джерела інформації необхідно використати для отримання відповіді на поставленні запитання?


Формування та аналіз вимог

  • Причини складності:

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


Етапи формування та аналізу вимог

  • Особливості - процес є циклічним із зворотними зв'язками від одного етапу до іншого

    • Аналіз предметної області
    • Збирання вимог
    • Класифікація вимог
    • Розв'язування протиріч при формуванні вимог
    • Призначення приорітетів по вимогах
    • Перевірка повноти та не протиріч по вимогах


Основні підходи до формулювання вимог



Метод опорних точок зору

  • Особливості: Різні типи користувачів та розробників-різні точки зору, інтереси та вимоги.

  • Точки зору слід розглядати:

    • Як користувачів системи
    • Як джерело інформації про системні дані;
    • Як структуру представлень – особлива частина моделі;
    • Як отримувачів системних сервізів – визначають данні для виконання системних сервізів;
  • Переваги: Багато поглядів забезпечує базу для знаходження протиріч у вимогах.

  • Недоліки: Складність використання в процесі структурного аналізу, оскільки відсутні зв'язки між точками зору.



Зовнішні опорні точки зору (viewpoint-oriented requirements definition)

  • Особливості:

    • Найбільш придатні для побудови інтерактивних систем: банкомати, довідкові системи, тощо;
    • Зовнішні точки зору дозволяють структуризувати процес формування вимог;
    • Усі опорні точки зору повинні відображати хоча б один спосіб взаємодії із системою;
    • Підхід є корисним для формулювання не функціональних вимог з якими можна зв'язати певний сервіз
  • Етапи:

    • Ідентифікація точок зору і відповідних до них сервізів;
    • Структуризація – створення ієрархії згрупованих точок зору;
    • Документування опорних точок зору;
    • Відображення системних об'єктів на основі інформації із опорних точок зору.


Метод сценаріїв

  • Особливості:

    • Спосіб доступного опису взаємодії з ПС;
    • Корисні для деталізації опису вимог;
    • Надають інформацію для деталізації різних рівнів системи.
  • Етапи:

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

    • Сценарії подій (на прикладі методу VORD);
    • Варіанти використання (на прикладі UML)


Сценарії подій (на прикладі методу VORD);

  • Особливості:

    • Кожна подія документується як сценарій;
    • Описуються: потоки, системні операції та особливі події, що можуть виникнути.
  • Використовуються такі елементи:

    • Дані, що поступають чи виходять із системи
    • Опис системних операцій
    • Інформація для управління
    • Внутрішньо системні дані
    • Особливі ситуації
    • Наступна подія після завершення сценарію


Варіанти використання (на прикладі UML)

  • Особливості:

    • Використовуються для опису об'єктних моделей систем;
    • Описуються: діючі особи, тобто користувачі та назви типів взаємодії.
    • Зауваження: на початкових стадіях без конкретизації потоків подій


Етнографічний метод

  • Особливості:

    • Розробник знаходиться в середовищі де буде функціонувати розроблена система і протоколює реальні дії, що виконуються користувачами системи;
    • Використовується для розуміння та формування соціальних та організаційних аспектів експлуатації системи;
    • Дозволяє деталізувати вимоги для критичних систем;
    • Орієнтований на конкретного користувача і не може повністю врахувати вимоги предметної області та організаційного характеру;
    • Дозволяє виявити неявні вимоги до системи, оскільки;
    • Для забезпечення повноти вимог застосовується спільно із аналізом варіантів використання;
    • Поєднується із прототипуванням
    • Використовується для розв'язання конкретних проблем прототипування та оцінювання створеного прототипу.


Атестація вимог.

  • Мета: Перевірка, що вимоги визначають ту систему, яка відповідає баченню замовника

  • Реалізується різними типами перевірок: достовірності; непротирічності; повноти; реальності виконання.

  • Методи атестування вимог:

    • Системний аналіз рецензентами;
    • Прототипування;
    • Генерування тестових завдань та їх аналіз
    • Автоматизований аналіз непротиріч
      • Можливе застосування, коли вимоги представлені у вигляді структурних чи формальних системних моделей.


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

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

  • Аналіз вимог – ітераційний процес, який включає: Аналіз предметної області; збирання, класифікацію вимог; розв'язування протиріч при формуванні вимог; призначення приорітетів по вимогах; перевірка повноти та не протиріч по вимогах.

  • Особи, які формулюють вимоги мають різні приорітети та інтереси, тому складні системи необхідно аналізувати із різних точок зору.

  • Соціальні та організаційні фактори суттєвим чином впливають на системні вимоги.

  • Атестація вимог – це перевірка їх на достовірності; непротирічності; повноти; реальності виконання.

  • Основними методами атестації вимог є: системний аналіз рецензентами; прототипування; генерування тестових завдань та їх аналіз




База даних захищена авторським правом ©pres.in.ua 2016
звернутися до адміністрації

    Головна сторінка