Найповніший посібник із керування вимогами та відстеження
Що можна і чого не можна робити щодо вимог до написання
Зміст
Якщо ви схожі на більшість людей, вам, ймовірно, не подобаються вимоги до письма. Це не найцікавіша річ у світі, але це важлива частина розробки продукту. Кращий документ вимог може заощадити вашій організації цілий стан завдяки чіткій комунікації між розробником і зацікавленими сторонами продукту. Це, у свою чергу, відображається на всій організації, включаючи більшу прозорість, меншу кількість переробок і підвищення продуктивності.
Хоча кожна організація має різні вимоги та методології, основи для написання вимог залишаються незмінними. У цій статті ми поділимося кількома порадами, які допоможуть вам покращити свої навички написання вимог і допоможуть вам написати чіткі та чіткі специфікації вимог.
Що таке специфікація вимог?
Специфікація вимог, також відома як документація, — це процес запису всіх вимог системи та користувача у вигляді документа. Ці вимоги мають бути чіткими, повними, вичерпними та послідовними.
Під час захоплення ми збираємо всі вимоги з різних джерел. Під час аналізу та переговорів ми аналізуємо та розуміємо ці вимоги. Тепер ми повинні підготувати офіційний документ, що пояснює ці вимоги. Ось що таке специфікація вимог. Якщо бути точним, то це процес чіткого та точного документування всіх потреб і обмежень користувача та системи.
Що означають «найкращі практики» в управлінні вимогами?
Мені так цікаво, що всі говорять про бажання навчатися «найкращим практикам». Цей термін часто використовується для опису консультацій, які ми також можемо надавати. Що це насправді означає? Я вважаю, що всі ми живемо міфом про те, що найкращі практики можуть бути основою для навчання людей. Кращі практики не навчаються, вони досвідчені.
Якщо ми порівняємо передовий підхід до природи, ми знаємо, що виживають не лише найсильніші, але й найплідніші види. Це одна з причин, чому так важко змінити процеси в організації. Подумайте про це на мить. Найсильніші та найплідніші, ймовірно, описують більшість людей, які є в будь-якій групі у вашій організації. Я бачив це знову і знову в галузі системної інженерії. Найсильніші та найплідніші інженери часто виконують свою роботу багато років і мають особливий спосіб виконання цієї роботи. Просити їх спробувати нові техніки та інструменти часто марно, оскільки вони не знають, як це покращить і без того чудову роботу, яку вони виконують. Їхня практика виживе, якщо ми продовжуватимемо нав’язувати їм передовий підхід.
Проблеми під час написання вимог
Під час написання вимог люди стикаються з різними проблемами.
Погане оформлення документів – У деяких організаціях документація процесів або відсутня, або не на належному рівні. У цьому випадку збір вимог стає двоетапним процесом: спочатку зворотне проектування існуючого процесу, а потім визначення областей, які потребують вдосконалення та оптимізації. Щоб підтвердити, що вимоги є конкретизованими та точними, важливо визначити ключових зацікавлених сторін та експертів у відповідній галузі та безпосередньо спілкуватися з ними. Малювання карт бізнес-процесів і візуалізація робочих процесів є двома чудовими способами зробити це. Це допомагає усунути неправильні припущення, а також забезпечує повну картину. Малювання карт процесу та відображення процесів є двома корисними підходами для цієї мети.
Суперечливі вимоги – Коли зацікавлені сторони мають різні пріоритети для своїх бізнес-цілей, це призводить до вимог, які суперечать одна одній. У таких випадках відповідальність бізнес-аналітика полягає в тому, щоб детально задокументувати всі вимоги, визначити, які запити суперечать один одному, і надати зацікавленим сторонам можливість вирішити, що є пріоритетним.
Ви не можете приймати рішення, не вислухавши думку зацікавлених сторін, і як бізнес-аналітик ви можете мати певні ідеї щодо того, чому слід віддати пріоритет. Усе ще важливо почути точку зору зацікавлених сторін. Проведення опитування може бути одним із методів отримати ясність щодо того, що є найважливішим для більшості зацікавлених сторін.
Недоступність введення користувача – Кілька причин можуть призвести до недоступності кінцевих користувачів, і кожна з них потребує власного вирішення. Наприклад, іноді кінцеві користувачі настільки зайняті своєю щоденною роботою, що не бажають брати участь у зборі вимог.
У таких випадках найкраще, що може зробити бізнес-аналітик, це обмежити кількість і тривалість залучень. Проведення якомога більшої кількості досліджень перед зустріччю допоможе зробити дискусію більш організованою та інформативною. Це майже як перетворити збір вимог на сесії перевірки вимог. визначення фокус-груп і визначення найбільш прийнятних кінцевих користувачів для кожної групи
Зосередження на інтерфейсі, а не на досвіді – Багато зацікавлених сторін і кінцевих користувачів мають чітке бачення того, як має виглядати нове рішення, але вони не знають, чого воно має досягти. Інтерфейс користувача будь-якої системи має вирішальне значення, але він не повинен визначати або заважати функціональності.
Бізнес-аналітики завжди повинні пам’ятати, що вимоги до дизайну та функціональні вимоги слід розділяти у своїй документації. Використовуючи більш загальні інструменти, такі як діаграми, історії користувачів або прототипи з низьким рівнем інформації, а не чернетки дизайну, вони можуть зосередитися на функціональних аспектах збору вимог.
Внески зацікавлених сторін – Коли зацікавлені сторони або кінцеві користувачі намагаються розповісти розробникам, як має працювати система, а не те, що вона має робити, це може призвести до неоптимальних проектів. Щоб уникнути цього, перевірте кожну потенційну «помилкову вимогу», запитавши «чому?» поки ви не дійдете до справжньої проблеми, яку потрібно вирішити.
Питання зв'язку – Серед проблем, які можуть призвести до непорозуміння між бізнес-аналітиком та іншими сторонами, є мовні бар’єри, неправильні припущення, недостатньо пояснений словниковий запас і надмірне використання технічних термінів.
Ідеальним підходом, щоб уникнути цієї проблеми, є часте спілкування та розвиток двосторонніх розмов. Задокументуйте потреби, які ви виявили, і надішліть їх на рецензування та критику різним фахівцям із предметних питань, створіть глосарій жаргону та ще раз перевірте передумови.
10 правил, які можна і чого не робити під час написання вимог:
Виконайте №1. По одному – Кожну вимогу слід розглядати як окремий тестовий випадок. Не слід використовувати такі сполучники, як і, або тощо, оскільки вони можуть призвести до втрати вимог. Це особливо важливо, оскільки подібні терміни можуть змусити розробників і тестувальників програмного забезпечення не помітити вимоги. Розбиття складних потреб на менші частини, щоб кожну з них можна було перевірити окремо, є одним із способів запобігти цьому.
Не №1. Говоріть «Що», а не «Як» – У центрі уваги має бути те, що буде робити система, а не те, як вона це робить. Крім того, уникайте занадто глибокого заглиблення в теми проектування, такі як імена полів, об’єкти мови програмування та об’єкти програмного забезпечення. Якщо ви обговорюєте ці теми в документі специфікації вимог, зробіть крок назад – це, швидше за все, означає, що ви стаєте занадто конкретними.
Виконайте №2. Простежуваність – Відстеження в управлінні проектом означає забезпечення того, що вимоги пов’язані з іншими компонентами проекту. Це дозволяє керівникам проектів, розробникам і зацікавленим сторонам відстежувати весь життєвий цикл вимоги від початку до кінця в усіх напрямках, а також з іншими частинами системи. Якщо ви належним чином керуєте відстеженням, ви можете уникнути коду, який не відповідає жодній вимозі («блудний» код), і переконатися, що кожен тестовий приклад покриває принаймні одну вимогу. Ви можете зробити вимоги відстежуваними, позначивши їх унікальним ідентифікатором і надавши інформацію про їх джерело в центральному сховищі, доступному для всіх членів команди.
Не №2. Без винятків – Вимога не повинна мати вихідне положення. Наприклад, «Система повинна визначити кількість спроб входу, за винятком випадків, коли користувач явно ввів неправильне ім’я користувача».
Виконайте №3. Здійсненно – Переконайтеся, що бюджет і графік проекту є здійсненними, а також наявні ресурси. Якщо ця умова підтримує вимогу, тоді можна рухатися вперед із планом.
Не №3. Скажіть «Ні» положенням про «звільнення». – Намагайтеся триматися подалі від таких фраз, як «але», «за винятком» і лише в разі необхідності.
Виконайте №4. консистенція – Підтримуйте постійний рівень деталізації. Наприклад, для вимог користувача кінцевий користувач має бути предметом кожного речення. Подібним чином, для системних вимог система має бути предметом кожного речення.
Не №4. Без скорочень – Кожна вимога має бути повним реченням без абревіатур чи жаргону.
Виконайте №5. Активний голос – Завжди пишіть активним голосом, переконавшись, що підметом кожного речення є одна з дійових осіб.
Не №5. Не будьте двозначними – Не використовуйте двозначні терміни, такі як приблизно тощо, і більше подібних термінів у документі вимог. Обов’язково пояснюйте вимоги таким чином, щоб усі учасники зрозуміли їх правильно. Нечіткі твердження можуть призвести до неправильного тлумачення та спричинити конфлікти між різними зацікавленими сторонами.
Виконайте №6. Підмет і присудок – Для кожної вимоги має бути суб’єкт (користувач/система) і предикат (запланований результат, дія чи умова).
Не №6. Спекуляції можуть завдати шкоди – Не гадай; не складайте списки функцій, про які не може бути й мови. Сказати, що ви хочете, щоб система справлялася з усіма несподіваними збоями, — чиста фантазія, оскільки жодна система ніколи не буде на 100 відсотків такою, якою ви її бажаєте бачити. Уникайте дублювання та суперечливих тверджень.
Виконайте №7. Перевіряється – Інша річ, про яку слід пам’ятати, коли організовує вимоги, це те, що вони завжди повинні бути перевіреними. Це означає, що має бути можливість перевірити, чи система відповідає відповідній вимозі. Це також пов’язано з нашим наступним моментом – відстеженням. Якщо вимога повна розпливчастих термінів, стає важче проаналізувати та перевірити, чи справді система відповідає цим стандартам щодо продуктивності. Тому, наскільки це можливо, прагніть до ясності та точності у своїй мові, щоб збір вимог не був неоднозначним процесом.
Не №7. Уникайте варіантів – Не пропонуйте ідей чи варіантів. Ви можете помітити їх у будь-якому твердженні, яке містить фрази may, might, could або ought.
Виконайте №8. Правильно – Переконайтеся, що кожне речення повне та граматично правильне з належним підметом, дієсловом і присудком.
Не №8. Не говоріть у майбутньому часі – Не посилайтеся на вимоги, які ще не визначені. Ваша мета — зробити документ якомога приємнішим для читання.
Виконайте №9. Сфокусувати – Сконцентруйте увагу, усунувши безладні, задовгі фрази та посилання на застарілі документи.
Не №9. Що слід використовувати і де? – «Повинен» використовуватися там, де формулюються вимоги, «Буде» слід використовувати для представлення викладень фактів; & «Потрібно» для позначення мети, якої потрібно досягти.
Виконайте №10. Організована документообіг творить чудеса – Тримайте вимоги впорядкованими в одному місці, щоб покращити читабельність вашого документа та не витрачати час на перехресні посилання на кілька джерел.
Не №10. Не використовуйте невідомі терміни – Не використовуйте невідомі терміни, такі як «зручний, універсальний і надійний», оскільки це може створити труднощі під час спроби визначити тестові випадки. Ці слова часто мають різне значення для різних людей.
Вимоги до Visure Платформа ALM
Visure — одна з найбільш надійних платформ керування життєвим циклом програм, яка спеціалізується на управлінні вимогами для організацій будь-якого розміру по всьому світу. Основними партнерами Visure є компанії, які мають важливе значення для бізнесу та безпеки. Компанія інтегрує всі процеси керування життєвим циклом додатків, включаючи управління ризиками, відстеження проблем і дефектів, керування відстеженням, керування змінами та різноманітні інші сфери, такі як аналіз якості, версії вимог і ефективне звітування.
Якщо ви шукаєте інструмент керування вимогами, який допоможе вам із функціональними та нефункціональними вимогами, перегляньте Visure Requirements. За допомогою цієї платформи ви можете легко створювати, керувати та відстежувати всі вимоги вашого проекту в одному місці.
Висновок
Специфікація вимог є критично важливим процесом у розробці програмного забезпечення, але написати хороші вимоги може бути важко. 20 порад, які ми надали, мають допомогти вам написати кращі вимоги, спростивши процес для всіх учасників. Якщо ви хочете вивести свої вимоги на наступний рівень, подумайте про використання такого інструменту, як Visure Requirements ALM Platform. Запит а Безкоштовна пробна версія 30 сьогодні й подивіться, як наша платформа може допомогти вам оптимізувати процеси збору вимог і керування ними.
Не забудьте поділитися цим постом!
