Характеристики правильно складеної спеки
Коректність. Спека є коректною, якщо кожна вимога, яка вкладена в ній є вимогою, якій повинно задовольняти ПЗ. (Чи правильно спека визначає потреби користувача даної системи).
Однозначність. Спека є однозначною, якщо викладена в ній вимога може інтерпретуватися тільки однозначно. Як мінімум, для цього вимагається, щоб кожна характеристика кінцевого продукту була описана з використанням одного унікального терміну.
Повнота (завершеність). Спека є повною, якщо вона включає наступні елементи:
Всі існуючі вимоги. Незалежно від того, відносяться вони до функціональних можливостей робочих характеристик, проектних обмежень, атрибутів або зовнішніх інтерфейсів.
Визначення відгуків ПЗ на всі класи вхідних даних, які можуть бути реалізовані, в усіх можливих ситуаціях.
Повні позначення і посилання на всі малюнки, таблиці і схеми в спеці і визначення усіх термінів і одиниць виміру.
Несуперечливість. Несуперечливість означає внутрішню несуперечливість. Якщо спека не погоджується із будь-яким документом більш високого рівня, то вона є некоректною (угоди. Системні специфікації або що).
Внутрішня несуперечливість. Спека є внутрішньо несуперечливою, якщо і тільки, якщо ніякий набір окремих вимог, описаних у ній, не знаходиться в суперечності із нею.
Двома типами ймовірних конфліктів в спеці є наступні:
Можуть входити в конфлікт задані характеристики реальних об’єктів. Наприкла, (одна вимога може встановлювати, що всі індикатори мають бути зеленими, у той час як в іншій може бути зазначено, що всі індикатори повинні бути синіми).
Між двома заданими діями може існувати логічний або тимчасовий поті. Наприклад, одна вимога може встановлювати, що «А» повинно завжди слідувати за «Б», в той час як інша може вимагати, щоб події «А» і «Б» відбувалися одночасно.
Упорядкованість за значущістю і/або за стійкістю. Спека є упорядкованою, якщо кожна вимога в ній має ідентифікатор, який вказує значимість чи стійкість цієї конкретної вимог.
Як правило, всі вимоги, які стосуються ПП, не є важливими в рівній мірі. Деякі вимоги можуть бути неєхидними, в той час, як інші можуть бути бажаними.
Кожна вимога в спеці повинна бути ідентифікована (необхідна або бажана), щоб зробити ці відмінності чіткими і явними. Ідентифікація вимог наступним чином допомагає:
Замовникам більш ретельно розглянути вимогу, що часто дозволяє роз’яснити будь-які приховані припущення, які можуть бути укладені в них.
Розробникам прийняти правильні проектні рішення, прикласти відповідні зусилля до різних складових програмного вибору.
Ступінь необхідності. Другий спосіб впорядкування вимог полягає в том, що б розрізняти класи вимог як необхідні, умовні і необов’язкові.
Необхідні. Припускають, що ПЗ не буде придатним, якщо ці вимоги не будуть забезпечені узгодженим чином.
Умовні. Припускають, що ці вимоги розширяють ПП, але не зроблять його непридатним за їх відсутності.
Необов`язкові. Припускають клас функцій, які можуть заслуговувати або не заслуговувати на увагу. Це дає постачальнику можливість запропонувати що-небудь, що виходить за межі спеки.
Перевіряємість. Спека є перевіряємою, якщо кожну вимогу, викладену в ній, можна буде перевірити. Вимога є перевіряємою, якщо існує якийсь кінцевий ефективний процес, використовуючи який користувач або машина можуть переконатися (впевнитись), що ПП задовольняє цій вимозі. У цілому, будь яка неоднозначна вимога не перевіряємо.
Неперевіряємі вимоги включають формулювання типу «працює добре», «гарний інтерфейс з користувачем» і «зазвичай має відбуватися». Ці вимоги не можуть бути перевірені.
Прикладом перевіряє мого твердження є наступне: Вихідні дані програми повинні вироблятися в межах 20 секунд протягом 60% часового інтервалу подій і повинні вироблятися в межах 30 секунд протягом 100% часового інтервалу подій.
Якщо не можна винайти метод, щоб визначити відповідає ПЗ певній вимозі, то цю вимогу слід виключити.
Модифікованість. Спека є тією, що модифікується, якщо її структура і стиль такі, що будь які зміни вимог можуть бути виконані легко повністю і несуперечливим чином при збереженні структури і стулю.
Якщо правило кодифікованість вимагає, щоб спека:
Мала зв’язану і легку у використанні структуру зі змістом, алфавітним покажчиком.
Не була надмірною (тобто, одна і та ж вимога не повинна з`являтися в спеці більше ніж в одному місці).
Висловлювала кожну вимогу роздільно, не змішуючи її х іншими вимогами.
Відслідковуваність. Спека є відслідковуванню, якщо чітко простежуються джерела кожної із її вимог, і якщо вона полегшує звертання до кожної із вимог при подальшій розробці або модернізації документації.
Рекомендуються наступні два типи відслідковуваності:
Зворотня відслідковуваність (до попередніх стадій розробки). Залежить від кожної вимоги, яке в явному вигляді посилається на її джерело в більш ранніх документах.
Пряма відслідковуваність (до всіх документів, породжуваним спекою). Залежить від кожної вимоги в спеці, що має однозначно певне ім»я або номер посилання.
Пряма відслідковуваність спеки є особливо важлива. Коли ПП входить у стадії функціонування і супроводу. По мірі зміни коду і проектних документів необхідно мати можливість визначити повний набір вимог, на які можуть вплинути ці зміни.
Способи представлення вимог
Документація, в якій використовується чітко структурована і акуратно використовувана природна мова
Графічні моделі, що ілюструють процеси трансформації, стану системи і їх зміни, взаємодію даних, а також логічні потоки, класи об’єктів і відношення між ними
Формальні специфікації, де вимоги визначені за допомогою математично точних, формальних логічних мов.
Результат розробки вимог – задокументована угода між клієнтами і розробниками про створюваний продукт.
Детальні функціональні і не функціональні вимоги до продукту записуються в специфікаціях до ПЗ.
Специфікація вимог до ПЗ
Специфікація вимог до ПЗ – закінчений опис поведінки системи, яку потрібно розробити.
Специфікація вимог до ПЗ інколи називають функціональною специфікацією, специфікацією продукту, документом про вимоги і системну специфікацію. В цьому документі точно вказуються функції і можливості, якими повинно володіти ПЗ, а також необхідні обмеження. Саме на основі спеки складаються плани розробки проекту і написання коду, а також особливості тестування системи і користувальницької документації. Вона повинна містити опис поведінки системи при різноманітних умовах. Деталі дизайну, збірки, тестування або управління проектом, зафіксовані в спеці, не повинні суперечити обмеженням розробки і розгортання.
Специфікація вимог до ПЗ необхідна різним учасникам проекту:
Клієнтам – відділ маркетингу і спеціалісти з продажу хочуть мати уявлення про кінцевий продукт
Менеджерам проекту – за даними спеки розраховуються графіки, витрати і необхідні ресурси
Команді розробників ПЗ – отримує представлення про створюваний продукт
Групі тестування – складає плати тестування, варіанти використання і процедури.
Спеціалістам по обслуговуванню і підтримки – отримують представлення про функціональності кожної складової частини продукту
Укладачам документації – створюють керівництва для користувачів і вікна довідки на основі специфікації вимог до ПЗ і дизайну користувацького інтерфейсу
Спеціалістам, що відповідають за інструктування (навчання) персоналу – необхідна спека вимог до ПЗ і документація для користувачів для розробки навчальних матеріалів
Персоналу, що займається юридичною стороною продукту – перевіряє, чи відповідають вимоги до продукту існуючим законам і постановам.
Основні питання, що розглядаються SRS:
Функціональні можливості. Які передбачувані функції ПЗ?
Зовнішні інтерфейси. Як ПЗ взаємодії з користувачем, апаратними засобами системи, іншими апаратними засобами і іншим ПЗ?
Продуктивність (робочі характеристики). Яка швидкодія, досяжність, час відгуку, час відновлення різних функцій ПЗ?
Атрибути. Яка мобільність, правильність, зручність супроводження, захищеність ПЗ і інші критерії?
Можливі проектні обмеження, що накладаються на реалізацію. Чи існують необхідні стандарти на ефективні мові реалізації, політика по збереженню цілісності БД, обмеження ресурсів, операційне середовище (ща) і т.д.?
Переваги і використання SRS
Документ SRS – однозначний і повний результат процесу специфікації інформаційної системи. Грамотно складений документ SRS надає наступні основні можливості:
Для замовника: точний опис того, що він хоче отримати
Для розробника: однозначне тлумачення і розуміння того, що хоче отримати замовник.
Вимоги до іменування
Контроль версій - це важливий аспект управління специфікаціями вимог та іншими проектними документами. Кожній версії слід присвоїти унікальний ідентифікатор. У кожного члена команди повинен бути доступ до поточної версії вимог, а зміни необхідно ясно документувати і передавати всім зацікавленим сторонам. Щоб мінімізувати плутанину, конфлікти і нерозуміння, потрібно призначити право поновлення вимог строго певним особам і переконатися, що ідентифікатор версії змінюється при кожній зміні вимоги.
Кожна версія документу повинна містити історію переробки, де вказуються внесені зміни, дата кожної з них, особу, що внесла зміни, а також причина.
Найпростіший механізм управління версіями - іменувати вручну кожну версію специфікації вимог до ПЗ згідно з угодою.
Спроба розрізняти версії документів за датою зміни часто призводить до помилок і плутанини, її не рекомендовано використовувати. Деякі команди доволі успішно застосовували таку угоду: перша версія будь-якого нового документа називається «Версія 1.0, начерк 1 ». Наступна називається «Версія 1.0, начерк 2 ». Автор послідовно збільшує номер начерку при кожній зміні і так до тих пір, поки документ не буде затверджена базова версія документа. Тоді назва змінюється на «Версія 1.0, затверджена». Наступні версії називаються «Версія 1.1, начерк 1» при невеликій зміні або «Версія 2.0, начерк 1» при значній зміні. При застосуванні цієї схеми ясно розрізняються начерки й версії базового документа, однак необхідно дотримуватися суворий порядок у веденні документації.
Варто додавати номер версії до назви кожної окремої вимоги і послідовно збільшувати її при модифікації.
Для документування версій використовуються текстові процесори, електронні таблиці.
Найбільш надійний метод контролю версій полягає в зберіганні вимог у базі даних комерційного засоби управління вимогами. Ці засоби відстежують повну історію змін вимог, що особливо важливо, якщо потрібно повернутися до більш ранньої версії вимоги. Такий засіб дозволяє вносити коментарі, де можна розумно обґрунтувати рішення про додавання, зміну або видалення вимоги; ці коментарі можуть виявитися корисними при необхідності обговорення вимоги у майбутньому.
Інтерфейси і специфікація вимог до ПЗ
Специфікація вимог до ПЗ – закінчений опис поведінки системи, яку потрібно розробити.
Специфікація вимог до ПЗ інколи називають функціональною специфікацією, специфікацією продукту, документом про вимоги і системну специфікацію. В цьому документі точно вказуються функції і можливості, якими повинно володіти ПЗ, а також необхідні обмеження. Саме на основі спеки складаються плани розробки проекту і написання коду, а також особливості тестування системи і користувальницької документації. Вона повинна містити опис поведінки системи при різноманітних умовах. Деталі дизайну, збірки, тестування або управління проектом, зафіксовані в спеці, не повинні суперечити обмеженням розробки і розгортання.
Специфікація вимог до ПЗ необхідна різним учасникам проекту:
Клієнтам – відділ маркетингу і спеціалісти з продажу хочуть мати уявлення про кінцевий продукт
Менеджерам проекту – за даними спеки розраховуються графіки, витрати і необхідні ресурси
Команді розробників ПЗ – отримує представлення про створюваний продукт
Групі тестування – складає плати тестування, варіанти використання і процедури.
Спеціалістам по обслуговуванню і підтримки – отримують представлення про функціональності кожної складової частини продукту
Укладачам документації – створюють керівництва для користувачів і вікна довідки на основі специфікації вимог до ПЗ і дизайну користувацького інтерфейсу
Спеціалістам, що відповідають за інструктування (навчання) персоналу – необхідна спека вимог до ПЗ і документація для користувачів для розробки навчальних матеріалів
Персоналу, що займається юридичною стороною продукту – перевіряє, чи відповідають вимоги до продукту існуючим законам і постановам.
Основні питання, що розглядаються SRS:
Функціональні можливості. Які передбачувані функції ПЗ?
Зовнішні інтерфейси. Як ПЗ взаємодії з користувачем, апаратними засобами системи, іншими апаратними засобами і іншим ПЗ?
Продуктивність (робочі характеристики). Яка швидкодія, досяжність, час відгуку, час відновлення різних функцій ПЗ?
Атрибути. Яка мобільність, правильність, зручність супроводження, захищеність ПЗ і інші критерії?
Можливі проектні обмеження, що накладаються на реалізацію. Чи існують необхідні стандарти на ефективні мові реалізації, політика по збереженню цілісності БД, обмеження ресурсів, операційне середовище (ща) і т.д.?
Требования к внешним интерфейсам
Интерфейсы пользователя (UX)
Программные интерфейсы
Интерфейсы оборудования
Интерфейсы связи и коммуникации
Шаблони специфікації вимог до ПЗ