Однією з найважливіших частин будь-якого проекту розробки програмного забезпечення є створення детальних і точних вимог. Без чіткого розуміння того, що потрібно будувати, неможливо створити якісний кінцевий продукт. На жаль, написати гарні вимоги часто легше сказати, ніж зробити. Основна причина того, що люди пишуть погані вимоги, полягає в тому, що вони не мали навчання чи досвіду написання хороших вимог. Якщо у вас або ваших співробітників є проблеми з написанням якісних вимог, вам можуть бути корисні інструкції щодо написання хороших вимог. Витративши час на те, щоб навчитися писати кращі вимоги, ви зможете підвищити загальну якість своїх проектів розробки програмного забезпечення – і заощадити собі багато головного болю в майбутньому.

Чому проекти системної інженерії провалюються?

Чому проекти в жорстко регульованих галузях провалюються? Багато дослідників досліджували, чому системи та проекти програмного забезпечення провалюються. У 2009 році Standish Group провела дослідження, яке підкреслює, що більшість причин невдачі проектів пов’язані з вимогами.

Це одна з головних причин, чому написання хороших вимог має вирішальне значення для успіху проекту. Крім того, гарне написання вимог приносить багато інших переваг для команд.

Що таке специфікація вимог?

Специфікація вимог — це процес, у якому вимоги визначаються, документуються та аналізуються. Це важлива частина розробки програмного забезпечення, оскільки вона гарантує, що всі зацікавлені сторони погоджуються щодо функціональності програмного забезпечення перед початком розробки. Завдяки цьому зменшується ймовірність непорозумінь і переробок пізніше.

Специфікація вимог, також відома як документація, — це процес запису або запису всіх вимог до системи та користувача у формі документа. Ці вимоги мають бути чіткими, повними, вичерпними та послідовними.

Процес розробки вимог

Під час роботи з вимогами ми стикаємося з деякими видами діяльності. У циклі розробки вимог є п’ять основних видів діяльності, а саме:

1. Вимоги Виявлення – Це процес збору, перегляду та розуміння потреб і обмежень зацікавлених сторін і користувачів на сезон. Користувачам потрібна інформація про домен, інформація про існуючу систему, правила, стандарти тощо. На основі цієї інформації ми визначаємо вимоги. Після цього ми переходимо до аналізу вимог і узгодження. 
2. Аналіз вимог і переговори – Аналіз – це процес уточнення потреб і обмежень користувача на основі зібраної та виявленої інформації. Потім переходимо до документації. 
3. Документація/специфікація вимог – Після отримання специфікацій вимог переходимо до документації. Ми чітко та точно документуємо потреби та обмеження користувачів. 
4. Перевірка вимог – Нарешті, під час перевірки ми додаємо, що сезонні вимоги є повними, стислими та чіткими. 
5. Управління вимогами – Управління вимогами – це спосіб збору, аналізу, уточнення та визначення пріоритетності всіх продуктів або вимог на етапі розробки. Під час цієї фази також встановлюється надійна відстежуваність між вимогами та джерелами інформації. 

Коли ми завершуємо ці п’ять заходів, ми повторюємо їх знову і знову, поки не отримаємо набір узгоджених документів з вимогами, які є формальними специфікаціями.

Чому важливо правильно написати вимоги?

Наявність хороших специфікацій вимог має багато переваг. Деякі з них наведено нижче:

• Допомагає переконатися, що всі зацікавлені сторони мають спільне розуміння системи, яка має бути розроблена. Це дозволяє уникнути непорозумінь на наступних етапах розробки.
• Служить орієнтиром для всіх зацікавлених сторін у процесі розробки.
• Допомагає виявити будь-які прогалини у вимогах на ранній стадії.
• Зменшує загальну вартість і час розробки, оскільки дозволяє уникнути переробки через зміни вимог.

Чого ми досягаємо, пишучи великі вимоги?

Є багато речей, яких допомагають досягти великі вимоги. Деякі з них наведено нижче:

• Великі вимоги допомагають гарантувати, що система, що розробляється, відповідає потребам користувачів.
• Вони служать основою для тестування системи, щоб переконатися, що вона працює належним чином.
• Вони допомагають скоротити загальну вартість і час розробки, уникаючи переробки через зміни вимог.
• Великі вимоги допомагають зробити процес розробки ефективнішим і ефективнішим.

