Вступ

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

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

Під час інтерв’ю з Visure Solutions, Йордан Кіріакідіс, шановний співзасновник і генеральний директор QRA Corp, поділився своїми думками щодо різних аспектів розробки вимог. Під час цього інтерв’ю ми обговорили досить цікаві теми, в тому числі

• Основні елементи великих вимог
• EASY Aпідхід до Rрівняння Syntax підхід
• ШІ набирає обертів у цифровізації розробки вимог
• Поради та підказки щодо написання чудових вимог
• І багато іншого!

Хто такий Джордан Кіріакідіс?

Джордан Кіріакідіс є відомим лідером у галузі проектування та перевірки важливих для безпеки систем. Він є співзасновником і генеральним директором QRA Corp, компанії, яка надає передові рішення для компаній і урядів для виявлення та зменшення ризиків у складних проектах із застосуванням нових технологій у регульованих галузях. Маючи майже два десятиліття досвіду керівництва високопродуктивними командами, Джордан є досвідченим науковцем із численними міжнародними публікаціями.

Джордан має ступінь доктора філософії. отримав ступінь магістра квантової теорії в Базельському університеті, Швейцарія, і жив і працював у різних країнах світу, включаючи Європу, Сполучені Штати та Канаду. Його досвід у розробці вимог у поєднанні з його пристрастю до розвитку галузі зробили його затребуваним оратором і лідером думок у галузі. Джордан відомий своїм далекоглядним підходом до використання штучного інтелекту та найкращих практик для написання вимог у критичних галузях, і він відіграв важливу роль у цифровизації розробки вимог.

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

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

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

Важливість написання великих вимог

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

1. Чітка комунікація: Добре написані вимоги допомагають гарантувати, що всі зацікавлені сторони проекту мають чітке та спільне розуміння того, чого очікують від системи або продукту, що розробляється. Ця чіткість гарантує, що всі працюють на одній сторінці, зменшуючи ризик непорозумінь і недомовок, які можуть призвести до помилок, переробки та затримок проекту.
2. Зосередьтеся на потребах користувачів: Великі вимоги зосереджені на потребах кінцевих користувачів і клієнтів, гарантуючи, що система або продукт, що розробляється, відповідає їхнім очікуванням і вимогам. Такий підхід підвищує задоволеність клієнтів і знижує ризик провалу проекту через невідповідність продукту потребам користувачів.
3. Управління ризиками: Вимоги можуть визначити потенційні ризики та проблеми на ранніх стадіях процесу розробки, дозволяючи запроваджувати проактивні стратегії пом’якшення. Виявляючи потенційні проблеми на ранній стадії, команди можуть уникнути дорогих переробок, затримок і збоїв у подальшому.
4. Ефективність: Великі вимоги допомагають оптимізувати процес розробки, надаючи чітку дорожню карту для розробників. Ця дорожня карта гарантує, що розробники працюють над найважливішими функціями та вимогами, уникаючи марних зусиль на менш важливі завдання.
5. Гарантія якості: Маючи чітко визначені вимоги, легше переконатися, що система або продукт, що розробляється, відповідає необхідним стандартам якості. Високі вимоги спрощують тестування, валідацію та перевірку системи або продукту, що розробляється, гарантуючи, що вони будуть доставлені вчасно, у межах бюджету та з очікуваним рівнем якості.

Характеристика Високих Вимог

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

