Вимоги (Requirements)
Вимога (requirement): Умови або можливості, необхідні користувачеві для вирішення певних завдань або досягнення певних цілей, які мають бути досягнуті для виконання контракту, стандартів, специфікації чи інших формальних документів. (IEEE 610)
Специфікація (specification): Документ, що описує (в ідеалі - вичерпно, однозначно та доступно) вимоги, дизайн, поведінка чи інші характеристики компонента чи системи. Найчастіше до специфікації включаються процедури контролю виконання. (ISTQB)
Специфікація компонента (component specification): Опис функцій компонента у термінах його вихідних значень для заданих вхідних значень за певних умов, а також необхідної нефункціональної поведінки (наприклад, використання ресурсів). (ISTQB)
Специфікація проектування тесту (test design specification): Документ, що описує тестову умову (елементи покриття) для елемента тестування, деталізований підхід до тестування та ідентифікує відповідні тестові сценарії високого рівня. (IEEE 829)
Специфікація процедури тестування (test procedure specification): Документ, що описує послідовність дій під час виконання тесту. Також відомий як ручний сценарій тестування. (IEEE 829)
Специфікація тесту (test specification): Документ, що складається зі специфікації проектування тесту, специфікації тестових сценаріїв та/або специфікації процедури тестування.
Специфікація тестових сценаріїв (test case specification): Документ, що описує комплект тестових сценаріїв - ціль, входи, тестові операції, очікувані результати та передумови виконання об'єкта тестування. (IEEE 829)
Вимоги є відправною точкою визначення того, що проектна команда буде проектувати, реалізовувати і тестувати. Незалежно від того, яка модель розробки ПЗ використовується на проекті, чим пізніше буде виявлено проблему, тим складнішим і дорожчим буде її вирішення. Якщо проблема в вимогах буде з'ясована на початковій стадії, її вирішення може звестися до виправлення кількох слів у тексті, тоді як недоробка, викликана пропущеною проблемою в вимогах і виявлена на стадії експлуатації, може навіть повністю знищити проект.
Джерела та шляхи виявлення вимог
Вимоги розпочинають своє життя на стороні замовника. Їх збирання (gathering) та виявлення (elicitation) здійснюються за допомогою наступних основних технік:
Інтерв'ю . Найуніверсальніший шлях виявлення вимог, що полягає у спілкуванні проектного спеціаліста (як правило, бізнес-аналітика) та представника замовника (або експерта, користувача тощо). Інтерв'ю може відбуватися у класичному розумінні цього слова (розмова у вигляді «питання відповідь»), у вигляді листування тощо. Головним тут є те, що ключовими фігурами виступають двоє – інтерв'юйований та інтерв'юер (хоча це і не виключає наявності «аудиторії слухачів», наприклад, у вигляді осіб, поставлених у копію листування).
Робота з фокусними групами . Може виступати як варіант «розширеного інтерв'ю», де джерелом інформації є не одна особа, а група осіб (як правило, що представляють цільову аудиторію, та/або мають важливу для проекту інформацію, та/або уповноважених приймати важливі для проекту рішення).
Анкетування . Цей варіант виявлення вимог викликає багато суперечок, т.к. за неправильної реалізації може призвести до нульового результату при об'ємних витратах. У той же час при правильній організації анкетування дозволяє автоматично зібрати та обробити величезну кількість відповідей від величезної кількості респондентів. Ключовим фактором успіху є правильне складання анкети, правильний вибір аудиторії та правильне піднесення анкети.
Семінари та мозковий штурм . Семінари дозволяють групі людей дуже швидко обмінятися інформацією (і наочно продемонструвати ті чи інші ідеї), а також добре поєднуються з інтерв'ю, анкетуванням, прототипуванням та моделюванням – у тому числі для обговорення результатів та формування висновків та рішень. Мозковий штурм може проводитись і як частина семінару, і як окремий вид діяльності. Він дозволяє за мінімальний час згенерувати велику кількість ідей, які надалі можна поспішаючи розглянути з точки зору їх використання для розвитку проекту.
Спостереження . Може виражатися як у буквальному спостереженні за деякими процесами, так і у включенні проектного фахівця в ці процеси як учасник. З одного боку, спостереження дозволяє побачити те, про що (з різних міркувань) можуть замовчати інтерв'ювані, анкетовані і представники фокусних груп, але з іншого - забирає дуже багато часу і найчастіше дозволяє побачити лише частину процесів.
Прототипування . Складається в демонстрації та обговоренні проміжних версій продукту (наприклад, дизайн сторінок сайту може бути спочатку представлений у вигляді картинок, а потім зверстаний). Це один з кращих шляхів пошуку єдиного розуміння та уточнення вимог, однак він може призвести до серйозних додаткових витрат за відсутності спеціальних інструментів (що дозволяють швидко створювати прототипи) та надто ранньому застосуванні (коли вимоги ще не стабільні, і висока ймовірність створення прототипу, що має мало спільного про те, що хотів замовник).
Аналіз документів . Добре працює тоді, коли експерти в предметній галузі (тимчасово) недоступні, а також у предметних галузях, що мають загальноприйняту регламентуючу документацію. Також до цієї техніки відноситься і просто вивчення документів, що регламентують бізнес-процеси в предметній галузі замовника або в конкретній організації, що дозволяє придбати необхідні для кращого розуміння проекту знання.
Моделювання процесів та взаємодій . Може застосовуватися як до «бізнес-процесів та взаємодій» (наприклад: «договір на закупівлю формується відділом закупівель, візується бухгалтерією та юридичним відділом…»), так і до «технічних процесів та взаємодій» (наприклад: «платіжне доручення генерується модулем “Бухгалтерія ”, шифрується модулем “Безпека” та передається на збереження в модуль “Сховище”»). Ця техніка вимагає високої кваліфікації фахівця з бізнес-аналізу, т.к. пов'язана з обробкою великого обсягу складної (і часто погано структурованої) інформації.
Самостійний опис . Є не так технікою виявлення вимог, як технікою їх фіксації та формалізації. Дуже складно (і навіть не можна!) намагатися самому «вигадати вимоги за замовника», але у спокійній обстановці можна самостійно опрацювати зібрану інформацію та акуратно оформити її для подальшого обговорення та уточнення.
Рівні та типи вимог
Бізнес-вимоги (business requirements) виражають мету, заради якої розробляється продукт (навіщо взагалі він потрібен, яка від нього очікується користь, як замовник з його допомогою отримуватиме прибуток). Результатом виявлення вимог цьому рівні є загальне бачення (vision and scope) - документ, який, зазвичай, представлений простим текстом і таблицями. Тут немає деталізації поведінки системи та інших технічних характеристик, але цілком можуть бути визначені пріоритети бізнес-завдань, що вирішуються, ризики і т.п. Декілька простих, ізольованих від контексту та один від одного прикладів бізнес-вимог:
Потрібен інструмент, що в реальному часі відображає найбільш вигідний курс купівлі та продажу валюти;
Необхідно вдвічі-втричі підвищити кількість заявок, що обробляються одним оператором за зміну;
Потрібно автоматизувати процес виписки товарно-транспортних накладних з урахуванням договорів.
Користувацькі вимоги (user requirements) описують завдання, які користувач може виконувати за допомогою системи, що розробляється (реакцію системи на дії користувача, сценарії роботи користувача). Оскільки тут з'являється опис поведінки системи, вимоги цього рівня можуть бути використані для оцінки обсягу робіт, вартості проекту, часу розробки і т.д. Користувацькі вимоги оформляються у вигляді варіантів використання (use cases), історій користувача (user stories), користувальницьких сценаріїв (user scenarios). Декілька простих, ізольованих від контексту та один від одного прикладів користувальницьких вимог:
При першому вході користувача до системи має відображатись ліцензійна угода;
Адміністратор повинен мати можливість переглядати список усіх користувачів, які працюють на даний момент у системі;
При першому збереженні нової статті, система повинна видавати запит на збереження у вигляді чернетки або публікацію.
Бізнес-правила (business rules) описують особливості прийнятих у предметній галузі (і/або безпосередньо у замовника) процесів, обмежень та інших правил. Ці правила можуть належати до бізнес-процесів, правил роботи співробітників, нюансів роботи ПЗ тощо. Декілька простих, ізольованих від контексту та один від одного прикладів бізнес-правил:
Жодний документ, переглянутий відвідувачами сайту хоча б один раз, не може бути відредагований чи видалений;
Публікація статті можлива лише після затвердження головним редактором;
Підключення до системи ззовні офісу заборонено у неробочий час.
Атрибути якості (quality attributes) розширюють собою нефункціональні вимоги і на рівні вимог користувача можуть бути представлені у вигляді опису ключових для проекту показників якості (властивостей продукту, не пов'язаних з функціональністю, але є важливими для досягнення цілей створення продукту - продуктивність, масштабованість, відновлюваність) . Атрибутів якості дуже багато, але для будь-якого проекту реально важливими є лише деяке їхнє підмножина. Декілька простих, ізольованих від контексту та один від одного прикладів атрибутів якості:
Максимальний час готовності системи до виконання нової команди після скасування попередньої не може перевищувати секунди;
Внесені до тексту статті зміни не повинні бути втрачені при порушенні з'єднання між клієнтом та сервером;
Додаток має підтримувати додавання довільної кількості неіероглифічних мов інтерфейсу.
Функціональні вимоги (functional requirements) описують поведінку системи, тобто. її дії (обчислення, перетворення, перевірки, обробку тощо). У контексті проектування функціональні вимоги переважно впливають на дизайн системи. Варто пам'ятати, що до поведінки системи відноситься не тільки те, що система повинна робити, а й те, що вона не повинна робити (наприклад: «додаток не повинен вивантажувати з оперативної пам'яті фонові документи протягом 30 хвилин з моменту виконання з ними останньої операції »). Декілька простих, ізольованих від контексту та один від одного прикладів функціональних вимог:
У процесі інсталяції програма повинна перевіряти залишок вільного місця на цільовому носії;
Система повинна автоматично виконувати резервне копіювання даних щодня у вказаний час;
Електронна адреса користувача, що вводиться під час реєстрації, має бути перевірена на відповідність вимогам RFC822.
Нефункціональні вимоги (non-functional requirements) описують властивості системи (зручність використання, безпека, надійність, розширюваність і т.д.), якими вона повинна мати при реалізації своєї поведінки. Тут наводиться більш технічний та детальний опис атрибутів якості. У контексті проектування дисфункції в основному впливають на архітектуру системи. Декілька простих, ізольованих від контексту та один від одного прикладів нефункціональних вимог:
При одночасної безперервній роботі з системою 1000 користувачів, мінімальний час між виникненням збоїв має бути більшим або рівним 100 годин;
За жодних умов загальний обсяг використовуваної додатком пам'яті не може перевищувати 2 ГБ;
Розмір шрифту для будь-якого напису на екрані повинен підтримувати налаштування в діапазоні від 5 до 15 пунктів.
Наступні вимоги в загальному випадку можуть бути віднесені до нефункціональних, проте їх часто виділяють в окремі підгрупи (тут для простоти розглянуті лише три таких підгрупи, але їх може бути і набагато більше; як правило, вони походять з атрибутів якості, але високий ступінь деталізації дозволяє віднести їх до рівня вимог продукту).
Обмеження (limitations, constraints) є чинники, що обмежують вибір способів і засобів (зокрема інструментів) реалізації продукту. Декілька простих, ізольованих від контексту та один від одного прикладів обмежень:
Всі елементи інтерфейсу повинні відображатися без прокручування при роздільній здатності екрана від 800x600 до 1920x1080;
Не допускається використання Flash під час реалізації клієнтської частини програми;
Програма має зберігати здатність реалізовувати функції з рівнем важливості «критичний» за відсутності у клієнта підтримки JavaScript.
Вимоги до інтерфейсів (external interfaces requirements) описують особливості взаємодії системи, що розробляється, з іншими системами та операційним середовищем. Декілька простих, ізольованих від контексту та один від одного прикладів вимог до інтерфейсів:
Обмін даними між клієнтською та серверною частинами програми при здійсненні фонових AJAX-запитів має бути реалізований у форматі JSON;
Протоколування подій має вестись у журналі подій операційної системи;
З'єднання з поштовим сервером має виконуватися згідно RFC3207 (SMTP over TLS).
Вимоги до даних (data requirements) описують структури даних (і самі дані), які є невід'ємною частиною системи, що розробляється. Часто сюди відносять опис бази даних та особливостей її використання. Декілька простих, ізольованих від контексту та один від одного прикладів вимог до даних:
Всі дані системи, за винятком документів користувача, повинні зберігатися в БД під управлінням СУБД MySQL, користувальницькі документи повинні зберігатися в БД під управлінням СУБД MongoDB;
Інформація про касові транзакції за поточний місяць повинна зберігатись в операційній таблиці, а після закінчення місяця переноситись до архівної;
Для прискорення операцій пошуку за текстом статей та оглядів мають бути передбачені повнотекстові індекси на відповідних полях таблиць.
Властивості якісних вимог (вимоги до самих вимог)
Завершеність (completeness). Вимога є повною і закінченою з погляду подання у ньому всієї необхідної інформації, ніщо не пропущено з міркувань «це і так всім зрозуміло». Типові проблеми із завершеністю:
Відсутні нефункціональні складові вимоги чи посилання відповідні нефункціональні вимоги (наприклад: «паролі повинні зберігатися у зашифрованому вигляді» - який алгоритм шифрування?);
Вказано лише частину деякого перерахування (наприклад: «експорт здійснюється у формати PDF, PNG тощо» - що ми повинні розуміти під «і т.д.»?);
Наведені посилання є неоднозначними (наприклад: «див. вище» замість «див. розділ 123.45.b»).
Атомарність, поодинокість (atomicity). Вимога є атомарною, якщо її не можна розбити на окремі вимоги без втрати завершеності і вона описує одну і лише одну ситуацію. Типові проблеми з атомарністю:
В одній вимогі фактично міститься кілька незалежних (наприклад: «кнопка “Restart” не повинна відображатися при зупиненому сервісі, вікно “Log” має вміщувати не менше 20-ти записів про останні дії користувача» - тут навіщось в одній пропозиції описані абсолютно різні елементи інтерфейсу в різних контекстах);
Вимога допускає різночитання в силу граматичних особливостей мови (наприклад: «якщо користувач підтверджує замовлення та редагує замовлення або відкладає замовлення, повинен видаватися запит на оплату» - тут описані три різні випадки, і цю вимогу варто розбити на три окремі, щоб уникнути плутанини). Таке порушення атомарності часто тягне у себе виникнення суперечливості;
В одній вимогі об'єднано опис кількох незалежних ситуацій (наприклад: «коли користувач входить до системи, йому має відображатися привітання; коли користувач увійшов до системи, має відображатися ім'я користувача; коли користувач виходить із системи, має відображатися прощання» - всі ці три ситуації заслуговують того, щоб бути описаними окремими і більш детальними вимогами).
Несуперечність, послідовність (consistency). Вимога не повинна містити внутрішніх протиріч та протиріч іншим вимогам та документам. Типові проблеми з несуперечністю:
Суперечності всередині однієї вимоги (наприклад: «після успішного входу в систему користувача, що не має права входити в систему…» - тоді як він успішно увійшов до системи, якщо не мав такого права?);
Суперечності між двома і більше вимогами, між таблицею та текстом, малюнком та текстом, вимогою та прототипом тощо. (наприклад: «712.a Кнопка “Close” завжди має бути червоною» та «36452.x Кнопка “Close” завжди повинна бути синьою» - так все ж таки червоною чи синьою?);
Використання невірної термінології або використання різних термінів для позначення одного і того ж об'єкта або явища (наприклад: «у разі, якщо роздільна здатність вікна становить менше 800x600…» - роздільна здатність є у екрана, у вікна є розмір).
Недвозначність (unambiguousness, clearness). Вимога повинна бути описана без використання жаргону, неочевидних абревіатур та розпливчастих формулювань, повинна допускати лише однозначне об'єктивне розуміння та бути атомарною в плані неможливості різного трактування поєднання окремих фраз. Типові проблеми з недвозначністю:
оптимізувати (optimize), швидко (rapid), зручно (user-friendly), просто (simple), часто (often), зазвичай (usual), великий (large), гнучкий (flexible), стійкий (robust), за останнім словом техніки (state-of-the-art), покращений (improved), результативно (efficient). Ось перебільшений приклад вимоги, що звучить дуже красиво, але абсолютно нереалізованого і незрозумілого: «У разі необхідності оптимізації передачі великих файлів система повинна ефективно використовувати мінімум оперативної пам'яті, якщо це можливо»;
Використання неочевидних або двозначних абревіатур без розшифровки (наприклад: «доступ до ФС здійснюється за допомогою системи прозорого шифрування» та «ФС надає можливість фіксувати повідомлення в їх поточному стані зі збереженням історії всіх змін» - ФС тут позначає файлову систему? Точно? А не який- або «Фіксатор Повідомлень»?);
Формулювання вимог з міркувань, що щось має бути всім очевидно (наприклад: «Система конвертує вхідний файл із формату PDF у вихідний файл формату PNG» - і при цьому автор вважає цілком очевидним, що імена файлів система отримує з командного рядка, а багатосторінковий PDF конвертується кілька PNG-файлів, до імен яких додається «page-1», «page-2» і т.д.). Ця проблема перегукується із порушенням коректності.
Виконаність ( feasibility ). Вимога має бути технологічно здійсненною та реалізованою в рамках бюджету та термінів розробки проекту. Типові проблеми з здійсненністю:
Так зване «озолочення» (gold plating) – вимоги, які вкрай довго та/або дорого реалізуються і при цьому практично не приносять користі кінцевим користувачам (наприклад: «налаштування параметрів для підключення до бази даних має підтримувати розпізнавання символів з жестів, отриманих з пристроїв тривимірного»). введення»).
Технічно нереалізовані на сучасному рівні розвитку технологій вимоги (наприклад: «аналіз договорів повинен виконуватися із застосуванням штучного інтелекту, який виноситиме однозначний коректний висновок про ступінь вигоди від укладання договору»).
У принципі вимоги, що не реалізуються (наприклад: «система пошуку повинна заздалегідь передбачати всі можливі варіанти пошукових запитів і кешувати їх результати»).
Обов'язковість, потреба (obligatoriness) та актуальність (up-to-date). Якщо вимога не є обов'язковою для реалізації, вона повинна бути просто виключена з набору вимог. Якщо вимога потрібна, але «не дуже важлива», для вказівки цього факту використовується вказівка пріоритету (див. проранжованість по ...). Також виключені (або перероблені) мають бути вимоги, що втратили актуальність. Типові проблеми з обов'язковістю та актуальністю:
Вимога була додана «про всяк випадок», хоча реальної потреби у ньому був і немає;
Вимоги виставлено неправильні значення пріоритету за критеріями важливості та/або терміновості;
Вимога застаріла, але не була перероблена чи видалена.
Простежуваність (traceability). Простежуваність буває вертикальною (vertical traceability) та горизонтальною (horizontal traceability). Вертикальна дозволяє співвідносити між собою вимоги різних рівнях вимог, горизонтальна дозволяє співвідносити вимогу з тест-планом, тест-кейсами, архітектурними рішеннями тощо. Для забезпечення простежуваності часто використовуються спеціальні інструменти управління вимогами (requirements management tool) та/або матриці простежуваності (traceability matrix). Типові проблеми із простежуваністю:
Вимоги не пронумеровані, не структуровані, немає змісту, немає працюючих перехресних посилань;
p align="justify"> При розробці вимог не були використані інструменти та техніки управління вимогами;
Набір вимог неповний, носить уривчастий характер із явними «пробілами».
Модифікованість (modifiability). Ця властивість характеризує простоту внесення змін до окремих вимог і набір вимог. Можна говорити про наявність модифікованості в тому випадку, якщо при доопрацюванні вимог потрібну інформацію легко знайти, а її зміна не призводить до порушення інших описаних у цьому переліку властивостей. Типові проблеми з модифікованістю:
Вимоги неатомарні (див. «атомарність») і непростежувані (див. «простежуваність»), тому їх зміна з високою ймовірністю породжує суперечливість (див. «несуперечність»);
Вимоги спочатку суперечливі (див. «Несуперечність»). У такій ситуації внесення змін (не пов'язаних із усуненням суперечливості) лише посилює ситуацію, збільшуючи суперечливість та знижуючи простежуваність;
Вимоги представлені у незручній для обробки формі (наприклад, не використані інструменти управління вимогами, і в результаті команді доводиться працювати з десятками великих текстових документів).
Проранжованість за важливістю, стабільністю, терміновістю (ranked for importance, stability, priority). p align="justify"> Важливість характеризує залежність успіху проекту від успіху реалізації вимоги. Стабільність характеризує ймовірність того, що в найближчому майбутньому в вимогу не буде внесено жодних змін. Терміновість визначає розподіл у часі зусиль проектної команди щодо реалізації тієї чи іншої вимоги. Типові проблеми з проранжованістю полягають у її відсутності чи неправильній реалізації та призводять до наступних наслідків:
Проблеми з проранжованістю за важливістю підвищують ризик неправильного розподілу зусиль проектної команди, спрямування зусиль на другорядні завдання та кінцевого провалу проекту через нездатність продукту виконувати ключові завдання з дотриманням ключових умов;
Проблеми з проранжованістю за стабільністю підвищують ризик виконання безглуздої роботи з удосконалення, реалізації та тестування вимог, які найближчим часом можуть зазнати кардинальних змін (аж до повної втрати актуальності);
Проблеми з проранжованістю по терміновості підвищують ризик порушення бажаної замовником послідовності реалізації функціональності та введення цієї функціональності в експлуатацію.
Коректність (correctness) та перевірюваність (verifiability). Фактично ці властивості випливають із дотримання всіх перелічених вище (або можна сказати, що вони не виконуються, якщо порушено хоча б одне з вищеперелічених). На додаток можна відзначити, що проверяемость передбачає можливість створення об'єктивного тест-кейсу (тест-кейсів), що однозначно показує, що вимога реалізована вірно і поведінка програми точно відповідає вимогі. До типових проблем із коректністю також можна віднести:
друкарські помилки (особливо небезпечні друкарські помилки в абревіатурах, що перетворюють одну осмислену абревіатуру в іншу також осмислену, але не має відношення до якогось контексту; такі друкарські помилки вкрай складно помітити);
наявність неаргументованих вимог до дизайну та архітектури;
погане оформлення тексту та супутньої графічної інформації, граматичні, пунктуаційні та інші помилки у тексті;
неправильний рівень деталізації (наприклад, надто глибока деталізація вимоги на рівні бізнес-вимог або недостатня деталізація на рівні вимог до продукту);
вимоги до користувача, а не до додатка (наприклад: «користувач повинен бути в змозі надіслати повідомлення» - на жаль, ми не можемо впливати на стан користувача).
Джерела вимог :
Федеральне та муніципальне галузеве законодавство (конституція, закони, розпорядження);
Нормативне забезпечення організації (регламенти, становища, статути, накази);
Поточна організація діяльності об'єкта автоматизації;
Моделі діяльності (діаграми бізнес-процесів);
Подання та очікування споживачів та користувачів системи;
журнали використання існуючих програмно-апаратних систем;
Конкуруючі програмні продукти.
Види документів вимог :
Специфікація вимог до програмного забезпечення(SRS - Software Requirement Specification): є документом, підготовленим групою системних аналітиків (system analysts), який використовується для опису програмного забезпечення, яке буде розроблено, основної бізнес-мети та функціональності певного продукту, а також того, як він виконує свої основні функції. В організаціях, які використовують SRS, вони зазвичай дуже схожі на те, що описується у PRD та FSD. SRS - це основа будь-якого проекту, оскільки він складається зі структури, якою слідуватиме кожен член команди. SRS також є основою контракту із зацікавленими сторонами (користувачами / клієнтами), який включає всі подробиці про функціональність майбутнього продукту і про те, як він повинен працювати. SRS широко використовується розробниками програмного забезпечення у процесі розробки продукту чи програми. SRS включає як функціональні, і нефункціональні вимоги, і навіть варіанти використання. В ідеальному документі SRS враховується не тільки те, як програмне забезпечення буде взаємодіяти з іншим програмним забезпеченням або коли воно вбудоване в обладнання, але також потенційних користувачів та способи взаємодії з програмним забезпеченням. Він також містить посилання на таблиці та діаграми, щоб отримати чітке уявлення про всі деталі, пов'язані з продуктом. Документ SRS допомагає членам команди з різних відділів залишатися у єдності та забезпечувати виконання всіх вимог. Цей документ також дозволяє мінімізувати витрати та час на розробку програмного забезпечення. SRS включає як функціональні, і нефункціональні вимоги, і навіть варіанти використання. В ідеальному документі SRS враховується не тільки те, як програмне забезпечення буде взаємодіяти з іншим програмним забезпеченням або коли воно вбудоване в обладнання, але також потенційних користувачів та способи взаємодії з програмним забезпеченням. Він також містить посилання на таблиці та діаграми, щоб отримати чітке уявлення про всі деталі, пов'язані з продуктом. Документ SRS допомагає членам команди з різних відділів залишатися у єдності та забезпечувати виконання всіх вимог. Цей документ також дозволяє мінімізувати витрати та час на розробку програмного забезпечення. SRS включає як функціональні, і нефункціональні вимоги, і навіть варіанти використання. В ідеальному документі SRS враховується не тільки те, як програмне забезпечення буде взаємодіяти з іншим програмним забезпеченням або коли воно вбудоване в обладнання, але також потенційних користувачів та способи взаємодії з програмним забезпеченням. Він також містить посилання на таблиці та діаграми, щоб отримати чітке уявлення про всі деталі, пов'язані з продуктом. Документ SRS допомагає членам команди з різних відділів залишатися у єдності та забезпечувати виконання всіх вимог. Цей документ також дозволяє мінімізувати витрати та час на розробку програмного забезпечення. як програмне забезпечення буде взаємодіяти з іншим програмним забезпеченням або коли воно вбудоване в обладнання, але також потенційних користувачів та способи їх взаємодії з програмним забезпеченням. Він також містить посилання на таблиці та діаграми, щоб отримати чітке уявлення про всі деталі, пов'язані з продуктом. Документ SRS допомагає членам команди з різних відділів залишатися у єдності та забезпечувати виконання всіх вимог. Цей документ також дозволяє мінімізувати витрати та час на розробку програмного забезпечення. як програмне забезпечення буде взаємодіяти з іншим програмним забезпеченням або коли воно вбудоване в обладнання, але також потенційних користувачів та способи їх взаємодії з програмним забезпеченням. Він також містить посилання на таблиці та діаграми, щоб отримати чітке уявлення про всі деталі, пов'язані з продуктом. Документ SRS допомагає членам команди з різних відділів залишатися у єдності та забезпечувати виконання всіх вимог. Цей документ також дозволяє мінімізувати витрати та час на розробку програмного забезпечення. щоб отримати чітке уявлення про всі деталі, пов'язані з продуктом. Документ SRS допомагає членам команди з різних відділів залишатися у єдності та забезпечувати виконання всіх вимог. Цей документ також дозволяє мінімізувати витрати та час на розробку програмного забезпечення. щоб отримати чітке уявлення про всі деталі, пов'язані з продуктом. Документ SRS допомагає членам команди з різних відділів залишатися у єдності та забезпечувати виконання всіх вимог. Цей документ також дозволяє мінімізувати витрати та час на розробку програмного забезпечення.
Специфікація бізнес-вимог(BRS – Business Requirement Specification): BRS – це специфікація бізнес-вимог, мета якої – показати, як задовольнити бізнес-вимоги на ширшому рівні. Документ BRS є одним із найпоширеніших документів зі специфікаціями. Це дуже важливо, і BRS зазвичай створюється на початку життєвого циклу продукту і описує основні цілі продукту або потреби, які клієнт хоче досягти за допомогою певного програмного забезпечення або продукту. Він зазвичай створюється бізнес-аналітиком (business analyst) на основі специфікацій інших зацікавлених сторін та після ретельного аналізу компанії-клієнта. Зазвичай остаточна версія документа перевіряється клієнтом, щоб переконатися, що очікування всіх зацікавлених сторін бізнесу є вірними. BRS включає всі вимоги, запитані клієнтом. Як правило, він складається з мети продукту, користувачів, загального обсягу робіт, всіх перерахованих функцій та можливостей, вимог до зручності використання та продуктивності. У цьому типі документа не включено варіанти використання, а також діаграми та таблиці. BRS використовується в основному вищим та середнім менеджментом, інвесторами у продукти, бізнес-аналітиками;
Специфікація функціональних вимог(FRS - Functional Requirement Specification): документ, в якому описані всі функції, які має виконувати програмне забезпечення або продукт. Фактично, це покрокова послідовність всіх операцій, необхідні розробки продукту від початку остаточно. FRS пояснює подробиці того, як певні програмні компоненти будуть поводитися під час взаємодії з користувачем. Цей документ створено кваліфікованими розробниками та інженерами та вважається результатом тісної співпраці між тестувальниками та розробниками. Основна відмінність від документа SRS у тому, що FRS не включає варіанти використання. Він також може містити діаграми та таблиці, але це не обов'язково. Цей документ є найбільш докладним, оскільки в ньому докладно пояснюється, як програмне забезпечення має функціонувати (включаючи бізнес-аспекти, відповідність вимогам, вимоги безпеки), оскільки воно також має відповідати всім вимогам, зазначеним у документах SRS та BRS. FRS допомагає розробникам зрозуміти, який продукт вони повинні створити, а тестувальники програмного забезпечення краще розуміються на різних тестових прикладах та сценаріях, в яких очікується тестування продукту;
Документ бізнес-вимог (BRD - Business Requirements Document, Business Needs Specification, Business Requirements): BRD фокусуються на визначенні бізнес-завдань проекту. BRD визначає одну або кілька бізнес-задач, що стоять перед користувачами, які можуть бути вирішені за допомогою продукту компанії. Після цього пропонується рішення - зазвичай це новий продукт чи удосконалення існуючого продукту у потрібній частині. Він також може включати якийсь попередній бізнес аналіз - прогноз прибутків, аналіз ринку та конкурентів, а також стратегію продажу та просування. Найчастіше він пишеться Менеджером з продукту, Менеджером з маркетингу продукту чи Бізнес-аналітиком. У маленьких компаніях може бути навіть директор чи власник фірми;
Документ вимог ринку (MRD - Market Requirements Document): MRD фокусується на визначенні вимог ринку до пропонованого нового продукту. Якщо BRD визначає коло проблем і пропонує варіант їх вирішення, то MRD детальніше описує деталі запропонованого рішення. Він може включати кілька або всі наведені нижче аспекти:
Функціональні можливості, необхідні вирішення бізнес задач;
Аналіз ринку та конкурентів;
Функціональні та нефункціональні вимоги;
Пріоритезацію вимог та функціональних можливостей;
Варіанти використання;
Найчастіше він пишеться Менеджером з продукту, Менеджером з маркетингу продукту або Бізнес-аналітиком спільно з Системним аналітиком. Деякі організації об'єднують MRD та PRD в один документ та називають цей документ MRD. У цьому випадку MRD включатиме те, що описано в цій частині і те, що описано в наступній - і може містити більше 50 сторінок;
Документ вимог до продукту (PRD - Product Requirements Document): PRD фокусується на визначенні вимог до нового продукту. Якщо MRD фокусується на вимогах з погляду потреб ринку, PRD фокусується на вимогах з погляду самого продукту. Зазвичай він більш детально описує можливості та функціональні вимоги і може навіть містити скріншоти та лейаути інтерфейсів користувача. В організаціях, де MRD не включає деталізацію вимог та варіанти використання, PRD закриває цей пролом. Зазвичай він пишеться Менеджером з продукту, Бізнес-аналітиком або Продуктовим аналітиком;
Функціональна специфікація (FSD - Functional Specifications Document): FSD детально визначає функціональні вимоги до продукту з фокусуванням на реалізації. FSD може визначати продукт послідовно форму за формою та одну функціональну можливість за іншою. Це документ, який може безпосередньо використовуватися командою розробників для створення продукту. Якщо MRD та PRD фокусуються на вимогах з точки зору потреб ринку та продукту, FSD фокусується на визначенні деталей продукту у формі, яка може бути використана розробниками. FSD може також включати закінчені скріншоти і детальний опис інтерфейсів користувача (UI). Зазвичай він пишеться Системним аналітиком, Архітектором рішення чи Головним розробником – тобто. автор зазвичай сам належить до розробників;
Специфікація продукту (PSD – Product Specifications Document): PSD – це найменш популярна абревіатура, але в тих організаціях, які використовують ці документи, вони зазвичай відповідають за змістом та обсягом Функціональної специфікації (Functional Specifications Document FSD) описаний вище;
Специфікація функціонального дизайну (FDS – Functional Design Specification);
Специфікація технічного дизайну (TDS – Technical Design Specification);
…
Техніки тестування вимог див. у темі “Тестування документації” у видах тестування.
Джерела:
Дод. матеріал:
Карл Вігерс «Розробка вимог до програмного забезпечення»
Last updated