98774

Шаблони специфікацій вимог до програмного забеспечення

Реферат

Информатика, кибернетика и программирование

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

Украинкский

2015-11-06

44.25 KB

1 чел.

Шаблони специфікацій вимог до програмного забеспеченняАналіз вимог до ПЗ

ЗМІСТ

  1.  Вступна частина …………………………………………………2
  2.  Класи систем…………………………………………………….. 4
  3.  Режими системи…………………………………………...4
  4.  Класи користувачів………………………………………. 4
  5.  Об’єкти……………………………………………………. 4
  6.  Властивості………………………………………………...5
  7.  Стимул…………………………………………………….. 5
  8.  Відгук……………………………………………………… 5
  9.  Функціональна ієрархія…………………………………...5
  10.  Додаткова інформація……………………………………. 6
  11.  Шаблони…………………………………………………………..7
  12.  Висновок………………………………………………………….17

  1.  Вступна частина

Сецифікація вимог до програмного забезпечення (Software Requirements Specification) - це повний опис поведінки системи до її розробки. Вона включає в себе безліч варіантів використання, які описують всі взаємодії користувачів з програмним забезпеченням. На додаток до варіантів використання, SRS також містить нефункціональні (або додаткові) вимоги. Номери для функціональних вимог , які накладають обмеження при розробці і здійсненні (наприклад, продуктивність технічних вимог, стандартів якості, або конструктивних обмежень).

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

Переваги гарної SRS:

  1.  Створення основи для угоди між клієнтами і постачальниками на тому, що програмний продукт     робити.
  2.  Скорочення зусиль у сфері розвитку.
  3.  Забезпечення основи для оцінки витрат і графіків.
  4.  Забезпечення основи для перевірки та контролю.
  5.  Подавати в якості основи для аксесуара.

Специфікація вимог до програмного забезпечення адресується на:

  1.  Функціональність: Що дане програмне забезпечення повинно робити?
  2.  Зовнішні інтерфейси: Яким чином ПЗ буде взаємодіяти з людьми, апаратними системами, іншим обладнанням, та іншим програмним забезпеченням?
  3.  Продуктивність: Що таке швидкість, доступність, час відгуку, час відновлення різних функцій програмного забезпечення, і т.д.?
  4.  Атрибути: Що таке мобільність, точність, простота обслуговування, безпека і т.д. ?
  5.  Дизайн обмежень на здійснення. Є всі необхідні стандарти по суті, мови реалізації, політика для цілісності бази даних, обмеження по ресурсах, використовуваної операційної системи і т.д.?

Характеристики якісної специфікації вимог:

  1.  Коректність
  2.  Однозначність
  3.  Повнота
  4.  Логічність
  5.  Стабільність
  6.  Перевіряємість.

Важливо розглянути ту роль, яку SRS грає в загальному плані проекту, який визначається в стандарті IEEE 610.12-1990. По суті, програмне забезпечення може включати всі функціональні можливості проекту або може бути частиною більшої системи. В останньому випадку звичайно є SRS, яка буде встановлювати інтерфейси між системою і частиною її програмного забезпечення, і буде поширювати зовнішні вимоги до характеристик і функцій на цю частину програмного забезпечення. Звичайно, в цьому випадку SRS повинна бути узгоджена і розширена у відповідності з цими системними вимогами.

Стандарт IEEE 1074-1997 описує стадії життєвого циклу програмного забезпечення і відповідні вхідні дані для кожної стадії. Інші стандарти,  належать до інших частин життєвого циклу програмного забезпечення і можуть доповнювати вимоги до програмного забезпечення.

Так як SRS відіграє певну роль у процесі розробки програмного забезпечення, упорядника (-ям) SRS слід проявляти обережність, щоб не вийти за межі цієї ролі. Це означає, що SRS:

  1.  Повинна правильно визначати всі вимоги до програмного забезпечення. Причиною існування будь-які вимоги до програмного забезпечення може бути характер розв'язуваної задачі або особлива характеристика проекту.
  2.  Не повинна описувати деталі розробки або реалізації. Вони повинні бути описані на етапі розробки проекту.
  3.  Не повинна накладати додаткові обмеження на програмне забезпечення. Ці обмеження належним чином визначаються в інших документах, таких як план забезпечення якості програмних засобів.

  1.  Класи систем