1. Чіткий і стислий: Великі вимоги легко зрозуміти, вони мають чітку та стислу мову, яка уникає двозначності та плутанини.
2. Завершити: Великі вимоги повинні охоплювати всі необхідні функціональні та нефункціональні аспекти системи чи продукту, що розробляється, не залишаючи місця для інтерпретацій чи непорозумінь.
3. Точний: Великі вимоги мають бути точними та такими, що можна перевірити, без розбіжностей між тим, що написано, і тим, що очікується від системи чи продукту.
4. Тестується: Великі вимоги повинні бути тестованими, тобто повинна бути можливість створювати тести, які можуть підтвердити, що система або продукт відповідає вимогам.
5. Пріоритет: Високі вимоги повинні бути пріоритетними, щоб гарантувати, що найважливіші функції та функції розроблені першими.
6. Можливо: Великі вимоги мають бути здійсненними, тобто технічно та практично досяжними в рамках заданих часових та бюджетних обмежень.
7. Відстежується: Великі вимоги мають бути простежуваними, тобто існує чіткий зв’язок між кожною вимогою та її джерелом, включаючи зацікавлену сторону, яка її запитала.
8. послідовний: Великі вимоги повинні узгоджуватися з іншою проектною документацією, включаючи план проекту, заяву про обсяг та іншу відповідну документацію.
9. однозначно: Великі вимоги повинні бути вільними від двозначності або плутанини, забезпечуючи чітке розуміння того, що очікується від системи або продукту, що розробляється.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. неоднозначність: Однією з найпоширеніших помилок при написанні вимог є використання двозначної мови, яка може призвести до непорозумінь і помилок. Цього можна уникнути, використовуючи чітку, стислу та недвозначну мову.
2. Неповні або невідповідні вимоги: Вимоги, які є неповними або суперечливими, можуть призвести до плутанини та помилок у процесі розробки програмного забезпечення. Цього можна уникнути шляхом перегляду та перевірки вимог, щоб переконатися, що вони повні та відповідають іншій проектній документації.
3. Відсутність пріоритетів: Без належного визначення пріоритетів вимоги можуть бути розроблені випадковим чином, що призведе до затримок і продукту, який не відповідає очікуванням клієнтів. Пріоритезація вимог може гарантувати, що найважливіші функції та функції розроблені першими.
4. Нечіткі або неперевірені вимоги: Нечіткі або неперевірені вимоги можуть призвести до непорозумінь і труднощів під час підтвердження того, що система або продукт відповідає вимогам. Цього можна уникнути, переконавшись, що вимоги чіткі та такі, що їх можна перевірити.
5. Позолота: Позолота виникає, коли до системи чи продукту додаються додаткові функції чи функції, які не були зазначені у вимогах. Це може призвести до затримок, додаткових витрат і продукту, який не відповідає потребам клієнтів.
6. Відсутність залучення зацікавлених сторін: Відсутність залучення зацікавлених сторін може призвести до вимог, які не відповідають потребам клієнтів та інших зацікавлених сторін. Залучення зацікавлених сторін протягом усього процесу розробки програмного забезпечення може гарантувати, що вимоги відповідають їхнім потребам і очікуванням.
7. Надмірна залежність від технологій: Надмірна залежність від технологій може призвести до вимог, які не відповідають можливостям системи або продукту, що розробляється. Цього можна уникнути, переконавшись, що вимоги здійсненні та узгоджені з технологією, яка використовується.
8. Міркування щодо відсутності тестування: Тестування є важливим аспектом розробки програмного забезпечення, і відсутність урахування тестування у вимогах може призвести до того, що продукт буде важко перевірити або він не відповідає стандартам якості.

Вимоги до написання з використанням методів природної мови

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

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

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

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

Шаблон ВУХА

Шаблон EARS (Easy Approach to Requirements Syntax) — це шаблон збору вимог і документації, який забезпечує структурований спосіб збору та документування вимог. Він зазвичай використовується в таких галузях, як аерокосмічна, оборонна та розробка програмного забезпечення, де є потреба охопити та задокументувати складні та часто технічні вимоги. Шаблон EARS можна використовувати як для функціональних, так і для нефункціональних вимог.

Шаблон EARS складається з чотирьох основних розділів:

1. Навколишнє середовище: У цьому розділі описано контекст, у якому працюватиме система, включаючи будь-які обмеження чи залежності, які необхідно враховувати.
2. Актор: У цьому розділі описуються різні типи користувачів або систем, які взаємодіятимуть із системою, включно з їхніми ролями та обов’язками.
3. вимога: Цей розділ описує конкретні вимоги до системи, включаючи як функціональні, так і нефункціональні вимоги. Кожна вимога визначена чітко та лаконічно за допомогою стандартизованого синтаксису.
4. Стимул: У цьому розділі описано вхідні дані, які ініціюватимуть систему для виконання певних дій або відповідей, а також очікувані результати чи відповіді.

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

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

Рекомендації INCOSE – шаблон

INCOSE, або Міжнародна рада з системної інженерії, є міжнародною некомерційною організацією, яка надає стандарти та рекомендації, щоб допомогти організаціям створювати кращі процеси системної інженерії. Стандарт системних вимог INCOSE (SRS) містить набір правил і стандартів, які розроблені, щоб допомогти організаціям оцінити заяви про вимоги до їх впровадження. SRS був прийнятий низкою великих корпорацій, а також урядовими установами по всьому світу і може використовуватися в багатьох галузях промисловості для різних застосувань. Важливо, щоб зацікавлені сторони, як-от розробники програмного забезпечення, бізнес-аналітики, менеджери проектів, тестувальники, персонал ІТ-відділу та інші члени команди, добре розуміли ці вимоги перед початком роботи над будь-якою системною заявою чи проектом.

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

Що таке правила INCOSE?

Заяви про вимоги оцінюються за правилами INCOSE. Ці стандарти допомагають організаціям оцінити здійсненність і якість вимог перед їх впровадженням. Процес оцінювання включає чотири основні критерії:

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

Майбутні тенденції: Написання вимог за допомогою ШІ

Технологія штучного інтелекту (ШІ) може революціонізувати процес написання та управління вимогами під час розробки продукту. В останні роки відбулися значні досягнення в обробці природної мови (NLP) і машинному навчанні (ML), які зробили можливим автоматизувати певні аспекти розробки вимог.

Однією з потенційних майбутніх тенденцій є використання чат-ботів на основі ШІ, таких як ChatGPT і Jasper, для допомоги у написанні вимог. Ці чат-боти використовують алгоритми NLP для аналізу вхідних даних від зацікавлених сторін і формування вимог до високої якості на основі цих вхідних даних. Використовуючи ці інструменти, організації можуть оптимізувати процес розробки вимог, зменшуючи час і зусилля, необхідні для розробки вимог, що призводить до швидшого циклу розробки продукту та більш ефективного використання ресурсів.

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

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