Проблеми під час написання вимог

Під час написання вимог люди стикаються з різними проблемами.

Погане оформлення документів – У деяких організаціях документація процесів або відсутня, або не на належному рівні. У цьому випадку збір вимог стає двоетапним процесом: спочатку зворотне проектування існуючого процесу, а потім визначення областей, які потребують вдосконалення та оптимізації. Щоб підтвердити, що вимоги є конкретизованими та точними, важливо визначити ключових зацікавлених сторін та експертів у відповідній галузі та безпосередньо спілкуватися з ними. Малювання карт бізнес-процесів і візуалізація робочих процесів є двома чудовими способами зробити це. Це допомагає усунути неправильні припущення, а також забезпечує повну картину. Малювання карт процесу та відображення процесів є двома корисними підходами для цієї мети.

Суперечливі вимоги – Коли зацікавлені сторони мають різні пріоритети для своїх бізнес-цілей, це призводить до вимог, які суперечать одна одній. У таких випадках відповідальність бізнес-аналітика полягає в тому, щоб детально задокументувати всі вимоги, визначити, які запити суперечать один одному, і надати зацікавленим сторонам можливість вирішити, що є пріоритетним.

Ви не можете приймати рішення, не вислухавши думку зацікавлених сторін, і як бізнес-аналітик ви можете мати певні ідеї щодо того, чому слід віддати пріоритет. Усе ще важливо почути точку зору зацікавлених сторін. Проведення опитування може бути одним із методів отримати ясність щодо того, що є найважливішим для більшості зацікавлених сторін.

Недоступність введення користувача – Кілька причин можуть призвести до недоступності кінцевих користувачів, і кожна з них потребує власного вирішення. Наприклад, іноді кінцеві користувачі настільки зайняті своєю щоденною роботою, що не бажають брати участь у зборі вимог.

У таких випадках найкраще, що може зробити бізнес-аналітик, це обмежити кількість і тривалість залучень. Проведення якомога більшої кількості досліджень перед зустріччю допоможе зробити дискусію більш організованою та інформативною. Це майже як перетворити збір вимог на сесії перевірки вимог. визначення фокус-груп і визначення найбільш прийнятних кінцевих користувачів для кожної групи

Зосередження на інтерфейсі, а не на досвіді – Багато зацікавлених сторін і кінцевих користувачів мають чітке бачення того, як має виглядати нове рішення, але вони не знають, чого воно має досягти. Інтерфейс користувача будь-якої системи має вирішальне значення, але він не повинен визначати або заважати функціональності.

Бізнес-аналітики завжди повинні пам’ятати, що вимоги до дизайну та функціональні вимоги слід розділяти у своїй документації. Використовуючи більш загальні інструменти, такі як діаграми, історії користувачів або прототипи з низьким рівнем інформації, а не чернетки дизайну, вони можуть зосередитися на функціональних аспектах збору вимог.

Внески зацікавлених сторін – Коли зацікавлені сторони або кінцеві користувачі намагаються розповісти розробникам, як має працювати система, а не те, що вона має робити, це може призвести до неоптимальних проектів. Щоб уникнути цього, перевірте кожну потенційну «помилкову вимогу», запитавши «чому?» поки ви не дійдете до справжньої проблеми, яку потрібно вирішити.

Питання зв'язку – Серед проблем, які можуть призвести до непорозуміння між бізнес-аналітиком та іншими сторонами, є мовні бар’єри, неправильні припущення, недостатньо пояснений словниковий запас і надмірне використання технічних термінів.

Ідеальним підходом, щоб уникнути цієї проблеми, є часте спілкування та розвиток двосторонніх розмов. Задокументуйте потреби, які ви виявили, і надішліть їх на рецензування та критику різним фахівцям із предметних питань, створіть глосарій жаргону та ще раз перевірте передумови.

Стандарти для написання вимог?

Ефективною методологією тут буде EARS. Це означає EASY Aпідходити до Rрівняння Syntax, Алістер Марвін. У цьому методі ми пишемо чітко, лаконічно та зрозуміло. Це покращує весь процес розробки вимог і спрощує роботу, роблячи речі досить легкими для розуміння. 