Перед тим як розглядати самі шаблони специфікацій вимог до програмного забезпечення, розглянемо спочатку різні способи організації вимог для різних класів систем, що описані в стандарті IEEE 830-1998.

2.1. Режими системи

Деякі системи ведуть себе зовсім по-різному залежно від режиму роботи. Наприклад, система управління може мати різні набори функцій залежно від режиму: навчання, нормальний режим або аварійний. При організації цього розділу за режимами слід використовувати шаблон, представлену в розділі А.1 або А.2. Вибір залежить від того, чи є інтерфейси і характеристики залежними від режиму.

  1.  . Клас користувачів

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

2.3. Об’єкти

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

2.4. Властивість

Властивість - це послуга, необхідна системою ззовні, для якої може бути необхідною послідовність вхідних впливів для отримання бажаного результату. Наприклад, в телефонній системі властивості включають локальний виклик, переадресацію викликів і циркулярний виклик. Кожна властивість в цілому описується в послідовності пар вхідний вплив (стимул)-відгук. При організації цього розділу за властивостями слід використовувати шаблон, представлений в розділі А.5.

2.5. Стимул

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

2.6. Відгук

Деякі системи можуть бути найкраще організовані за допомогою опису всіх функцій для підтримки генерації відповіді. Наприклад, функції системи обліку персоналу можуть бути організовані в розділи, відповідні всіх функцій, пов'язаних зі складанням чеків з оплати, всіх функцій, пов'язаних зі складанням поточного списку службовців і т.д. У цьому випадку слід використовувати шаблон, представлений у розділі А.6 (з усіма подіями стимулів, замінених відгуком).

2.7. Функціональна ієрархія

Якщо жодна з вищезгаданих організаційних схем виявляється непридатною, повні функціональні можливості можуть бути організовані в ієрархію функцій, організованих чи за загальними вхідним впливів, або за загальним вихідним даним, або по загальному доступу до внутрішніх даних. Щоб показати зв'язок між функціями і даними, можна використовувати схеми потоків даних і словники даних. При організації цього розділу з функціональної ієрархії слід використовувати шаблон, представлений у розділі А.7.

2.8. Додаткова інформація

При розгляді нової SRS підходящими може виявитися більше одного з методів організації, наведених у пункті 2.7. У таких випадках можна організувати специфічні вимоги для декількох ієрархій, пристосовані до конкретних потреб спеціфіціруемий системи. Наприклад, спосіб організації, що об'єднує клас користувачів і властивості. Будь-які додаткові вимоги можуть бути включені в окремий розділ у кінці SRS.

Існує безліч систем позначень, методів і автоматизованих засобів підтримки, доступних для забезпечення допомоги у документуванні вимог. Здебільшого, їх корисність є функцією способу організації. Наприклад, при організації вимог за режимами можуть виявитися корисними кінцеві автомати або діаграми станів; при організації по об'єктах - метод об'єктно-орієнтованого аналізу; при організації за властивостями - послідовності стимул-відгук; а при організації з функціональної ієрархії-схеми потоків даних і словники даних .

У будь-якій із схем, представлених у розділах з А. .1 по А.7, пункти, озаглавлені "Функціональна вимога", можуть бути описані на оригінальній мові (наприклад, англійській), в псевдокоді, мовою визначень системи або в чотирьох підрозділах, озаглавлених: Введення, Вхідні дані, Обробка й Вихідні дані.

  1.  Шаблони

А.1 Шаблон розділу 2.1 SRS, організованого за режимами: Версія 1

     1. Специфічні вимоги

         1.1 Вимоги до зовнішніх інтерфейсів

             1.1.1 Інтерфейси користувача

             1.1.2 Апаратні інтерфейси

             1.1.3 Інтерфейси програмного забезпечення

             1.1.4 Інтерфейси зв'язку

         1.2 Функціональні вимоги

             1.2.1 Режим 1

                 1.2.1.1 Функціональне вимога 1.1

                 1.2.1.n Функціональне вимогу 1 .. п

             1.2.m Режим m

                 1.2.m.1 Функціональне вимога m.1

                 1.2.mn Функціональне вимога mn

         1.3 Вимоги до робочих характеристик

         1.4 Проектні обмеження

         1.5 Атрибути системи програмного забезпечення

         1.6 Інші вимоги