Основні поради щодо написання вимог

1. Пишіть шарами – Написання вимог шарами означає розбиття складних вимог на більш дрібні, легші частини. Це допомагає зробити вимоги більш зрозумілими, комплексними та легшими для реалізації.
2. По одному - Кожну вимогу слід розглядати як окремий тестовий випадок. Не слід використовувати такі сполучники, як і, або тощо, оскільки вони можуть призвести до втрати вимог. Це особливо важливо, оскільки подібні терміни можуть змусити розробників і тестувальників програмного забезпечення не помітити вимоги. Розбиття складних потреб на менші частини, щоб кожну з них можна було перевірити окремо, є одним із способів запобігти цьому.
3. Говоріть «Що», а не «Як» – У центрі уваги має бути те, що буде робити система, а не те, як вона це робить. Крім того, уникайте занадто глибокого заглиблення в теми проектування, такі як імена полів, об’єкти мови програмування та об’єкти програмного забезпечення. Якщо ви обговорюєте ці теми в документі специфікації вимог, зробіть крок назад – це, ймовірно, означає, що ви стаєте занадто конкретними.
4. Піддається перевірці – Інша річ, про яку слід пам’ятати, коли організовує вимоги, це те, що вони завжди повинні бути перевіреними. Це означає, що має бути можливість перевірити, чи система відповідає відповідній вимозі. Це також пов’язано з нашим наступним моментом – відстеженням. Якщо вимога повна розпливчастих термінів, стає важче проаналізувати та перевірити, чи справді система відповідає цим стандартам щодо продуктивності. Тому, наскільки це можливо, прагніть до ясності та точності у своїй мові, щоб збір вимог не був неоднозначним процесом.
5. Простежуваність – Простежуваність в управлінні проектом означає забезпечення зв’язку вимог з іншими компонентами проекту. Це дозволяє керівникам проектів, розробникам і зацікавленим сторонам відстежувати весь життєвий цикл вимоги від початку до кінця в усіх напрямках, а також з іншими частинами системи. Якщо ви належним чином керуєте відстежуваністю, ви можете уникнути коду, який не відповідає жодній вимозі («блудний» код), і переконатися, що кожен тестовий приклад покриває принаймні одну вимогу. Ви можете зробити вимоги відстежуваними, позначивши їх унікальним ідентифікатором і надавши інформацію про їх джерело в центральному сховищі, доступному для всіх членів команди.
6. 3 Ws – Вимоги мають бути зосереджені на задоволенні потреб користувача, а не на рішенні. Тому перед розробкою вимог важливо розуміти вимоги та проблемні точки користувача.
   1. Що? - Що ми робимо?
   2. ВООЗ? – Кому буде вигідно?
   3. чому – Чому ми це робимо?
7. 1 вимога до 1 завдання – У кожній вимозі має бути визначена одна дія та мета. Слідкуйте за надмірним використанням «і» та «або». Наприклад, «Якщо остання п’ятниця місяця, а платіж має бути здійснено 31 числа, і якщо 31 число є останньою п’ятницею місяця, то подання платежу в цей день після 6:XNUMX за східним часом призведе до затримки платежу ”. Я закликаю вас зрозуміти це!
8. Пріоритезація вимог – Розставте пріоритети вимог на основі їх важливості та впливу на успіх проекту. Це допомагає забезпечити першочергове виконання найважливіших вимог і задоволення потреб зацікавлених сторін.
9. Застереження про відмову відсутнє – Наприклад, «Система повинна визначити кількість спроб входу, за винятком випадків, коли користувач явно ввів неправильне ім’я користувача».

За словами Джордана, що відрізняє успішні проекти від невдалих?

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

Де знайти більше про Джордана Кіріакідіса?

Щоб дізнатися більше про Джордана Кіріакідіса та QRA Corp, перегляньте їхню сторінку в LinkedIn за адресою https://www.linkedin.com/company/qra-corp/. Крім того, ви можете знайти Джордана Кіріакідіса на LinkedIn за адресою https://www.linkedin.com/in/jordankyriakidis/. QRA Corp також має на своєму веб-сайті кілька технічних документів і тематичних досліджень, які дають уявлення про її технологію та її застосування в різних галузях промисловості.

Заключні думки

На завершення Джордан Кіріакідіс і Visure Solutions поділилися проникливою бесідою про вимоги до написання. Ми дослідили важливість написання великих вимог і торкнулися труднощів під час написання вимог, а також поширених помилок. Ми розглянули різні методи, такі як методи природної мови, шаблон EARS і рекомендації INCOSE. Технологія штучного інтелекту також відкрила багато можливостей для написання вимог, що полегшує людям, які починають вчитися їх краще писати. Нарешті, ми також включили ключові поради, які допоможуть вам на шляху, коли ви починаєте цю подорож. Від вивчення правил INCOSE до майбутніх тенденцій у написанні вимог – тут кожен знайде щось для себе! Заберіть ці важливі поради та застосуйте їх зараз! Перегляньте повне інтерв’ю зараз!