Специфікація вимог до програмного забезпечення є одним з найважливіших документів при розробці програмного забезпечення. Вам може бути цікаво, що таке специфікація вимог до програмного забезпечення. SRS описує роботу програмного забезпечення, його функції та навантаження. Специфікація вимог до програмного забезпечення описує функціональні та нефункціональні вимоги. Часто документ включає варіанти використання, які ілюструють, як користувач буде взаємодіяти з системою.
Що таке специфікація вимог до програмного забезпечення?
Специфікація вимог до програмного забезпечення (SRS) - це опис програмної системи, яку потрібно розробити. Вона моделюється за зразком специфікації бізнес-вимог. Специфікація вимог до програмного забезпечення встановлює функціональні та нефункціональні вимоги і може включати набір варіантів використання, які описують взаємодію з користувачем, яку програмне забезпечення повинно надавати користувачеві для ідеального користувацького досвіду.
Документ на програмне забезпечення створює основу для угоди між замовниками та підрядниками або постачальниками про те, як повинен функціонувати програмний продукт (у ринково орієнтованому проекті ці ролі можуть відігравати відділи маркетингу та розробки). Специфікація вимог до програмного забезпечення - це сувора оцінка вимог перед більш конкретними кроками проектування системи, і її мета - зменшити кількість наступних ітерацій. Вона також повинна забезпечити реалістичну основу для оцінки вартості продукту, ризиків і графіків. При правильному використанні специфікації вимог до програмного забезпечення можуть допомогти запобігти провалу програмного проекту.
Іванна
Менеджер по роботі з клієнтами
Зв'яжіться з нами, і ми охоче розповімо про наші кейси у цій ніші
Безкоштовна консультаціяДокумент специфікації вимог до програмного забезпечення містить перелік вимог, достатніх для розробки проекту. Щоб вивести вимоги, розробник повинен мати чітке і повне розуміння продуктів, що розробляються. Це досягається шляхом детальної та безперервної взаємодії з проектною командою та замовником протягом усього процесу розробки програмного забезпечення.
Документ S R S може бути одним з описів елементів даних контракту або мати іншу форму, визначену організацією.
Зазвичай SRS пише технічний письменник, системний архітектор або програміст.
Навіщо використовувати SRS-документ?
Наявність чіткого набору вимог гарантує, що команда розробників створить програмне забезпечення, яке відповідає потребам клієнта. SRS допоможе оцінити вартість роботи і охопити обсяг проекту. Він також дає програмістам уявлення про стек технологій, які їм знадобляться, і допомагає їм планувати свою роботу.
Але це ще не все:
- Дизайнери отримують уявлення про дизайн за допомогою SRS-документів, щоб вони могли адаптувати дизайн до варіанту використання.
- Тестувальники отримують рекомендації щодо створення тестових кейсів, які відповідають потребам бізнесу.
- За допомогою SRS ви можете створити чітку презентацію для інвесторів.
- SRS також важливе тому, що це єдине джерело інформації, яке запобігає непорозумінням як між менеджером проекту та командою, так і між замовником та аутсорсинговою компанією.
Специфікація вимог до програмного забезпечення проти специфікації системних вимог
У складних проектах прийнято відокремлювати специфікацію системних вимог від вимог до програмного забезпечення. Хоча терміни "Специфікація вимог до програмного забезпечення" і "Специфікація системних вимог" іноді використовуються як взаємозамінні під абревіатурою SRS, ці два поняття не є синонімами. Специфікація вимог до програмного забезпечення набагато ширша за обсягом, ніж специфікація системних вимог.
Специфікація вимог до програмного забезпечення (SRS) містить детальний опис програмної системи, яку потрібно розробити. Специфікація вимог до програмного забезпечення - це детальний огляд вимог, необхідних для створення програмного забезпечення.
Специфікація системних вимог (SyRS) містить детальну інформацію про вимоги до системи. Вона фокусується на тому, що повинно робити програмне забезпечення і як воно повинно працювати.
IEEE 1233 стандарт є одним з визнаних керівництв для розробки системних вимог. І, як зазначалося раніше, не забувайте, що поняття системи, в загальному випадку, охоплює програмне забезпечення, обладнання та людей. Системна інженерія, в свою чергу, є самостійною і не менш об'ємною дисципліною, ніж програмна інженерія.
Функціональні та нефункціональні вимоги
Функціональна вимога - це опис того, як повинна поводитися система. Вона визначає, що система повинна робити, щоб задовольнити потреби або очікування користувача. Функціональні вимоги можна розглядати як можливості, які відкриває користувач. Вони відрізняються від нефункціональних вимог, які визначають, як система повинна працювати внутрішньо (наприклад, продуктивність, безпека тощо).
Функціональні вимоги
Функціональні вимоги складаються з двох частин: функції та поведінки. Функція - це те, що робить система (наприклад, "розрахувати податок з продажів"). Поведінка визначається тим, як система це робить (наприклад, "система повинна розраховувати податок з продажу шляхом множення ціни покупки на ставку податку").
Типи функціональних вимог
Ось найпоширеніші типи функціональних вимог:
- Бізнес-правила
- Вимоги до сертифікації
- Вимоги до звітності
- Адміністративні функції
- Рівні авторизації
- Відстеження аудиту
- Зовнішні інтерфейси
- Управління даними
- Законодавчі та регуляторні вимоги
Нефункціональні (NFR) вимоги
Нефункціональні вимоги пояснюють обмеження та недоліки системи, що розробляється. Ці вимоги жодним чином не впливають на функціональність програми. Крім того, загальноприйнятою практикою є поділ нефункціональних вимог на різні категорії, наприклад
- Інтерфейс користувача
- Надійність
- Безпека
- Продуктивність
- Сервіс
- Стандарт
- Підкласифікація нефункціональних вимог є хорошою практикою. Це допомагає створити контрольний список вимог, які повинні бути включені в розроблювану систему.
Структура документа SRS
Нижче ви можете знайти приклад документу специфікації вимог до програмного забезпечення
1. Вступ
У цьому розділі документу вимог до програмного забезпечення ми описуємо додаток або продукт, функціональність якого буде описана в SRS.
Тут ми описуємо всі незрозумілі слова або терміни технічної специфікації, які можуть зустрічатися в СДЗ. Зверніть увагу, що опис слова не може містити іншого незрозумілого слова. Намагайтеся якомога детальніше описати термін, який ви використовуєте, простою і зрозумілою мовою. Не економте на цьому розділі, тому що чим більше ви запишете, тим легше буде розробляти пізніше.
2. Загальний опис
У цьому розділі документу з вимогами до програмного забезпечення ми описуємо частини функціональності на високому рівні. Кожна частина функціональності буде описана більш детально у відповідному розділі нижче. Тут бажано розмістити DFD діаграму, яка покаже загальну взаємодію системи.
Тут також описується середовище, в якому буде працювати продукт. ОС, версії компіляторів, бази даних, сервери, програмне забезпечення, обладнання та інші речі, які необхідні для роботи вашого продукту.
Опис з обмеженнями. Такими обмеженнями можуть бути, наприклад, такі речі:
- Мова програмування, база даних
- Стандарти кодування
- Комунікаційні стандарти
- Обмеження, які можуть бути накладені бізнес-логікою проекту
Тут ви описуєте документацію, необхідну для користувачів цього продукту. Можливо, це може бути книга про HTML, якщо це HTML-редактор.
3. Системні функції та вимоги
Ми називаємо функцію для проекту і даємо їй унікальний ідентифікатор. Наприклад, server.html.editor.
Системні можливості\Системна можливість X\Опис і пріоритет Ми детально описуємо можливості продукту. Для чого вона потрібна? Що я повинен робити? Який пріоритет її виконання? З цього розділу людина, яка читає CRS, повинна відразу зрозуміти, для чого ця функціональність присутня в системі.
Функції системи\Функція X\Послідовності стимулів/відповідей Функція запуску тригера. Коли вона запускається і як вона поводиться після запуску? Наприклад, редактор HTML показується, коли користувач натискає на посилання меню Відкрити редактор HTML
Функції системи\Функція X\Функціональні вимоги Детальний і докладний опис функції. Ми описуємо все: як вона працює, як реагує на помилки, що має перевіряти, як відображати дані, як і куди зберігає і т.д.
4. Вимоги до зовнішнього інтерфейсу
Опис того, як система буде взаємодіяти із зовнішнім світом. Які API, як отримувати ті чи інші дані тощо? Підрозділи слугують для деталізації вимог. Які програмні інтерфейси, "апаратні" інтерфейси, комунікаційні інтерфейси тощо?
Нефункціональні вимоги
Не функціональні вимоги. Деякі вимоги не можуть бути описані як певна функція, наприклад, вимоги безпеки.
Нефункціональні вимоги\Вимоги до продуктивності Вимоги до продуктивності. Це не функція, але вона накладає певні обмеження. Скажімо, база даних проекту повинна витримувати 1000 запитів в секунду і так далі. Ці вимоги призводять до величезної роботи над оптимізацією проекту.
Нефункціональні вимоги\Атрибути якості програмного забезпечення Тут ми описуємо вимоги до якості коду. Які тести використовувати? Які метрики використовувати для визначення якості коду?
Нефункціональні вимоги\Вимоги до безпеки Вимоги до безпеки. Якщо це HTML-редактор, через який можна щось змінювати на сайті, то це може бути щось на кшталт: через HTML-редактор не повинно бути можливості поставити оболонку на сервер і т.д.
5. Попередній розклад і бюджет
Попередній графік: Розділ включає в себе початковий етап плану проекту, включаючи завдання, які необхідно виконати, їх взаємозалежності та дати початку/завершення. Попередній бюджет: Розділ містить початковий бюджет проекту, поділений на коефіцієнт вартості.
Як писати вимоги до програмного забезпечення
Як правило, замовники та розробники розмовляють різними мовами. Клієнт представляє зовнішню поведінку системи: що вона буде робити і як кінцеві користувачі будуть з нею працювати. Програмісти, з іншого боку, думають про продукт з точки зору його внутрішніх характеристик.
Бізнес-аналітик допомагає їм зрозуміти один одного, він перетворює потреби клієнта у вимоги, а вимоги - у завдання для розробників. Спочатку це робиться за допомогою написання вимог до програмного забезпечення (SRS). Нижче наведено шаблонну специфікацію вимог.
1. Створіть план на основі ваших цілей
Перший крок включає в себе створення плану специфікації вимог до програмного забезпечення. Ви можете створити його самостійно або просто скористатися онлайн-шаблоном SRS.
2. Визначте мету вашого продукту
Цей розділ має вирішальне значення, оскільки він встановлює очікування, які ми будемо реалізовувати протягом усього SRS.
Цільова аудиторія та цільове використання
Визначте осіб, які матимуть доступ до СДЗ, і як вони повинні її використовувати. Сюди входять розробники, тестувальники та менеджери проектів, а також зацікавлені особи з інших відділів, включаючи відділ продажів і маркетинг.
- Сфера застосування продукту
- переваги
- завдання
- цілі
Це має бути пов'язано з бізнес-цілями.
Визначення та абревіатури
Ви повинні визначити ризики проекту в SRS в інженерії програмного забезпечення. Що може піти не так? Як я можу з цим впоратися? Хто відповідає за елементи ризику?
Наприклад, якщо несправність медичного пристрою може спричинити травму, це один рівень ризику. Знаючи рівень виникнення та серйозність, ми можемо створити стратегію для мінімізації цього ризику.
3. Опишіть свій продукт
Наступним кроком є опис продукту. Це новий тип продукту? Чи це розширення продукту, який ви вже створили? Чи буде він інтегрований з іншим продуктом? Для кого він призначений?
Приклади вимог користувачів
Опишіть вашу цільову аудиторію. Розуміння того, хто є вашими користувачами і які їхні потреби, є важливою частиною процесу.
Припущення та залежності
Які припущення будуть вірними? Чи беремо ми реальну технологію? Чи основою є фреймворк Windows? Вам потрібно зробити припущення, щоб краще зрозуміти, коли ваш продукт вийде з ладу або працюватиме не бездоганно.
Ви також повинні відзначити, чи залежить ваш проект від інших факторів. Наприклад, чи берете ви частину програмного забезпечення з існуючого проекту?
4. Деталізуйте свої специфічні вимоги
Якщо ви хочете, щоб ваша команда розробників правильно виконала вимоги, ви повинні включити всі можливі деталі.
Функціональні вимоги
Функціональні вимоги мають вирішальне значення для вашого продукту, оскільки вони забезпечують його функціональність.
Ви також можете вказати, як ваше програмне забезпечення може взаємодіяти з іншими інструментами, що пов'язано з вимогами до зовнішнього інтерфейсу.
Вимоги до зовнішнього інтерфейсу
Вимоги до зовнішнього інтерфейсу є різновидом функціональних вимог. Вони важливі, коли ви працюєте з вбудованими системами. Вони описують, як ваш продукт буде взаємодіяти з іншими компонентами.
Типи інтерфейсів:
- Користувацький
- Апаратний
- Програмне забезпечення
- Комунікації
Нефункціональні вимоги так само важливі, як і функціональні.
Включають
- Продуктивність
- Безпека
- Якість
5. Подання на затвердження
"Навіщо мені потрібен технічний письменник, якщо є розробник продукту, який може легко створити документацію для нього?" - це питання часто задають керівники програмних продуктів. Ті з них, хто в ході міркувань приходить до висновку, що технічний письменник в компанії не потрібен і з усіма завданнями по документації впораються розробники, помиляються.
Написання технічних матеріалів, таких як посібники користувача програмного забезпечення або звіти про дослідження, вимагає певного набору навичок. Вивчення теорії та осмислення практичного досвіду, пов'язаного з професією технічного письменника, вимагає часу. Наймаючи досвідченого технічного письменника, ви отримуєте наступні переваги:
- Чіткіші комунікації
- Зниження витрат на технічну підтримку
- Зменшення витрат на документацію
- Основна робота технічного письменника - написання вимог до програмного забезпечення
Як SRS залежить від підходу до управління проектом
Незалежно від того, чи це розробка нового програмного забезпечення, чи проведення маркетингової кампанії, чи написання SRS, управління проектами дає можливість досягти успіху.
Waterfall
Найочевидніший спосіб зробити проект більш керованим - розбити його на послідовні етапи. Саме на такій лінійній структурі базується традиційний проектний менеджмент - водоспад. У цьому сенсі воно нагадує комп'ютерну гру - ви не можете перейти на наступний рівень, не завершивши попередній.
Agile
Гнучкий ітеративно-інкрементальний підхід до управління проектами та продуктами, орієнтований на динамічне формування вимог і забезпечення їх виконання в результаті постійної взаємодії в рамках робочих груп, що самоорганізуються і складаються з фахівців різних галузей. Існує багато методів, заснованих на ідеях Agile, найпопулярнішим з яких є Scrum.
Scrum
Скрам поєднує в собі елементи класичного процесу з ідеями гнучкого підходу до управління проектами. Результат - поєднання гнучкості та структурованості.
Дотримуючись заповідей Agile, Скрам розбиває проект на частини, які можуть бути негайно використані Замовником для отримання цінності, що називається продуктовим беклогом. Щоб переконатися, що проект відповідає вимогам замовника, які мають тенденцію змінюватися з часом, перед початком кожного спринту ще не завершений обсяг проекту переоцінюється і в нього вносяться зміни. У цьому процесі беруть участь усі - команда проекту, скрам-майстер і власник продукту. І кожен несе відповідальність за цей процес.
Висновок
Кожен, хто працював над програмним проектом, знає, як швидко можуть накопичуватися вимоги і як важко ними керувати. Специфікація вимог до програмного забезпечення надає вичерпний опис програмного продукту, що розробляється, і тримає всіх учасників на одній сторінці. Завдяки сучасним інструментам управління вимогами, написання специфікації вимог до програмного забезпечення - це простіше простого, а її переваги неможливо ігнорувати.
SRS зазвичай підписується наприкінці етапу розробки вимог, самого раннього етапу в процесі розробки програмного забезпечення. Якщо ви хочете розпочати проект, просто напишіть нам, ми надамо вам безкоштовну консультацію.
