Аналіз вимог

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук
Аналіз вимог — перша стадія процесу розробки ПЗ.[1]
Цикл розробки
програмного забезпечення
Coding Shots Annual Plan high res-5.jpg
Програміст за роботою
Діяльність та кроки
Вимоги ·  Специфікація
Архітектура ·  Дизайн
Реалізація ·  Тестування
Розгортання ·  Підтримка
Методології
Гнучка ·  Чистого приміщення
DSDM ·  Iterative ·  RAD ·  RUP
Spiral ·  Водоспад ·  XP ·  Scrum
Lean ·  V-Model ·  FDD ·  TDD
Допоміжні дисципліни
Конфігураційне керування
Документування
Якість ПЗ
Управління проектами
Досвід користування
Інструменти
Компілятор ·  Зневаджувач
Профілювальник
GUI designer ·  IDE
Див. також
Стадії розробки програмного забезпечення


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

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

Огляд[ред.ред. код]

Аналіз вимог включає три види діяльності:

  • Виявлення вимог: задача комунікації з користувачами для визначення їх вимог. Також це називають збором вимог.
  • Аналіз вимог: виявлення недоліків вимог (неточностей, неповноти, неоднозначностей чи суперечностей) і їх виправлення.
  • Запис вимог: Вимоги можуть документуватись в різних формах, таких як опис звичайною мовою, прецедентами, користувацькими історіями, чи специфікаціями процесу.

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

Інженерія вимог[ред.ред. код]

Систематичний аналіз вимог також відомий як інженерія вимог.[3] Часом більш неформально її називають збором вимог, чи специфікацією вимог. Термін аналіз вимог також може застосовуватись до відповідного аналізу, в протилежність до, наприклад, збору чи документування вимог. Інженерія вимог може бути поділена на дискретні хронологічні кроки:

  • Збір вимог
  • Аналіз вимог і переговори
  • Специфікація вимог
  • Моделювання системи
  • Перевірка вимог
  • Управління вимогами

Інженерія вимог згідно з Лапланте (2007) є «піддисципліною системної інженерії та програмної інженерії яка причетна до визначення цілей, функцій та обмежень апаратних та програмних систем».[4] В деяких моделях життєвих циклів, процес інженерії вимог починається з діяльності по вивченню здійсненності, результатом якої є звіт про здійсненність. Якщо звіт припускає що продукт може бути створеним, то починається аналіз вимог. Якщо аналіз вимог передує дослідженням здійсненності, що може сприяти нестандартному мисленню, тоді здійсненність має визначитись перед завершенням аналізу вимог.

Розділи аналізу вимог[ред.ред. код]

Визначення зацікавлених сторін[ред.ред. код]

Дивіться аналіз зацікавлених сторін для опису використання в бізнесі.

Зацікавлені сторони (ЗС) це особи чи організації, які мають дійсний інтерес до системи. Вона може впливати на них прямо чи опосередковано.

Визнається, що зацікавлені сторони не обмежуються організацією що найняла аналітиків. До зацікавлених сторін також відносять:

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

Інтерв'ю з зацікавленими сторонами[ред.ред. код]

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

Спільні сесії Розробки Вимог (СРР)[ред.ред. код]

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

Сесії СРР подібні до сесій спільного проектування ПЗ. Спершу сесії виявляють вимоги які направляють дизайн, а потім виявляють властивості які мають бути реалізовані щоб задовольнити отримані вимоги.


Списки вимог в стилі контракту[ред.ред. код]

Також традиційним способом документування вимог є список вимог в стилі контракту. В складній системі такий список вимог може розтягуватись на сотні сторінок.

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

Переваги[ред.ред. код]
  • Надає чіткий попунктовий список вимог.
  • Надає контракт між спонсорами проекту, та розробниками.
  • Для великої системи може надати опис високого рівня.
Недоліки[ред.ред. код]
  • Такі списки розтягуються на сотні сторінок. Такі документи майже неможливо прочитати цілком, і отримати повне розуміння системи.
  • Такі списки абстрагують всі вимоги, тому є мало контексту
  • Їх абстракція робить неможливим побачити як вимоги сполучаються чи працюють разом.
  • Така абстракція заважає правильно розставляти пріоритети між вимогами.
  • Така абстракція збільшує подібність та ймовірність неправильної інтерпретації вимог, чим більше людей її прочитають тим більша кількість різних інтерпретацій з'явиться.
  • Така абстракція означає що надзвичайно важко впевнитись що ви маєте більшість вимог.
  • Такі списки створюють фальшиве відчуття взаємного розуміння між зацікавленими сторонами та розробниками.
  • Списки в стилі контракту дають ЗС фальшиве відчуття безпеки, що розробники мусять досягти певних речей. Тем не менш, через природу таких списків вони упускають критичні вимоги, які виявляються пізніше в процесі. Розробники можуть використати ці відкриті вимоги щоб переглянути умови договору на свою користіть.
  • Такі списки вимог не домогають в проектуванні системи
Альтернативи до списків вимог[ред.ред. код]

Як альтернатива до великих, попередньо-описаних списків вимог гнучка розробка програмного забезпечення використовує історії користувачів щоб описати вимогу в повсякденних термінах.

Вимірювані цілі[ред.ред. код]

Докладніше: Моделювання цілей

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

Прототипи[ред.ред. код]

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