А.2 Шаблон розділу 2.1 SRS, організованого за режимами: Версія 2

1. Специфічні вимоги

     1.1 Функціональні вимоги

         1.1.1 Режим 1

             1.1.1.1 Зовнішні інтерфейси

                 1.1.1.1.1 Інтерфейси користувача

                 1.1.1.1.2 Апаратні інтерфейси

                 1.1.1.1.3 Інтерфейси програмного забезпечення

                 1.1.1.1.4 Інтерфейси зв'язку

             1.1.1.2 Функціональні вимоги

             1.1.1.2.n Функціональне вимога n

             1.1.1.3 Робочі характеристики

         1.1.m Режим m

             1.1.m.1 Зовнішні інтерфейси

                 1.1.m.1.1 Інтерфейси користувача

                 1.1.m.1.2 Апаратні інтерфейси

                 1.1.m.1.3 Інтерфейси програмного забезпечення

                 1.1.m.1.4 Інтерфейси зв'язку

             1.1.m.2 Функціональні вимоги

                

   1.1.m.2.n Функціональне вимога n

              1.1.m.3 Робочі характеристики

     1.2 Проектні обмеження

     1.3 Атрибути системи програмного забезпечення

     1.4 Інші вимоги

А.З Шаблон розділу 2.2 SRS, організованого за класами користувачів

     1. Специфічні вимоги

         1.1 Вимоги до зовнішніх інтерфейсів

             1.1.1 Інтерфейси користувача

             1.1.2 Апаратні інтерфейси

             1.1.3 Інтерфейси програмного забезпечення

             1.1.4 Інтерфейси зв'язку

         1.2 Функціональні вимоги

             1.2.1 Клас користувачів 1

                 1.2.1.1 Функціональне вимога 1.1

                 1.2.1.n Функціональне вимога 1.n

             1.2.m Клас користувачів m

                 1.2.m.1 Функціональне вимога m. .1

                 1.2.mn Функціональне вимога mn

         1.3 Вимоги до робочих характеристик

        

         1.4 Проектні обмеження

          1.5 Атрибути системи програмного забезпечення

         1.6 Інші вимоги

А.4 Шаблон розділу 2.3 SRS, організованого по об'єктах

    1. Специфічні вимоги

        1.1 Вимоги до зовнішніх інтерфейсів

            1.1.1 Інтерфейси користувача

            1.1.2 Апаратні інтерфейси

            1.1.3 Інтерфейси програмного забезпечення

            1.1.4 Інтерфейси зв'язку

        1.2 Класи / Об'єкти

            1.2.1 Класс/Об'ект1

                1.2.1.1 Атрибути (прямі або успадковані)

                    1.2.1.1.1 Атрибут 1

                    1.2.1.1.n Атрибут n

                1.2.1.2 Функції (послуги, методи, прямі чи успадковані)

                    1.2.1.2.1 Функціональне вимога 1.1

                    1.2.1.2.m Функціональне вимога 1.m

                1.2.1.3 Повідомлення (отримані або відправлені)

            1.2.р Клас / Об'єкт р

                1.2.p.1 Атрибути (прямі або успадковані)

                    1.2.p.1.1 Атрибут 1

                    1.2.p.1.n Атрибут n

                1.2.p.2 Функції (послуги, методи, прямі чи успадковані)

                    1.2.p.2.1 Функціональне вимога p.1

                    1.2.p.2.m Функціональне вимога pm

                1.2.p.3 Повідомлення (отримані або відправлені)

            1.3 Вимоги до робочих характеристик

            1.4 Проектні обмеження

            1.5 Атрибути системи програмного забезпечення

            1.6 Інші вимоги

А.5 Шаблон розділу 2.4 SRS, організованого за властивостями

