|
Читайте также: |
Коректність. Спека є коректною, якщо кожна вимога, яка вкладена в ній є вимогою, якій повинно задовольняти ПЗ. (Чи правильно спека визначає потреби користувача даної системи).
Однозначність. Спека є однозначною, якщо викладена в ній вимога може інтерпретуватися тільки однозначно. Як мінімум, для цього вимагається, щоб кожна характеристика кінцевого продукту була описана з використанням одного унікального терміну.
Повнота (завершеність). Спека є повною, якщо вона включає наступні елементи:
· Всі існуючі вимоги. Незалежно від того, відносяться вони до функціональних можливостей робочих характеристик, проектних обмежень, атрибутів або зовнішніх інтерфейсів.
· Визначення відгуків ПЗ на всі класи вхідних даних, які можуть бути реалізовані, в усіх можливих ситуаціях.
· Повні позначення і посилання на всі малюнки, таблиці і схеми в спеці і визначення усіх термінів і одиниць виміру.
Несуперечливість. Несуперечливість означає внутрішню несуперечливість. Якщо спека не погоджується із будь-яким документом більш високого рівня, то вона є некоректною (угоди. Системні специфікації або що).
Внутрішня несуперечливість. Спека є внутрішньо несуперечливою, якщо і тільки, якщо ніякий набір окремих вимог, описаних у ній, не знаходиться в суперечності із нею.
Двома типами ймовірних конфліктів в спеці є наступні:
· Можуть входити в конфлікт задані характеристики реальних об’єктів. Наприкла, (одна вимога може встановлювати, що всі індикатори мають бути зеленими, у той час як в іншій може бути зазначено, що всі індикатори повинні бути синіми).
· Між двома заданими діями може існувати логічний або тимчасовий поті. Наприклад, одна вимога може встановлювати, що «А» повинно завжди слідувати за «Б», в той час як інша може вимагати, щоб події «А» і «Б» відбувалися одночасно.
Упорядкованість за значущістю і/або за стійкістю. Спека є упорядкованою, якщо кожна вимога в ній має ідентифікатор, який вказує значимість чи стійкість цієї конкретної вимог.
Як правило, всі вимоги, які стосуються ПП, не є важливими в рівній мірі. Деякі вимоги можуть бути неєхидними, в той час, як інші можуть бути бажаними.
Кожна вимога в спеці повинна бути ідентифікована (необхідна або бажана), щоб зробити ці відмінності чіткими і явними. Ідентифікація вимог наступним чином допомагає:
1. Замовникам більш ретельно розглянути вимогу, що часто дозволяє роз’яснити будь-які приховані припущення, які можуть бути укладені в них.
2. Розробникам прийняти правильні проектні рішення, прикласти відповідні зусилля до різних складових програмного вибору.
Ступінь необхідності. Другий спосіб впорядкування вимог полягає в том, що б розрізняти класи вимог як необхідні, умовні і необов’язкові.
1. Необхідні. Припускають, що ПЗ не буде придатним, якщо ці вимоги не будуть забезпечені узгодженим чином.
2. Умовні. Припускають, що ці вимоги розширяють ПП, але не зроблять його непридатним за їх відсутності.
3. Необов`язкові. Припускають клас функцій, які можуть заслуговувати або не заслуговувати на увагу. Це дає постачальнику можливість запропонувати що-небудь, що виходить за межі спеки.
Перевіряємість. Спека є перевіряємою, якщо кожну вимогу, викладену в ній, можна буде перевірити. Вимога є перевіряємою, якщо існує якийсь кінцевий ефективний процес, використовуючи який користувач або машина можуть переконатися (впевнитись), що ПП задовольняє цій вимозі. У цілому, будь яка неоднозначна вимога не перевіряємо.
Неперевіряємі вимоги включають формулювання типу «працює добре», «гарний інтерфейс з користувачем» і «зазвичай має відбуватися». Ці вимоги не можуть бути перевірені.
Прикладом перевіряє мого твердження є наступне: Вихідні дані програми повинні вироблятися в межах 20 секунд протягом 60% часового інтервалу подій і повинні вироблятися в межах 30 секунд протягом 100% часового інтервалу подій.
Якщо не можна винайти метод, щоб визначити відповідає ПЗ певній вимозі, то цю вимогу слід виключити.
Модифікованість. Спека є тією, що модифікується, якщо її структура і стиль такі, що будь які зміни вимог можуть бути виконані легко повністю і несуперечливим чином при збереженні структури і стулю.
Якщо правило кодифікованість вимагає, щоб спека:
1. Мала зв’язану і легку у використанні структуру зі змістом, алфавітним покажчиком.
2. Не була надмірною (тобто, одна і та ж вимога не повинна з`являтися в спеці більше ніж в одному місці).
3. Висловлювала кожну вимогу роздільно, не змішуючи її х іншими вимогами.
Відслідковуваність. Спека є відслідковуванню, якщо чітко простежуються джерела кожної із її вимог, і якщо вона полегшує звертання до кожної із вимог при подальшій розробці або модернізації документації.
Рекомендуються наступні два типи відслідковуваності:
1. Зворотня відслідковуваність (до попередніх стадій розробки). Залежить від кожної вимоги, яке в явному вигляді посилається на її джерело в більш ранніх документах.
2. Пряма відслідковуваність (до всіх документів, породжуваним спекою). Залежить від кожної вимоги в спеці, що має однозначно певне ім»я або номер посилання.
Пряма відслідковуваність спеки є особливо важлива. Коли ПП входить у стадії функціонування і супроводу. По мірі зміни коду і проектних документів необхідно мати можливість визначити повний набір вимог, на які можуть вплинути ці зміни.
· Документація, в якій використовується чітко структурована і акуратно використовувана природна мова
· Графічні моделі, що ілюструють процеси трансформації, стану системи і їх зміни, взаємодію даних, а також логічні потоки, класи об’єктів і відношення між ними
· Формальні специфікації, де вимоги визначені за допомогою математично точних, формальних логічних мов.
Результат розробки вимог – задокументована угода між клієнтами і розробниками про створюваний продукт.
Детальні функціональні і не функціональні вимоги до продукту записуються в специфікаціях до ПЗ.
Специфікація вимог до ПЗ – закінчений опис поведінки системи, яку потрібно розробити.
Специфікація вимог до ПЗ інколи називають функціональною специфікацією, специфікацією продукту, документом про вимоги і системну специфікацію. В цьому документі точно вказуються функції і можливості, якими повинно володіти ПЗ, а також необхідні обмеження. Саме на основі спеки складаються плани розробки проекту і написання коду, а також особливості тестування системи і користувальницької документації. Вона повинна містити опис поведінки системи при різноманітних умовах. Деталі дизайну, збірки, тестування або управління проектом, зафіксовані в спеці, не повинні суперечити обмеженням розробки і розгортання.
Специфікація вимог до ПЗ необхідна різним учасникам проекту:
1. Клієнтам – відділ маркетингу і спеціалісти з продажу хочуть мати уявлення про кінцевий продукт
2. Менеджерам проекту – за даними спеки розраховуються графіки, витрати і необхідні ресурси
3. Команді розробників ПЗ – отримує представлення про створюваний продукт
4. Групі тестування – складає плати тестування, варіанти використання і процедури.
5. Спеціалістам по обслуговуванню і підтримки – отримують представлення про функціональності кожної складової частини продукту
6. Укладачам документації – створюють керівництва для користувачів і вікна довідки на основі специфікації вимог до ПЗ і дизайну користувацького інтерфейсу
7. Спеціалістам, що відповідають за інструктування (навчання) персоналу – необхідна спека вимог до ПЗ і документація для користувачів для розробки навчальних матеріалів
8. Персоналу, що займається юридичною стороною продукту – перевіряє, чи відповідають вимоги до продукту існуючим законам і постановам.
Основні питання, що розглядаються SRS:
6. Функціональні можливості. Які передбачувані функції ПЗ?
7. Зовнішні інтерфейси. Як ПЗ взаємодії з користувачем, апаратними засобами системи, іншими апаратними засобами і іншим ПЗ?
8. Продуктивність (робочі характеристики). Яка швидкодія, досяжність, час відгуку, час відновлення різних функцій ПЗ?
9. Атрибути. Яка мобільність, правильність, зручність супроводження, захищеність ПЗ і інші критерії?
10. Можливі проектні обмеження, що накладаються на реалізацію. Чи існують необхідні стандарти на ефективні мові реалізації, політика по збереженню цілісності БД, обмеження ресурсів, операційне середовище (ща) і т.д.?
Дата добавления: 2015-07-11; просмотров: 203 | Нарушение авторских прав