Тим не менш, протягом останнього десятиліття, прототипування хоча й зарекомендувало себе як корисна техніка, але не розв'язало проблему вимог:

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

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

Прецеденти[ред.ред. код]

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

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

Специфікація вимог до програмного забезпечення[ред.ред. код]

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

Рекомендовані підходи до специфікації вимог до ПЗ описані в стандарті IEEE 830–1998. Цей стандарт описує можливі структури, бажаний вміст і якості специфікації вимог.

Типи вимог[ред.ред. код]

Вимоги категоризуються кількома способами. Нижче подана звичана категоризація вимог яка стосується технічного менеджменту:[1]

Вимоги споживача 
вирази фактів та припущень які описують очікування до системи в термінах цілей, середовища, обмежень, та міри ефективності й придатності. Споживачі це ті, хто виконують вісім первинних функцій системної інженерії, з особливим наголосом на операторі, як на ключовому споживачі. Операційні вимоги опишуть базову необхідність, і як мінімум дадуть відповідь на запитання, з даного списку:[1]
  • Операційне поширення і розгортання: Де використають систему?
  • Профіль чи сценарій місії: Як система буде виконувати свої завдання?
  • Продуктивність та пов'язані параметри: Які параметри критичні для виконання місії?
  • Використання середовища: Як будуть використовуватись різноманітні компоненти системи?
  • Вимоги ефективності: Якою ефективною має бути система для виконання своєї місії?
  • Операційний життєвий цикл: Як довго система буде використовуватись споживачем?
  • Середовище: Яких середовищ система очікує щоб працювати ефективно?
Архітектурні вимоги 
Архітектурні вимоги пояснюють що має бути зроблено ідентифікацією необхідної системної архітектури.
Структурні вимоги 
Структурні вимоги пояснюють що має бути зроблено ідентифікацією необхідної структури системи.
Поведінкові вимоги 
Поведінкові вимоги пояснюють що має бути зроблено ідентифікацією необхідної поведінки системи.
Функціональні вимоги 
Функціональні вимоги пояснюють що має бути зроблено ідентифікацією необхідної задачі, дії, чи діяльності які мають виконуватись. Аналіз функціональних вимог буде використаний в функціях верхніх рівнів для функціонального аналізу.[1]
Нефункціональні вимоги
Нефункціональні вимоги — це вимоги що задають критерій для оцінки операцій системи, замість її поведінки.
Вимоги продуктивності 
До якої міри місії чи функції повинні бути виконані; зазвичай вимірюється в термінах кількості, якості, охопленні, своєчасності чи готовності. Протягом аналізу вимог, вимоги продуктивності (як добре воно має бути зроблено) будуть інтерактнивно розроблятись вздовж всіх виявлених функції що базуються на факторах життєвого циклу системи, і характеризуються в термінах ступеня визначеності в їх оцінках, ступеня критичності успіху системи, і їх відношення до інших вимог.[1]
Вимоги дизайну
Вимоги «будувати до», «кодувати до», і «купувати до» для продуктів, і «як виконати» для процесів виражених в технічних пакетах даних та інструкціях.[1]
Успадковані вимоги
Вимоги які маються наувазі вимогами вищого рівня, чи перетворені з них. Наприклад вимога великої дальності, чи високої швидкості може спричинити вимогу дизайну малої ваги.[1]
Розподілені вимоги
Вимоги які визначені поділом, чи іншим перерозміщенням високорівневих вимог в кілька низькорівневих вимог. Наприклад стокілограмовий пристрій що складається з двох підсистем може спричинити вимоги ваги не більше 70 та 30 кілограм для конкретних систем нижчого рівня.[1]

До відомих моделей категоризації вимог належать FURPS та FURPS+, розроблені в Hewlett-Packard.

Проблеми аналізу вимог[ред.ред. код]

Проблеми з зацікавленою стороною[ред.ред. код]

Стів МакКоннел, в своїй книжці Швидка розробка, деталізує способи, якими користувачі можуть перешкоджати збору вимог:

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

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

Проблеми з інженерами/розробниками[ред.ред. код]

Можливі проблеми які можуть спричинити розробники та інженери протягом аналізу вимог:

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

Можливі рішення[ред.ред. код]

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

Технології представлені в 1990-тих такі як прототипування, Unified Modeling Language (UML), прецеденти, та Гнучка розробка програмного забезпечення також вважаються рішеннями проблем пов'язаних з попередніми методами.

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

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

Див. також[ред.ред. код]

Зноски[ред.ред. код]

  1. а б в г д е ж и Systems Engineering Fundamentals. Defense Acquisition University Press, 2001
  2. Executive editors: Alain Abran, James W. Moore; editors Pierre Bourque, Robert Dupuis, ред. (March 2005). «Chapter 2: Software Requirements». Guide to the software engineering body of knowledge (вид. 2004). Los Alamitos, CA: IEEE Computer Society Press. ISBN 0-7695-2330-7. Процитовано 2007-02-08. «It is widely acknowledged within the software industry that software engineering projects are critically vulnerable when these activities are performed poorly.» 
  3. Wiegers, Karl E. (2003). Software Requirements (вид. 2nd). Redmond, WA: Microsoft Press. ISBN 0-7356-1879-8. 
  4. Phillip A. Laplante (2007) What Every Engineer Should Know about Software Engineering. Page 44.

Література для подальшого читання[ред.ред. код]

Посилання[ред.ред. код]