1. Специфічні вимоги

     1.1 Вимоги до зовнішніх інтерфейсів

         1.1.1 Інтерфейси користувача

         1.1.2 Апаратні інтерфейси

         1.1.3 Інтерфейси програмного забезпечення

         1.1.4 Інтерфейси зв'язку

     1.2 Властивості системи

         1.2.1 Властивість системи 1

             1.2.1.1 Введення / Призначення властивості

             1.2.1.2 Послідовність стимулів / відгуків

             1.2.1.3 Асоційовані функціональні вимоги

                 1.2.1.3.1 Функціональне вимогу 1

                 1.2.1.3.n Функціональне вимога n

         1.2.m Властивість системи m

             1.2.m.1 Введення / Призначення властивості

             1.2.m.2 Послідовність стимулів / відгуків

             1.2.m.3 Асоційовані функціональні вимоги

                 1.2.m.3.1 Функціональне вимогу 1

                 1.2.m.3.n Функціональне вимога n

     1.3 Вимоги до робочих характеристик

     1.4 Проектні обмеження

     1.5 Атрибути системи програмного забезпечення

     1.6 Інші вимоги

А.6 Шаблон розділу 2.5 та 2.6 SRS, організованого за стимулам

1. Специфічні вимоги

     1.1 Вимоги до зовнішніх інтерфейсів

         1.1.1 Інтерфейси користувача

         1.1.2 Апаратні інтерфейси

         1.1.3 Інтерфейси програмного забезпечення

         1.1.4 Інтерфейси зв'язку

     1.2 Функціональні вимоги

         1.2.1 Стимул 1

             1.2.1.1 Функціональне вимога 1.1

             1.2.1.n Функціональне вимога 1.n

         1.2.m Стимул m

             1.2.m.1 Функціональне вимога m.1

             1.2.mn Функціональне вимога mn

     1.3 Вимоги до робочих характеристик

     1.4 Проектні обмеження

     1.5 Атрибути системи програмного забезпечення

     1.6 Інші вимоги

А.7 Шаблон розділу 2.7 SRS, організованого з функціональної ієрархії

1. Специфічні вимоги

    1.1 Вимоги до зовнішніх інтерфейсів

        1.1.1 Інтерфейси користувача

        1.1.2 Апаратні інтерфейси

        1.1.3 Інтерфейси програмного забезпечення

        1.1.4 Інтерфейси зв'язку

    1.2 Функціональні вимоги

        1.2.1 Інформаційні потоки

            1.2.1.1 Схема потоку даних 1

                1.2.1.1.1 Інформаційні об'єкти

                1.2.1.1.2 Релевантні потоки

                1.2.1.1.3 Топологія

            1.2.1.n Схема потоку даних n

                1.2.1.n.1 Інформаційні об'єкти

                1.2.1.n.2 Релевантні потоки

                1.2.1.n.З Топологія

        1.2.2 Опис процесів

            1.2.2.1 Процес 1

                

               1.2.2.1.1 Об'єкти вхідних даних

                1.2.2.1.2 Алгоритм або формула процесу

                1.2.2.1.3 Об'єкти оброблюваних даних

            1.2.2.m Процес m

                1.2.2.m.1 Об'єкти вхідних даних m.1,

                1.2.2.m.2 Алгоритм або формула процесу

                1.2.2.m.З Об'єкти оброблюваних даних

        1.2.3 Специфікації структури даних

            1.2.3.1 Структура 1

                1.2.3.1.1 Тип запису

                1.2.3.1.2 Складові подя

            1.2.3.p Структура р

                1.2.3.p.1 Тип запису

                1.2.3.p.2 Складові поля

        1.2.4 Словник даних

            1.2.4.1 Елемент даних 1

                1.2.4.1.1 Ім'я

                1.2.4.1.2 Представлення

                1.2.4.1.3 Одиниці / Формат

                1.2.4.1.4 Розрядність / Точність

                1.2.4.1.5 Діапазон

            1.2.4.q Елемент даних q

                1.2.4.q.1 Ім'я

                1.2.4.q.2 Представлення

                1.2.4.q.3 Одиниці / Формат

                1.2.4.q.4 Розрядність / Точність

                1.2.4.q.5 Діапазон

    1.3 Вимоги до робочих характеристик

    1.4 Проектні обмеження

    1.5 Атрибути системи програмного забезпечення

    1.6 Інші вимоги


      
        
        


  1.  Висновок

В даному рефераті було розглянуто уривки стандарту IEEE 830-1998, у яких розкривається поняття шаблонів специфікацій вимог до програмного забезпечення.

У рефераті були показані основні класи систем, кожний клас був описаний та для кожного класу були наведені відповідні шаблони специфікацій вимог до ПЗ.