Щоб досягти цього, ось деякі принципи, які слід пам’ятати під час написання вимог. Вони включають:

• Кожна вимога має бути у формі повного речення. Не можна використовувати маркери, акроніми, абревіатури чи модні слова. Намагайтеся складати короткі, прямі та повні речення. 
• Переконайтеся, що кожна вимога має відповідний підмет, присудок і дієслово. Темою буде тип користувача або система, про яку ми говоримо. Предикатом будуть умови, дії або бажані результати, які ми очікуємо. Ми повинні використовувати такі слова, як «буде», «буде» та «повинен», щоб висловити якусь необхідність, і слова на кшталт «можеться», щоб висловити необов’язковість у вимозі. 
• Кожна вимога повинна ефективно пояснювати кінцевий результат, якого ми бажаємо від системи. 
• Крім того, вимога повинна описувати якість, яку ми очікуємо від системи. Це допомагає, коли ми оцінюємо кінцевий результат і перевіряємо, чи правильно реалізована вимога чи ні.

Основні компоненти документа вимог:

Основні розділи специфікації вимог до програмного забезпечення:

• Бізнес драйвери – У цьому розділі описано причини, чому клієнт хоче побудувати систему. Цей розділ також містить проблеми, з якими клієнт стикається з поточною системою, і можливості, які надасть нова система.
• Бізнес-модель – У цьому розділі обговорюється бізнес-модель, яку система має підтримувати. Він також містить різні інші деталі, як-от організаційний і бізнес-контекст, основні бізнес-функції та діаграми процесів системи.
• Функціональні та системні вимоги – У цьому розділі зазвичай детально описуються вимоги, організовані в ієрархічній структурі. Функціональні вимоги знаходяться на верхньому рівні, а детальні системні вимоги перераховані як підпункти.
• Випадки використання системи – Цей розділ містить діаграму варіантів використання Уніфікованої мови моделювання (UML), яка пояснює всі ключові зовнішні об’єкти, які взаємодіятимуть із системою, і різні варіанти використання, які вони повинні виконувати.
• Технічні вимоги – У цьому розділі обговорюються всі нефункціональні вимоги, які складають технічне середовище, і технічні обмеження, в яких працюватиме програмне забезпечення.  
• Системні якості – У цьому розділі визначаються численні якості системи, такі як надійність, придатність до обслуговування, безпека, масштабованість, доступність і зручність обслуговування.
• Обмеження та припущення – У цьому розділі описані всі обмеження, накладені на дизайн системи з точки зору клієнта. Тут також обговорюються різні припущення команди інженерів щодо того, чого очікувати під час розробки.
• Критерії прийняття – Детально про всі умови, які повинні бути виконані перед передачею системи кінцевим споживачам, обговорюються в цьому розділі.

Характеристики документа специфікації вимог до програмного забезпечення:

• Очистити – Письмові вимоги мають бути чіткими, легкими для читання та зрозумілими. Чітко конкретизуйте інформацію, використовуючи стверджувальні речення, якими мають обмінюватися актори. Кожна вимога повинна описувати чіткі критерії успіху. Намагайтеся використовувати просту лексику та уникайте скорочень. Наприклад, «Користувач повинен мати можливість переглядати звіт журналу аудиту».
• Атомний – Кожну вимогу слід розглядати як окремий тестовий випадок. Не слід використовувати такі сполучники, як і, або тощо, оскільки вони можуть призвести до втрати вимог. Це особливо важливо, оскільки подібні терміни можуть змусити розробників і тестувальників програмного забезпечення не помітити вимоги. Розбиття складних потреб на менші частини, щоб кожну з них можна було перевірити окремо, є одним із способів запобігти цьому.
• Однозначне – Нечіткі, неповні або суперечливі вимоги можуть призвести до помилок і переробки. Щоб запобігти цьому, вимоги повинні бути переглянуті кожною зацікавленою стороною до того, як вони будуть завершені. Це допоможе виявити будь-які прогалини на ранній стадії, які потім можна буде усунути.
• Перевіряється – Кожен член команди розробників повинен мати доступ до документа, щоб мати змогу звертатися до нього так часто, як це буде потрібно. Оскільки вимоги мають бути чіткими, членам команди не потрібна додаткова інформація. Усі вони мають бути доступні в документі ЄСВ.
• Необхідно – Кожна вимога має документувати те, що дійсно потрібно користувачам, або те, що потрібно для виконання стандарту чи потреби інтеграції через наявність зовнішнього інтерфейсу. Крім того, для кожної вимоги важливо мати авторизоване джерело.
• Незалежний дизайн – Кожна вимога має визначати, що необхідно, а не те, як це буде реалізовано. Вимоги повинні визначати характеристики системи, які спостерігатимуться зовні, а не внутрішні деталі.
• Здійсненно – Кожна вимога має бути технічно здійсненною та реалізовуватися з урахуванням бюджету, термінів та інших обмежень, які впливають на проект. Вимоги мають відображати фактичний стан справ, включаючи вартість, терміни та технологію. Вони не повинні залежати від майбутніх технологічних досягнень.
• Цілковита – Документ із вимогами має містити достатньо інформації для вашої команди розробників і тестувальників, щоб завершити продукт і переконатися, що він відповідає вимогам користувача без помилок.
• Правильно – Вимоги, зазначені в документах, мають бути дуже точними, щоб уникнути будь-якої плутанини. У них не повинно бути жодних лазівок, двозначностей, суб’єктивності, відмінних ступенів чи порівнянь. Отже, щоб написати правильні вимоги, ми повинні отримати правильну інформацію та правильно задокументувати зібрану інформацію.

