Виробництво вимог етап процесу розробки програмного забезпечення Специфікації вимог до програмного забезпечення (SRS) (також називається a документ вимог ). Цей звіт закладає основу для діяльності з розробки програмного забезпечення та створюється, коли виявляються й аналізуються всі вимоги. SRS це офіційний звіт, який діє як представлення програмного забезпечення, що дозволяє клієнтам перевірити, чи воно (SRS) відповідає їхнім вимогам. Крім того, він містить вимоги користувача до системи, а також детальні специфікації системних вимог.
SRS — це специфікація для конкретного програмного продукту, програми або набору програм, які виконують певні функції в певному середовищі. Він переслідує кілька цілей залежно від того, хто його пише. По-перше, SRS може бути написаний клієнтом системи. По-друге, ЄСВ міг бути написаний розробником системи. Ці два методи створюють абсолютно різні ситуації та встановлюють абсолютно різні цілі для документа. Перший випадок, SRS, використовується для визначення потреб і очікувань користувачів. Другий випадок, СГД, пишеться для різних цілей і служить договірним документом між замовником і забудовником.
Характеристики справної SRS
Хороший документ ЄСВ має такі особливості:
1. Правильність: Огляд користувача використовується для забезпечення точності вимог, викладених у ЄСВ. SRS вважається ідеальною, якщо вона покриває всі потреби, які дійсно очікуються від системи.
2. Повнота: ЄСВ є повним тоді і тільки тоді, коли він містить такі елементи:
(1). Усі основні вимоги, пов’язані з функціональністю, продуктивністю, дизайном, обмеженнями, атрибутами чи зовнішніми інтерфейсами.
машинопис дата час
(2). Визначення відповідей програмного забезпечення на всі реалізовані класи вхідних даних у всіх доступних категоріях ситуацій.
Примітка. Важливо вказати відповіді як на дійсні, так і на недійсні значення.
(3). Повні позначки та посилання на всі малюнки, таблиці та діаграми в ЄСВ та визначення всіх термінів та одиниць вимірювання.
3. Консистенція: SRS є узгодженим тоді і тільки тоді, коли немає підмножини окремих вимог, описаних у його конфлікті. Існує три типи можливих конфліктів у СГД:
(1). Зазначені характеристики об'єктів реального світу можуть конфліктувати. Наприклад,
(a) Формат вихідного звіту може бути описаний в одній вимозі як табличний, а в іншій як текстовий.
(b) Одна умова може вказувати, що всі вогні мають бути зеленими, а інша вказує, що всі вогні мають бути синіми.
(2). Між двома вказаними діями може існувати розумний або тимчасовий конфлікт. Наприклад,
(a) Одна вимога може визначити, що програма додасть два входи, а інша може визначити, що програма їх помножить.
(b) Одна умова може стверджувати, що «A» завжди має слідувати за «B», тоді як інша вимагає, щоб «A і B» зустрічалися одночасно.
(3). Дві або більше вимоги можуть визначати той самий об’єкт реального світу, але використовувати різні терміни для цього об’єкта. Наприклад, запит програми на введення користувача може називатися «підказкою» в одній вимозі та «підказкою» в іншій. Використання стандартної термінології та описів сприяє послідовності.
4. Однозначність: ЄСВ є однозначним, коли кожна фіксована вимога має лише одне тлумачення. Це означає, що кожен елемент унікально інтерпретується. Якщо метод використовується з декількома визначеннями, звіт про вимоги має визначати наслідки в SRS, щоб він був зрозумілим і простим для розуміння.
абстракція в java
5. Рейтинг за важливістю та стабільністю: SRS оцінюється за важливістю та стабільністю, якщо кожна вимога в ньому має ідентифікатор, який вказує або на значимість, або на стабільність цієї конкретної вимоги.
Як правило, не всі вимоги однаково важливі. Деякі передумови можуть бути важливими, особливо для життєво важливих додатків, а інші можуть бути бажаними. Кожен елемент має бути визначений, щоб зробити ці відмінності чіткими та чіткими. Інший спосіб ранжування вимог полягає в тому, щоб розрізняти класи предметів як основні, умовні та необов'язкові.
6. Модифікованість: SRS має бути максимально модифікованим і має бути здатним до певної міри швидко отримувати зміни в системі. Зміни повинні бути ідеально проіндексовані та мати перехресні посилання.
7. Перевіряемість: SRS є правильним, якщо вказані вимоги можна перевірити за допомогою економічно ефективної системи, щоб перевірити, чи остаточне програмне забезпечення відповідає цим вимогам. Вимоги перевіряються за допомогою рецензій.
8. Простежуваність: SRS можна відстежити, якщо походження кожної з вимог є зрозумілим і якщо це полегшує посилання на кожну умову в майбутній розробці або вдосконаленні документації.
Існує два типи відстеження:
1. Зворотне відстеження: Це залежить від того, чи кожна вимога містить пряме посилання на джерело в попередніх документах.
2. Простежуваність: Це залежить від того, чи кожен елемент у SRS має унікальне ім’я або контрольний номер.
Попереднє відстеження SRS є особливо важливим, коли програмний продукт переходить у фазу експлуатації та обслуговування. Оскільки код і проектний документ змінюються, необхідно мати можливість визначити повний набір вимог, яких можуть стосуватися ці зміни.
9. Незалежність дизайну: Повинна бути можливість вибору з кількох варіантів дизайну для кінцевої системи. Зокрема, SRS не має містити жодних деталей щодо реалізації.
10. Тестування: SRS має бути написаний таким методом, щоб було легко генерувати тестові випадки та плани тестування зі звіту.
11. Зрозумілі замовнику: Кінцевий користувач може бути експертом у своїй конкретній області, але може не бути навченим у сфері інформатики. Отже, призначення формальних позначень і символів також слід уникати настільки, наскільки це можливо. Мова повинна бути простою і зрозумілою.
12. Правильний рівень абстракції: Якщо SRS написаний для етапу вимог, деталі повинні бути пояснені чітко. Тоді як для техніко-економічного обґрунтування можна використати менше аналізів. Отже, рівень абстракції змінюється відповідно до мети SRS.
Властивості хорошого документа ЄСВ
Основними властивостями якісного документа ЄСВ є:
Коротко: Звіт з ЄСВ має бути стислим і водночас однозначним, послідовним і повним. Багатослівні та нерелевантні описи зменшують читабельність, а також збільшують ймовірність помилок.
Структуровано: Він повинен бути добре структурованим. Добре структурований документ легко зрозуміти та змінити. На практиці документ ЄСВ зазнає кількох переглядів, щоб відповідати вимогам користувачів. Часто вимоги користувачів змінюються протягом певного періоду часу. Тому, щоб легко було вносити зміни до документа ЄСВ, важливо зробити звіт добре структурованим.
Вид чорної скриньки: Він має лише визначати, що має робити система, і утримуватися від вказівок, як це робити. Це означає, що документ SRS повинен визначати зовнішню поведінку системи, а не обговорювати питання впровадження. Звіт SRS повинен розглядати систему, що розробляється, як чорний ящик і повинен визначати зовнішню видиму поведінку системи. З цієї причини звіт SRS також відомий як специфікація системи чорної скриньки.
Концептуальна цілісність: Він повинен демонструвати концептуальну цілісність, щоб читач міг його просто зрозуміти. Реакція на небажані події: має характеризувати прийнятні реакції на небажані події. Це називається реакцією системи на виняткові умови.
зразок javascript
Піддається перевірці: Усі вимоги системи, задокументовані в документі ЄСВ, мають бути правильними. Це означає, що має бути можливість вирішити, чи були виконані вимоги під час впровадження.