Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АрхитектураБиологияГеографияДругоеИностранные языки
ИнформатикаИсторияКультураЛитератураМатематика
МедицинаМеханикаОбразованиеОхрана трудаПедагогика
ПолитикаПравоПрограммированиеПсихологияРелигия
СоциологияСпортСтроительствоФизикаФилософия
ФинансыХимияЭкологияЭкономикаЭлектроника

Характеристики правильно складеної спеки



Читайте также:
  1. E) Нет правильного ответа
  2. I. Схема характеристики.
  3. III. Экономические и эксплуатационные характеристики
  4. V - образные характеристики
  5. А правильно ли...?
  6. Анализ энергетического баланса электромагнита и вывод общей формулы для расчёта тяговой характеристики электромагнита.
  7. Асимптотические характеристики

 

Коректність. Спека є коректною, якщо кожна вимога, яка вкладена в ній є вимогою, якій повинно задовольняти ПЗ. (Чи правильно спека визначає потреби користувача даної системи).

 

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

 

Повнота (завершеність). Спека є повною, якщо вона включає наступні елементи:

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

· Визначення відгуків ПЗ на всі класи вхідних даних, які можуть бути реалізовані, в усіх можливих ситуаціях.

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

 

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

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

Двома типами ймовірних конфліктів в спеці є наступні:

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

· Між двома заданими діями може існувати логічний або тимчасовий поті. Наприклад, одна вимога може встановлювати, що «А» повинно завжди слідувати за «Б», в той час як інша може вимагати, щоб події «А» і «Б» відбувалися одночасно.

 

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

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

Кожна вимога в спеці повинна бути ідентифікована (необхідна або бажана), щоб зробити ці відмінності чіткими і явними. Ідентифікація вимог наступним чином допомагає:

1. Замовникам більш ретельно розглянути вимогу, що часто дозволяє роз’яснити будь-які приховані припущення, які можуть бути укладені в них.

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

 

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

1. Необхідні. Припускають, що ПЗ не буде придатним, якщо ці вимоги не будуть забезпечені узгодженим чином.

2. Умовні. Припускають, що ці вимоги розширяють ПП, але не зроблять його непридатним за їх відсутності.

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

 

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

Неперевіряємі вимоги включають формулювання типу «працює добре», «гарний інтерфейс з користувачем» і «зазвичай має відбуватися». Ці вимоги не можуть бути перевірені.

Прикладом перевіряє мого твердження є наступне: Вихідні дані програми повинні вироблятися в межах 20 секунд протягом 60% часового інтервалу подій і повинні вироблятися в межах 30 секунд протягом 100% часового інтервалу подій.

Якщо не можна винайти метод, щоб визначити відповідає ПЗ певній вимозі, то цю вимогу слід виключити.

 

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

Якщо правило кодифікованість вимагає, щоб спека:

1. Мала зв’язану і легку у використанні структуру зі змістом, алфавітним покажчиком.

2. Не була надмірною (тобто, одна і та ж вимога не повинна з`являтися в спеці більше ніж в одному місці).

3. Висловлювала кожну вимогу роздільно, не змішуючи її х іншими вимогами.

 

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

Рекомендуються наступні два типи відслідковуваності:

1. Зворотня відслідковуваність (до попередніх стадій розробки). Залежить від кожної вимоги, яке в явному вигляді посилається на її джерело в більш ранніх документах.

2. Пряма відслідковуваність (до всіх документів, породжуваним спекою). Залежить від кожної вимоги в спеці, що має однозначно певне ім»я або номер посилання.

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

 

  1. Способи представлення вимог

· Документація, в якій використовується чітко структурована і акуратно використовувана природна мова

· Графічні моделі, що ілюструють процеси трансформації, стану системи і їх зміни, взаємодію даних, а також логічні потоки, класи об’єктів і відношення між ними

· Формальні специфікації, де вимоги визначені за допомогою математично точних, формальних логічних мов.

 

Результат розробки вимог – задокументована угода між клієнтами і розробниками про створюваний продукт.

Детальні функціональні і не функціональні вимоги до продукту записуються в специфікаціях до ПЗ.

 

  1. Специфікація вимог до ПЗ

Специфікація вимог до ПЗ – закінчений опис поведінки системи, яку потрібно розробити.

 

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

 

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

1. Клієнтам – відділ маркетингу і спеціалісти з продажу хочуть мати уявлення про кінцевий продукт

2. Менеджерам проекту – за даними спеки розраховуються графіки, витрати і необхідні ресурси

3. Команді розробників ПЗ – отримує представлення про створюваний продукт

4. Групі тестування – складає плати тестування, варіанти використання і процедури.

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

6. Укладачам документації – створюють керівництва для користувачів і вікна довідки на основі специфікації вимог до ПЗ і дизайну користувацького інтерфейсу

7. Спеціалістам, що відповідають за інструктування (навчання) персоналу – необхідна спека вимог до ПЗ і документація для користувачів для розробки навчальних матеріалів

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

 

Основні питання, що розглядаються SRS:

6. Функціональні можливості. Які передбачувані функції ПЗ?

7. Зовнішні інтерфейси. Як ПЗ взаємодії з користувачем, апаратними засобами системи, іншими апаратними засобами і іншим ПЗ?

8. Продуктивність (робочі характеристики). Яка швидкодія, досяжність, час відгуку, час відновлення різних функцій ПЗ?

9. Атрибути. Яка мобільність, правильність, зручність супроводження, захищеність ПЗ і інші критерії?

10. Можливі проектні обмеження, що накладаються на реалізацію. Чи існують необхідні стандарти на ефективні мові реалізації, політика по збереженню цілісності БД, обмеження ресурсів, операційне середовище (ща) і т.д.?

 


Дата добавления: 2015-07-11; просмотров: 203 | Нарушение авторских прав






mybiblioteka.su - 2015-2024 год. (0.009 сек.)