Правила для набору правильних вимог

Існують певні правила, яких необхідно дотримуватися, щоб називатися «Правильним».

• Цілковита – Документ із вимогами має містити достатньо інформації для вашої команди розробників і тестувальників, щоб завершити продукт і переконатися, що він відповідає вимогам користувача без помилок.
• консистенція – Підтримуйте постійний рівень деталізації. Наприклад, для вимог користувача кінцевий користувач має бути предметом кожного речення. Подібним чином, для системних вимог система має бути предметом кожного речення.
• Модифікованість – Вимоги можуть змінюватися протягом життєвого циклу проекту. Журнал вимог повинен зберігатися, і має бути можливим аналіз впливу внесених до нього змін на інші вимоги та елементи проекту.
• Визначення пріоритетів – Вимоги мають бути класифіковані з точки зору важливості. Не всі характеристики, бажані для системи, однаково важливі. Для цього було б корисно встановити правило для визначення пріоритетів вимог на рівні організації та адаптувати його до кожного проекту. І працюйте з користувачами, щоб вони могли визначити пріоритетність вимог.

Вимоги до Visure Платформа ALM

Visure — одна з найбільш надійних платформ керування життєвим циклом програм, яка спеціалізується на управлінні вимогами для організацій будь-якого розміру по всьому світу. Основними партнерами Visure є компанії, які мають важливе значення для бізнесу та безпеки. Компанія інтегрує всі процеси керування життєвим циклом додатків, включаючи управління ризиками, відстеження проблем і дефектів, керування відстеженням, керування змінами та різноманітні інші сфери, такі як аналіз якості, версії вимог і ефективне звітування.  

Якщо ви шукаєте інструмент керування вимогами, який допоможе вам із функціональними та нефункціональними вимогами, перегляньте Visure Requirements. За допомогою цієї платформи ви можете легко створювати, керувати та відстежувати всі вимоги вашого проекту в одному місці.

Висновок

Щоб створювати якісне програмне забезпечення, важливо мати добре написану специфікацію вимог. Цей документ окреслює потреби клієнта та те, що система повинна робити, щоб відповідати їхнім очікуванням. Однак написання хороших вимог може бути складним завданням. Існує багато стандартів і вказівок, яких необхідно дотримуватися, і є багато різних способів їх написання залежно від мови та інструментів, які ви використовуєте. Visure Requirements ALM Platform пропонує курс, який навчить вас писати ефективні специфікації вимог, використовуючи найкращі практики та галузеві стандарти. Курс охоплює всі основні компоненти документа вимог, від структури до форматування, а також як використовувати різні мови для написання вимог. Він також висвітлює характеристики великих вимог, щоб ви могли створювати документи, з якими ваша команда любитиме працювати. Якщо ви хочете дізнатися більше про написання ефективних вимог, спробуйте Специфікація вимог до курсу від Visure Вимоги до платформи ALM сьогодні!