Ана́ліз вимо́г полягає в визначенні потреб та умов, які висуваються щодо нового, чи зміненого продукту, враховуючи можливо конфліктні вимоги різних замовників, таких як користувачі чи бенефіціари.
Аналіз вимог є критичним для успішної розробки проекту.Вимоги мають бути задокументованими, вимірними, тестовними, пов'язаними з бізнес-потребами, і описаними з рівнем деталізації достатнім для конструювання системи. Вимоги можуть бути архітектурними, структурними, поведінковими, функціональними, та не функціональними.
У мові моделювання SysML вимоги моделюють за допомогою діаграми вимог, а в UML для цього інколи пристосовують діаграму прецедентів.
Огляд
Аналіз вимог включає три види діяльності:
- : задача комунікації з користувачами для визначення їх вимог. Також це називають збором вимог.
- Аналіз вимог: виявлення недоліків вимог (неточностей, неповноти, неоднозначностей чи суперечностей) і їх виправлення.
- Запис вимог: Вимоги можуть документуватись в різних формах, таких як опис звичайною мовою, прецедентами, користувацькими історіями, чи специфікаціями процесу.
Аналіз вимог може бути довгим та важким процесом що вимагає використання тонких психологічних навичок. Нові системи змінюють середовище і відношення між людьми, тому важливо розпізнати всі зацікавлені сторони, взяти до уваги всі їхні потреби, і переконатись що вони розуміють наслідки які приносить нова система. Аналітики можуть використати кілька методів щоб отримати від споживача вимоги. Історично це включає проведення інтерв'ю, чи фокус-груп (яку в цьому контексті частіше називають як майстерня вимог) і створення списків вимог. До сучасніших підходів відносять прототипування, та прецеденти. За потреби аналітик використає комбінацію цих методів щоб встановити точні вимоги зацікавлених сторін, так щоб система відповідала бізнес-потребам.
Інженерія вимог
Систематичний аналіз вимог також відомий як інженерія вимог. Часом більш неформально її називають збором вимог, чи специфікацією вимог. Термін аналіз вимог також може застосовуватись до відповідного аналізу, в протилежність до, наприклад, збору чи документування вимог. Інженерія вимог може бути поділена на дискретні хронологічні кроки:
- Збір (виявлення) вимог
- Аналіз вимог та їх узгодження
- Специфікація вимог
- Моделювання системи
- Перевірка (валідація) вимог
- Управління вимогами
Інженерія вимог згідно з Лапланте (2007) є «піддисципліною системної інженерії та програмної інженерії яка причетна до визначення цілей, функцій та обмежень апаратних та програмних систем». В деяких моделях життєвих циклів, процес інженерії вимог починається з діяльності по вивченню здійсненності, результатом якої є звіт про здійсненність. Якщо звіт припускає що продукт може бути створеним, то починається аналіз вимог. Якщо аналіз вимог передує дослідженням здійсненності, що може сприяти нестандартному мисленню, тоді здійсненність має визначитись перед завершенням аналізу вимог.
Розділи аналізу вимог
Визначення зацікавлених сторін
Зацікавлені сторони (ЗС) це особи чи організації, які мають дійсний інтерес до системи. Вона може впливати на них прямо чи опосередковано.
Визнається, що зацікавлені сторони не обмежуються організацією що найняла аналітиків. До зацікавлених сторін також відносять:
- кожного хто керуватиме системою (звичайні та обслуговуючі оператори)
- будь-кого хто отримає вигоди від системи (функціональні, політичні, фінансові та соціальні бенефіціари).
- кожен хто бере участь в придбанні чи закупці системи. В розробці продуктів для масового ринку, відділ менеджменту продукту, маркетингу, і іноді продаж діють як сурогатні споживачі щоб направляти розробку продукту.
- організації що регулюють аспекти системи (фінансові, безпеки, та інші регулятори)
- люди та організації що протистоять системі (негативні зацікавлені сторони (див. також )
- організації відповідальні за системи які будуть взаємодіяти з системою що розробляється
- ті організації які горизонтально інтегруються з організацією для якої аналітики конструюють систему
Інтерв'ю з зацікавленими сторонами
Інтерв'ю з ЗС є рядовим підходом що використовується в аналізі вимог. Ця техніка може служити як шлях отримання висококонцентрованого знання яке часто не виявляється в спільних сесіях розробки вимог, де увага зацікавленої сторони підпорядкована забезпеченню більш крос-функціонального контексту. Більш того, особистий характер інтерв'ю надає більш розслаблююче середовище де хід думок може бути детальніше пояснений.
Спільні сесії розробки вимог
Вимоги часто мають крос-функціональні наслідки, які невідомі окремим зацікавленим сторонам і часто пропускаються чи неправильно описуються протягом інтерв'ю з ЗС. Ці крос-функціональні наслідки можуть бути виявленими проведенням сесій СРР в контрольованому середовищі, стимульованому кваліфікованим посередником, де ЗС беруть участь в дискусії з метою виявлення вимог, аналізують їх деталі і розкривають крос-функціональні наслідки. Мають бути присутні спеціально призначені секретар, та бізнес-аналітик для документування дискусії. Використання навичок навченого посередника для управління дискусією звільняє бізнес-аналітика, дозволяючи йому сфокусуватись на процесі визначення вимог.
Сесії СРР подібні до сесій . Спершу сесії виявляють вимоги які направляють дизайн, а потім виявляють властивості які мають бути реалізовані щоб задовольнити отримані вимоги.
Списки вимог в стилі контракту
Також традиційним способом документування вимог є список вимог в стилі контракту. В складній системі такий список вимог може розтягуватись на сотні сторінок.
Відповідною метафорою може бути надзвичайно довгий список покупок. Такі списки не дуже цінуються в сучасному аналізі, так як вони показали малу успішність в досягненні своїх цілей. Тим не менш, Їх іноді можна побачити і сьогодні.
Переваги
- Надає чіткий попунктовий список вимог.
- Надає контракт між спонсорами проекту, та розробниками.
- Для великої системи може надати опис високого рівня.
Недоліки
- Такі списки розтягуються на сотні сторінок. Такі документи майже неможливо прочитати цілком, і отримати повне розуміння системи.
- Такі списки абстрагують всі вимоги, тому є мало контексту
- Їх абстракція робить неможливим побачити як вимоги сполучаються чи працюють разом.
- Така абстракція заважає правильно розставляти пріоритети між вимогами.
- Така абстракція збільшує подібність та ймовірність неправильної інтерпретації вимог, чим більше людей її прочитають тим більша кількість різних інтерпретацій з'явиться.
- Така абстракція означає що надзвичайно важко впевнитись що ви маєте більшість вимог.
- Такі списки створюють фальшиве відчуття взаємного розуміння між зацікавленими сторонами та розробниками.
- Списки в стилі контракту дають ЗС фальшиве відчуття безпеки, що розробники мусять досягти певних речей. Тем не менш, через природу таких списків вони упускають критичні вимоги, які виявляються пізніше в процесі. Розробники можуть використати ці відкриті вимоги щоб переглянути умови договору на свою користь.
- Такі списки вимог не допомагають в проектуванні системи
Альтернативи до списків вимог
Як альтернатива до великих, попередньо-описаних списків вимог гнучка розробка програмного забезпечення використовує історії користувачів щоб описати вимогу в повсякденних термінах.
Вимірювані цілі
беруть складений список вимог як підказку, і постійно запитують «Чому?», поки не стане зрозумілою справжня бізнес ціль. Зацікавлені сторони і розробники можуть скласти тести що вимірюють рівень досягнення цілей. Такі цілі змінюються повільніше ніж довгий список конкретних але невимірних вимог. Як тільки невеликий набір критичних, вимірних цілей буде встановлений, та короткі ітеративні фази розробки можуть продовжити приносити справжні цінності для зацікавленої сторони, задовго до середини проекту.
Прототипи
В середині 1980-тих прототипування розглядалось як найкраще рішення до проблеми аналізу вимог. Прототипи — це макети програмного забезпечення. Макети дозволяють користувачам візуалізувати ще не створений додаток . Прототипи допомагають користувачам уявити як буде виглядати система, і спростити для користувачів прийняття конструкторських рішень. Після введення прототипів спостерігаються значні покращення в комунікації між користувачами й розробниками. Раннє бачення програмного забезпечення приводить до меншої кількості змін у майбутньому і тому зменшує загальну вартість проекту.
Тим не менш, протягом останнього десятиліття, прототипування хоча й зарекомендувало себе як корисна техніка, але не розв'язало проблему вимог:
- Як тільки менеджери бачать прототип, вони перестають розуміти що проект ще не буде завершений протягом деякого часу.
- Дизайнери часто думають що змушені використовувати склеєний докупи код прототипу в реальній системі, бо вони бояться «втратити час» починаючи заново.
- Прототипи загалом допомагають в конструкторських рішеннях, та проектуванні інтерфейсу користувача. Та вони не можуть сказати які вимоги були спочатку.
- Дизайнери і кінцеві користувачі можуть занадто сфокусуватись на конструюванні інтерфейсу користувача, і занадто мало на створенні системи що виконує бізнес процес.
- Прототипи добре працюють для інтерфейсів користувача, та подій на екрані, але не дуже корисні для пакетних чи асинхронних процесів які можуть включати складні розрахунки чи запити до даних.
Прототипи можуть бути плоскими діаграмами (які часто називаються каркасними моделями), чи робочими додатками що використовують синтезовану функціональність. Каркасні моделі створюються в різноманітних графічних , і часто видаляють увесь колір з дизайну (використовують чорно-білу палітру) в випадках колір з дизайну (використовують чорно-білу палітру) в випадках коли кінцеве ПЗ буде мати відповідний графічний дизайн. Це допомагає уникнути плутанини між концептом програми в дизайн-документі, та її кінцевим виглядом.
Прецеденти
Прецеденти це технологія документування потенційних вимог до нової, чи зміненої програмної системи. Кожен прецедент надає один чи більше сценаріїв які виражають те, як система взаємодіє з користувачем чи іншою системою щоб досягти конкретної бізнес цілі. Прецеденти зазвичай уникають технічного жаргону, віддаючи перевагу мові кінцевого користувача чи експерта в предметній області. Інженери вимог та ЗС часто виступають співавторами прецедентів.
Прецеденти є оманливо простими інструментами для опису поведінки системи. Прецедент містить текстовий опис всіх способів якими користувачі можуть працювати з програмним забезпеченням. Прецеденти не описують жодних внутрішніх процесів у системі, і не пояснюють як система має реалізовуватись. Вони просто показують кроки які користувач має здійснити щоб виконати свою задачу. Так можна описати всі способи взаємодії з системою.
Специфікація вимог до програмного забезпечення
Специфікація вимог до програмного забезпечення (SRS) — це повний опис поведінки системи що розробляється. Він включає набір прецедентів, що описують всі взаємодії користувача з системою. Прецеденти також відомі як функціональні вимоги. На додачу до прецедентів, SRS також містить нефункціональні (чи додаткові вимоги). Нефункціональні вимоги є вимогами які накладають обмеження на проект, чи реалізацію (такі як вимоги інженерії продуктивності, стандарти якості, чи обмеження проектування).
Рекомендовані підходи до специфікації вимог до ПЗ описані в стандарті IEEE 830–1998. Цей стандарт описує можливі структури, бажаний вміст і якості специфікації вимог.
Типи вимог
Вимоги категоризуються кількома способами. Нижче подана звичайна категоризація вимог яка стосується технічного менеджменту:
- Вимоги споживача
- вирази фактів та припущень які описують очікування до системи в термінах цілей, середовища, обмежень, та міри ефективності й придатності. Споживачі це ті, хто виконують вісім первинних функцій системної інженерії, з особливим наголосом на операторі, як на ключовому споживачі. Операційні вимоги опишуть базову необхідність, і як мінімум дадуть відповідь на запитання, з даного списку:
- Операційне поширення і розгортання: Де використають систему?
- Профіль чи сценарій місії: Як система буде виконувати свої завдання?
- Продуктивність та пов'язані параметри: Які параметри критичні для виконання місії?
- Використання середовища: Як будуть використовуватись різноманітні компоненти системи?
- Вимоги ефективності: Якою ефективною має бути система для виконання своєї місії?
- Операційний життєвий цикл: Як довго система буде використовуватись споживачем?
- Середовище: Яких середовищ система очікує щоб працювати ефективно?
- Архітектурні вимоги
- Архітектурні вимоги пояснюють що має бути зроблено ідентифікацією необхідної системної архітектури.
- Структурні вимоги
- Структурні вимоги пояснюють що має бути зроблено ідентифікацією необхідної структури системи.
- Поведінкові вимоги
- Поведінкові вимоги пояснюють що має бути зроблено ідентифікацією необхідної поведінки системи.
- Функціональні вимоги
- Функціональні вимоги пояснюють що має бути зроблено ідентифікацією необхідної задачі, дії, чи діяльності які мають виконуватись. Аналіз функціональних вимог буде використаний в функціях верхніх рівнів для функціонального аналізу.
- Нефункціональні вимоги
- Нефункціональні вимоги — це вимоги що задають критерій для оцінки операцій системи, замість її поведінки.
- Вимоги продуктивності
- До якої міри місії чи функції повинні бути виконані; зазвичай вимірюється в термінах кількості, якості, охопленні, своєчасності чи готовності. Протягом аналізу вимог, вимоги продуктивності (як добре воно має бути зроблено) будуть інтерактнивно розроблятись вздовж всіх виявлених функції що базуються на факторах життєвого циклу системи, і характеризуються в термінах ступеня визначеності в їх оцінках, ступеня критичності успіху системи, і їх відношення до інших вимог.
- Вимоги дизайну
- Вимоги «будувати до», «кодувати до», і «купувати до» для продуктів, і «як виконати» для процесів виражених в технічних пакетах даних та інструкціях.
- Успадковані вимоги
- Вимоги які маються на увазі вимогами вищого рівня, чи перетворені з них. Наприклад вимога великої дальності, чи високої швидкості може спричинити вимогу дизайну малої ваги.
- Розподілені вимоги
- Вимоги які визначені поділом, чи іншим перерозміщенням високорівневих вимог в кілька низькорівневих вимог. Наприклад стокілограмовий пристрій що складається з двох підсистем може спричинити вимоги ваги не більше 70 та 30 кілограм для конкретних систем нижчого рівня.
До відомих моделей категоризації вимог належать FURPS та FURPS+, розроблені в Hewlett-Packard.
Проблеми аналізу вимог
Правильно визначені вимоги до програмного проєкту має надзвичайно велике значення для його успіху. Дослідження Роберта Гласа (англ. Robert Glass) декількох провалених проєктів свідчать, що невірно визначені вимоги є чи не головною причиною їх невдач. Чим далі просувається робота над проєктом, тим важче і дорожче виправити помилки, допущені при визначені вимог до проєкту.
Проблеми з зацікавленою стороною
Стів МакКоннел, в своїй книжці Швидка розробка, деталізує способи, якими користувачі можуть перешкоджати збору вимог:
- Користувачі не розуміють чого їм треба, чи не мають чіткого уявлення про свої вимоги
- Користувачі не вкладуть нічого в набір письмових вимог
- Користувачі наполягають на нових вимогах після фіксації ціни та графіку розробки
- Спілкування з користувачами відбувається повільно
- Користувачі часто не беруть участі у оглядах чи не мають змоги брати участь
- Користувачі неграмотні технічно
- Користувачі не розуміють процес розробки
- Користувачі не знають про сучасні технології
Це може привести до ситуації в якій вимоги користувача продовжують змінюватись навіть коли почалась розробка.
Проблеми з інженерами/розробниками
Можливі проблеми які можуть спричинити розробники та інженери протягом аналізу вимог:
- Технічний персонал та кінцеві користувачі можуть говорити різними мовами. Вони можуть помилково вірити в те, що вони перебувають в ідеальній згоді, поки не буде наданий закінчений продукт.
- Інженери та розробники можуть спробувати зробити вимоги які підходять до існуючої системи чи моделі, замість того щоб розробляти систему спеціально під потреби клієнта.
- Аналіз часто може проводитись інженерами чи програмістами, а не персоналом з навичками комунікації та знанням предменної області для правильного розуміння потреб клієнта.
Можливі рішення
Одне з можливих рішень в проблемі комунікації — найняти спеціаліста з бізнес-аналізу чи системного аналізу.
Технології представлені в 1990-тих такі як , Unified Modeling Language (UML), прецеденти, та Гнучка розробка програмного забезпечення також вважаються рішеннями проблем пов'язаних з попередніми методами.
Також, на ринок вийшов новий клас інструментів симуляції програмного забезпечення чи інструментів опису ПЗ. Ці інструменти створені як міст через комунікаційний розрив між користувачами та IT — фірмами, і дозволяють додаткам(ПЗ) бути «випробуваними ринком» перед тим як з'явиться перший код. Найкращі з цих інструментів надають:
- електронні дошки для малювання ескізів процесів додатку та тестових альтернатив
- здатність фіксувати бізнес логіку та потреби даних
- здатність генерувати високоякісні прототипи які близько імітують кінцевий продукт
- здатність додавати контекстуальні вимоги та інші коментарі
- здатність для віддалених та розподілених користувачів запускати та взаємодіяти з симуляцією
Проте залишається основна проблема: обмеженість інформації та знань учасниками процесу формулювання вимог, можливі конфлікти інтересів між ними та нездатність вірно виставити пріоритети.
Див. також
Примітки
- Executive editors: Alain Abran, James W. Moore; editors Pierre Bourque, Robert Dupuis, ред. (March 2005). . Guide to the software engineering body of knowledge (вид. 2004). Los Alamitos, CA: IEEE Computer Society Press. ISBN . Архів оригіналу за 23 березня 2009. Процитовано 8 лютого 2007.
It is widely acknowledged within the software industry that software engineering projects are critically vulnerable when these activities are performed poorly.
- Jon Holt, Simon Perry (2008). 4.9 Requirement diagrams (structural). SysML for Systems Engineering. The Institution of Engineering and Technology. ISBN .
- Wiegers, Karl E. (2003). (вид. 2nd). Redmond, WA: Microsoft Press. ISBN . Архів оригіналу за 5 травня 2021. Процитовано 28 жовтня 2010.
- Phillip A. Laplante (2007) What Every Engineer Should Know about Software Engineering. Page 44.
- Systems Engineering Fundamentals. [ 22 липня 2011 у Wayback Machine.] Defense Acquisition University Press, 2001
- Albert Endres, Dieter Rombach (2003). 2.3.1 Glass’ law. A Handbook of Software and Systems Engineering. Pearson. ISBN .
- (Enders, Rombach; розділ 2.3.2 Boehm's first law)
Література для подальшого читання
- Laplante, Phil (2009). (вид. 1st). Redmond, WA: CRC Press. ISBN . Архів оригіналу за 8 липня 2011. Процитовано 28 жовтня 2010.
- McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules (вид. 1st). Redmond, WA: Microsoft Press. ISBN .
- Wiegers, Karl E. (2003). (вид. 2nd). Redmond, WA: Microsoft Press. ISBN . Архів оригіналу за 5 травня 2021. Процитовано 28 жовтня 2010.
- Andrew Stellman and Jennifer Greene (2005). . Cambridge, MA: O'Reilly Media. ISBN . Архів оригіналу за 25 травня 2021. Процитовано 23 травня 2022.
- Brian Berenbach, Daniel Paulish, Juergen Katzmeier, Arnold Rudorfer (2009). . New York: McGraw-Hill Professional. ISBN . Архів оригіналу за 9 травня 2021. Процитовано 23 травня 2022.
- Walter Sobkiw (2008). . New Jersey: CassBeth. ISBN . Архів оригіналу за 23 січня 2020. Процитовано 28 жовтня 2010.
Посилання
Вікісховище має мультимедійні дані за темою: Аналіз вимог |
- Requirements Engineering Process «Goodies» [ 23 листопада 2008 у Wayback Machine.]
- Requirements Engineering: A Roadmap [ 7 червня 2011 у Wayback Machine.] (PDF) article by Bashar Nuseibeh and Steve Easterbrook, 2000.
Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет
Ana liz vimo g polyagaye v viznachenni potreb ta umov yaki visuvayutsya shodo novogo chi zminenogo produktu vrahovuyuchi mozhlivo konfliktni vimogi riznih zamovnikiv takih yak koristuvachi chi beneficiari Analiz vimog ye kritichnim dlya uspishnoyi rozrobki proektu Vimogi mayut buti zadokumentovanimi vimirnimi testovnimi pov yazanimi z biznes potrebami i opisanimi z rivnem detalizaciyi dostatnim dlya konstruyuvannya sistemi Vimogi mozhut buti arhitekturnimi strukturnimi povedinkovimi funkcionalnimi ta ne funkcionalnimi U movi modelyuvannya SysML vimogi modelyuyut za dopomogoyu diagrami vimog a v UML dlya cogo inkoli pristosovuyut diagramu precedentiv OglyadAnaliz vimog vklyuchaye tri vidi diyalnosti zadacha komunikaciyi z koristuvachami dlya viznachennya yih vimog Takozh ce nazivayut zborom vimog Analiz vimog viyavlennya nedolikiv vimog netochnostej nepovnoti neodnoznachnostej chi superechnostej i yih vipravlennya Zapis vimog Vimogi mozhut dokumentuvatis v riznih formah takih yak opis zvichajnoyu movoyu precedentami koristuvackimi istoriyami chi specifikaciyami procesu Analiz vimog mozhe buti dovgim ta vazhkim procesom sho vimagaye vikoristannya tonkih psihologichnih navichok Novi sistemi zminyuyut seredovishe i vidnoshennya mizh lyudmi tomu vazhlivo rozpiznati vsi zacikavleni storoni vzyati do uvagi vsi yihni potrebi i perekonatis sho voni rozumiyut naslidki yaki prinosit nova sistema Analitiki mozhut vikoristati kilka metodiv shob otrimati vid spozhivacha vimogi Istorichno ce vklyuchaye provedennya interv yu chi fokus grup yaku v comu konteksti chastishe nazivayut yak majsternya vimog i stvorennya spiskiv vimog Do suchasnishih pidhodiv vidnosyat prototipuvannya ta precedenti Za potrebi analitik vikoristaye kombinaciyu cih metodiv shob vstanoviti tochni vimogi zacikavlenih storin tak shob sistema vidpovidala biznes potrebam Inzheneriya vimogSistematichnij analiz vimog takozh vidomij yak inzheneriya vimog Chasom bilsh neformalno yiyi nazivayut zborom vimog chi specifikaciyeyu vimog Termin analiz vimog takozh mozhe zastosovuvatis do vidpovidnogo analizu v protilezhnist do napriklad zboru chi dokumentuvannya vimog Inzheneriya vimog mozhe buti podilena na diskretni hronologichni kroki Zbir viyavlennya vimog Analiz vimog ta yih uzgodzhennya Specifikaciya vimog Modelyuvannya sistemi Perevirka validaciya vimog Upravlinnya vimogami Inzheneriya vimog zgidno z Laplante 2007 ye piddisciplinoyu sistemnoyi inzheneriyi ta programnoyi inzheneriyi yaka prichetna do viznachennya cilej funkcij ta obmezhen aparatnih ta programnih sistem V deyakih modelyah zhittyevih cikliv proces inzheneriyi vimog pochinayetsya z diyalnosti po vivchennyu zdijsnennosti rezultatom yakoyi ye zvit pro zdijsnennist Yaksho zvit pripuskaye sho produkt mozhe buti stvorenim to pochinayetsya analiz vimog Yaksho analiz vimog pereduye doslidzhennyam zdijsnennosti sho mozhe spriyati nestandartnomu mislennyu todi zdijsnennist maye viznachitis pered zavershennyam analizu vimog Rozdili analizu vimogViznachennya zacikavlenih storin Zacikavleni storoni ZS ce osobi chi organizaciyi yaki mayut dijsnij interes do sistemi Vona mozhe vplivati na nih pryamo chi oposeredkovano Viznayetsya sho zacikavleni storoni ne obmezhuyutsya organizaciyeyu sho najnyala analitikiv Do zacikavlenih storin takozh vidnosyat kozhnogo hto keruvatime sistemoyu zvichajni ta obslugovuyuchi operatori bud kogo hto otrimaye vigodi vid sistemi funkcionalni politichni finansovi ta socialni beneficiari kozhen hto bere uchast v pridbanni chi zakupci sistemi V rozrobci produktiv dlya masovogo rinku viddil menedzhmentu produktu marketingu i inodi prodazh diyut yak surogatni spozhivachi shob napravlyati rozrobku produktu organizaciyi sho regulyuyut aspekti sistemi finansovi bezpeki ta inshi regulyatori lyudi ta organizaciyi sho protistoyat sistemi negativni zacikavleni storoni div takozh organizaciyi vidpovidalni za sistemi yaki budut vzayemodiyati z sistemoyu sho rozroblyayetsya ti organizaciyi yaki gorizontalno integruyutsya z organizaciyeyu dlya yakoyi analitiki konstruyuyut sistemuInterv yu z zacikavlenimi storonami Interv yu z ZS ye ryadovim pidhodom sho vikoristovuyetsya v analizi vimog Cya tehnika mozhe sluzhiti yak shlyah otrimannya visokokoncentrovanogo znannya yake chasto ne viyavlyayetsya v spilnih sesiyah rozrobki vimog de uvaga zacikavlenoyi storoni pidporyadkovana zabezpechennyu bilsh kros funkcionalnogo kontekstu Bilsh togo osobistij harakter interv yu nadaye bilsh rozslablyuyuche seredovishe de hid dumok mozhe buti detalnishe poyasnenij Spilni sesiyi rozrobki vimog Vimogi chasto mayut kros funkcionalni naslidki yaki nevidomi okremim zacikavlenim storonam i chasto propuskayutsya chi nepravilno opisuyutsya protyagom interv yu z ZS Ci kros funkcionalni naslidki mozhut buti viyavlenimi provedennyam sesij SRR v kontrolovanomu seredovishi stimulovanomu kvalifikovanim poserednikom de ZS berut uchast v diskusiyi z metoyu viyavlennya vimog analizuyut yih detali i rozkrivayut kros funkcionalni naslidki Mayut buti prisutni specialno priznacheni sekretar ta biznes analitik dlya dokumentuvannya diskusiyi Vikoristannya navichok navchenogo poserednika dlya upravlinnya diskusiyeyu zvilnyaye biznes analitika dozvolyayuchi jomu sfokusuvatis na procesi viznachennya vimog Sesiyi SRR podibni do sesij Spershu sesiyi viyavlyayut vimogi yaki napravlyayut dizajn a potim viyavlyayut vlastivosti yaki mayut buti realizovani shob zadovolniti otrimani vimogi Spiski vimog v stili kontraktu Takozh tradicijnim sposobom dokumentuvannya vimog ye spisok vimog v stili kontraktu V skladnij sistemi takij spisok vimog mozhe roztyaguvatis na sotni storinok Vidpovidnoyu metaforoyu mozhe buti nadzvichajno dovgij spisok pokupok Taki spiski ne duzhe cinuyutsya v suchasnomu analizi tak yak voni pokazali malu uspishnist v dosyagnenni svoyih cilej Tim ne mensh Yih inodi mozhna pobachiti i sogodni Perevagi Nadaye chitkij popunktovij spisok vimog Nadaye kontrakt mizh sponsorami proektu ta rozrobnikami Dlya velikoyi sistemi mozhe nadati opis visokogo rivnya Nedoliki Taki spiski roztyaguyutsya na sotni storinok Taki dokumenti majzhe nemozhlivo prochitati cilkom i otrimati povne rozuminnya sistemi Taki spiski abstraguyut vsi vimogi tomu ye malo kontekstuYih abstrakciya robit nemozhlivim pobachiti yak vimogi spoluchayutsya chi pracyuyut razom Taka abstrakciya zavazhaye pravilno rozstavlyati prioriteti mizh vimogami Taka abstrakciya zbilshuye podibnist ta jmovirnist nepravilnoyi interpretaciyi vimog chim bilshe lyudej yiyi prochitayut tim bilsha kilkist riznih interpretacij z yavitsya Taka abstrakciya oznachaye sho nadzvichajno vazhko vpevnitis sho vi mayete bilshist vimog Taki spiski stvoryuyut falshive vidchuttya vzayemnogo rozuminnya mizh zacikavlenimi storonami ta rozrobnikami Spiski v stili kontraktu dayut ZS falshive vidchuttya bezpeki sho rozrobniki musyat dosyagti pevnih rechej Tem ne mensh cherez prirodu takih spiskiv voni upuskayut kritichni vimogi yaki viyavlyayutsya piznishe v procesi Rozrobniki mozhut vikoristati ci vidkriti vimogi shob pereglyanuti umovi dogovoru na svoyu korist Taki spiski vimog ne dopomagayut v proektuvanni sistemiAlternativi do spiskiv vimog Yak alternativa do velikih poperedno opisanih spiskiv vimog gnuchka rozrobka programnogo zabezpechennya vikoristovuye istoriyi koristuvachiv shob opisati vimogu v povsyakdennih terminah Vimiryuvani cili Dokladnishe berut skladenij spisok vimog yak pidkazku i postijno zapituyut Chomu poki ne stane zrozumiloyu spravzhnya biznes cil Zacikavleni storoni i rozrobniki mozhut sklasti testi sho vimiryuyut riven dosyagnennya cilej Taki cili zminyuyutsya povilnishe nizh dovgij spisok konkretnih ale nevimirnih vimog Yak tilki nevelikij nabir kritichnih vimirnih cilej bude vstanovlenij ta korotki iterativni fazi rozrobki mozhut prodovzhiti prinositi spravzhni cinnosti dlya zacikavlenoyi storoni zadovgo do seredini proektu Prototipi V seredini 1980 tih prototipuvannya rozglyadalos yak najkrashe rishennya do problemi analizu vimog Prototipi ce maketi programnogo zabezpechennya Maketi dozvolyayut koristuvacham vizualizuvati she ne stvorenij dodatok Prototipi dopomagayut koristuvacham uyaviti yak bude viglyadati sistema i sprostiti dlya koristuvachiv prijnyattya konstruktorskih rishen Pislya vvedennya prototipiv sposterigayutsya znachni pokrashennya v komunikaciyi mizh koristuvachami j rozrobnikami Rannye bachennya programnogo zabezpechennya privodit do menshoyi kilkosti zmin u majbutnomu i tomu zmenshuye zagalnu vartist proektu Tim ne mensh protyagom ostannogo desyatilittya prototipuvannya hocha j zarekomenduvalo sebe yak korisna tehnika ale ne rozv yazalo problemu vimog Yak tilki menedzheri bachat prototip voni perestayut rozumiti sho proekt she ne bude zavershenij protyagom deyakogo chasu Dizajneri chasto dumayut sho zmusheni vikoristovuvati skleyenij dokupi kod prototipu v realnij sistemi bo voni boyatsya vtratiti chas pochinayuchi zanovo Prototipi zagalom dopomagayut v konstruktorskih rishennyah ta proektuvanni interfejsu koristuvacha Ta voni ne mozhut skazati yaki vimogi buli spochatku Dizajneri i kincevi koristuvachi mozhut zanadto sfokusuvatis na konstruyuvanni interfejsu koristuvacha i zanadto malo na stvorenni sistemi sho vikonuye biznes proces Prototipi dobre pracyuyut dlya interfejsiv koristuvacha ta podij na ekrani ale ne duzhe korisni dlya paketnih chi asinhronnih procesiv yaki mozhut vklyuchati skladni rozrahunki chi zapiti do danih Prototipi mozhut buti ploskimi diagramami yaki chasto nazivayutsya karkasnimi modelyami chi robochimi dodatkami sho vikoristovuyut sintezovanu funkcionalnist Karkasni modeli stvoryuyutsya v riznomanitnih grafichnih i chasto vidalyayut uves kolir z dizajnu vikoristovuyut chorno bilu palitru v vipadkah kolir z dizajnu vikoristovuyut chorno bilu palitru v vipadkah koli kinceve PZ bude mati vidpovidnij grafichnij dizajn Ce dopomagaye uniknuti plutanini mizh konceptom programi v dizajn dokumenti ta yiyi kincevim viglyadom Precedenti Dokladnishe Precedent programuvannya Precedenti ce tehnologiya dokumentuvannya potencijnih vimog do novoyi chi zminenoyi programnoyi sistemi Kozhen precedent nadaye odin chi bilshe scenariyiv yaki virazhayut te yak sistema vzayemodiye z koristuvachem chi inshoyu sistemoyu shob dosyagti konkretnoyi biznes cili Precedenti zazvichaj unikayut tehnichnogo zhargonu viddayuchi perevagu movi kincevogo koristuvacha chi eksperta v predmetnij oblasti Inzheneri vimog ta ZS chasto vistupayut spivavtorami precedentiv Precedenti ye omanlivo prostimi instrumentami dlya opisu povedinki sistemi Precedent mistit tekstovij opis vsih sposobiv yakimi koristuvachi mozhut pracyuvati z programnim zabezpechennyam Precedenti ne opisuyut zhodnih vnutrishnih procesiv u sistemi i ne poyasnyuyut yak sistema maye realizovuvatis Voni prosto pokazuyut kroki yaki koristuvach maye zdijsniti shob vikonati svoyu zadachu Tak mozhna opisati vsi sposobi vzayemodiyi z sistemoyu Specifikaciya vimog do programnogo zabezpechennya Dokladnishe Specifikaciya vimog do programnogo zabezpechennya Specifikaciya vimog do programnogo zabezpechennya SRS ce povnij opis povedinki sistemi sho rozroblyayetsya Vin vklyuchaye nabir precedentiv sho opisuyut vsi vzayemodiyi koristuvacha z sistemoyu Precedenti takozh vidomi yak funkcionalni vimogi Na dodachu do precedentiv SRS takozh mistit nefunkcionalni chi dodatkovi vimogi Nefunkcionalni vimogi ye vimogami yaki nakladayut obmezhennya na proekt chi realizaciyu taki yak vimogi inzheneriyi produktivnosti standarti yakosti chi obmezhennya proektuvannya Rekomendovani pidhodi do specifikaciyi vimog do PZ opisani v standarti IEEE 830 1998 Cej standart opisuye mozhlivi strukturi bazhanij vmist i yakosti specifikaciyi vimog Tipi vimogVimogi kategorizuyutsya kilkoma sposobami Nizhche podana zvichajna kategorizaciya vimog yaka stosuyetsya tehnichnogo menedzhmentu Vimogi spozhivacha virazi faktiv ta pripushen yaki opisuyut ochikuvannya do sistemi v terminah cilej seredovisha obmezhen ta miri efektivnosti j pridatnosti Spozhivachi ce ti hto vikonuyut visim pervinnih funkcij sistemnoyi inzheneriyi z osoblivim nagolosom na operatori yak na klyuchovomu spozhivachi Operacijni vimogi opishut bazovu neobhidnist i yak minimum dadut vidpovid na zapitannya z danogo spisku Operacijne poshirennya i rozgortannya De vikoristayut sistemu Profil chi scenarij misiyi Yak sistema bude vikonuvati svoyi zavdannya Produktivnist ta pov yazani parametri Yaki parametri kritichni dlya vikonannya misiyi Vikoristannya seredovisha Yak budut vikoristovuvatis riznomanitni komponenti sistemi Vimogi efektivnosti Yakoyu efektivnoyu maye buti sistema dlya vikonannya svoyeyi misiyi Operacijnij zhittyevij cikl Yak dovgo sistema bude vikoristovuvatis spozhivachem Seredovishe Yakih seredovish sistema ochikuye shob pracyuvati efektivno Arhitekturni vimogi Arhitekturni vimogi poyasnyuyut sho maye buti zrobleno identifikaciyeyu neobhidnoyi sistemnoyi arhitekturi Strukturni vimogi Strukturni vimogi poyasnyuyut sho maye buti zrobleno identifikaciyeyu neobhidnoyi strukturi sistemi Povedinkovi vimogi Povedinkovi vimogi poyasnyuyut sho maye buti zrobleno identifikaciyeyu neobhidnoyi povedinki sistemi Funkcionalni vimogi Funkcionalni vimogi poyasnyuyut sho maye buti zrobleno identifikaciyeyu neobhidnoyi zadachi diyi chi diyalnosti yaki mayut vikonuvatis Analiz funkcionalnih vimog bude vikoristanij v funkciyah verhnih rivniv dlya funkcionalnogo analizu Nefunkcionalni vimogi Nefunkcionalni vimogi ce vimogi sho zadayut kriterij dlya ocinki operacij sistemi zamist yiyi povedinki Vimogi produktivnosti Do yakoyi miri misiyi chi funkciyi povinni buti vikonani zazvichaj vimiryuyetsya v terminah kilkosti yakosti ohoplenni svoyechasnosti chi gotovnosti Protyagom analizu vimog vimogi produktivnosti yak dobre vono maye buti zrobleno budut interaktnivno rozroblyatis vzdovzh vsih viyavlenih funkciyi sho bazuyutsya na faktorah zhittyevogo ciklu sistemi i harakterizuyutsya v terminah stupenya viznachenosti v yih ocinkah stupenya kritichnosti uspihu sistemi i yih vidnoshennya do inshih vimog Vimogi dizajnu Vimogi buduvati do koduvati do i kupuvati do dlya produktiv i yak vikonati dlya procesiv virazhenih v tehnichnih paketah danih ta instrukciyah Uspadkovani vimogi Vimogi yaki mayutsya na uvazi vimogami vishogo rivnya chi peretvoreni z nih Napriklad vimoga velikoyi dalnosti chi visokoyi shvidkosti mozhe sprichiniti vimogu dizajnu maloyi vagi Rozpodileni vimogi Vimogi yaki viznacheni podilom chi inshim pererozmishennyam visokorivnevih vimog v kilka nizkorivnevih vimog Napriklad stokilogramovij pristrij sho skladayetsya z dvoh pidsistem mozhe sprichiniti vimogi vagi ne bilshe 70 ta 30 kilogram dlya konkretnih sistem nizhchogo rivnya Do vidomih modelej kategorizaciyi vimog nalezhat FURPS ta FURPS rozrobleni v Hewlett Packard Problemi analizu vimogPravilno viznacheni vimogi do programnogo proyektu maye nadzvichajno velike znachennya dlya jogo uspihu Doslidzhennya Roberta Glasa angl Robert Glass dekilkoh provalenih proyektiv svidchat sho nevirno viznacheni vimogi ye chi ne golovnoyu prichinoyu yih nevdach Chim dali prosuvayetsya robota nad proyektom tim vazhche i dorozhche vipraviti pomilki dopusheni pri viznacheni vimog do proyektu Problemi z zacikavlenoyu storonoyu Stiv MakKonnel v svoyij knizhci Shvidka rozrobka detalizuye sposobi yakimi koristuvachi mozhut pereshkodzhati zboru vimog Koristuvachi ne rozumiyut chogo yim treba chi ne mayut chitkogo uyavlennya pro svoyi vimogi Koristuvachi ne vkladut nichogo v nabir pismovih vimog Koristuvachi napolyagayut na novih vimogah pislya fiksaciyi cini ta grafiku rozrobki Spilkuvannya z koristuvachami vidbuvayetsya povilno Koristuvachi chasto ne berut uchasti u oglyadah chi ne mayut zmogi brati uchast Koristuvachi negramotni tehnichno Koristuvachi ne rozumiyut proces rozrobki Koristuvachi ne znayut pro suchasni tehnologiyi Ce mozhe privesti do situaciyi v yakij vimogi koristuvacha prodovzhuyut zminyuvatis navit koli pochalas rozrobka Problemi z inzhenerami rozrobnikami Mozhlivi problemi yaki mozhut sprichiniti rozrobniki ta inzheneri protyagom analizu vimog Tehnichnij personal ta kincevi koristuvachi mozhut govoriti riznimi movami Voni mozhut pomilkovo viriti v te sho voni perebuvayut v idealnij zgodi poki ne bude nadanij zakinchenij produkt Inzheneri ta rozrobniki mozhut sprobuvati zrobiti vimogi yaki pidhodyat do isnuyuchoyi sistemi chi modeli zamist togo shob rozroblyati sistemu specialno pid potrebi kliyenta Analiz chasto mozhe provoditis inzhenerami chi programistami a ne personalom z navichkami komunikaciyi ta znannyam predmennoyi oblasti dlya pravilnogo rozuminnya potreb kliyenta Mozhlivi rishennya Odne z mozhlivih rishen v problemi komunikaciyi najnyati specialista z biznes analizu chi sistemnogo analizu Tehnologiyi predstavleni v 1990 tih taki yak Unified Modeling Language UML precedenti ta Gnuchka rozrobka programnogo zabezpechennya takozh vvazhayutsya rishennyami problem pov yazanih z poperednimi metodami Takozh na rinok vijshov novij klas instrumentiv simulyaciyi programnogo zabezpechennya chi instrumentiv opisu PZ Ci instrumenti stvoreni yak mist cherez komunikacijnij rozriv mizh koristuvachami ta IT firmami i dozvolyayut dodatkam PZ buti viprobuvanimi rinkom pered tim yak z yavitsya pershij kod Najkrashi z cih instrumentiv nadayut elektronni doshki dlya malyuvannya eskiziv procesiv dodatku ta testovih alternativ zdatnist fiksuvati biznes logiku ta potrebi danih zdatnist generuvati visokoyakisni prototipi yaki blizko imituyut kincevij produkt zdatnist dodavati kontekstualni vimogi ta inshi komentari zdatnist dlya viddalenih ta rozpodilenih koristuvachiv zapuskati ta vzayemodiyati z simulyaciyeyu Prote zalishayetsya osnovna problema obmezhenist informaciyi ta znan uchasnikami procesu formulyuvannya vimog mozhlivi konflikti interesiv mizh nimi ta nezdatnist virno vistaviti prioriteti Div takozhVimogi do programnogo zabezpechennya Diagrama vimog Funkcionalni vimogi Nefunkcionalni vimogi Specifikaciya vimog do programnogo zabezpechennyaPrimitkiExecutive editors Alain Abran James W Moore editors Pierre Bourque Robert Dupuis red March 2005 Guide to the software engineering body of knowledge vid 2004 Los Alamitos CA IEEE Computer Society Press ISBN 0 7695 2330 7 Arhiv originalu za 23 bereznya 2009 Procitovano 8 lyutogo 2007 It is widely acknowledged within the software industry that software engineering projects are critically vulnerable when these activities are performed poorly Jon Holt Simon Perry 2008 4 9 Requirement diagrams structural SysML for Systems Engineering The Institution of Engineering and Technology ISBN 978 0 86341 825 9 Wiegers Karl E 2003 vid 2nd Redmond WA Microsoft Press ISBN 0 7356 1879 8 Arhiv originalu za 5 travnya 2021 Procitovano 28 zhovtnya 2010 Phillip A Laplante 2007 What Every Engineer Should Know about Software Engineering Page 44 Systems Engineering Fundamentals 22 lipnya 2011 u Wayback Machine Defense Acquisition University Press 2001 Albert Endres Dieter Rombach 2003 2 3 1 Glass law A Handbook of Software and Systems Engineering Pearson ISBN 0 321 15420 7 Enders Rombach rozdil 2 3 2 Boehm s first law Literatura dlya podalshogo chitannyaLaplante Phil 2009 vid 1st Redmond WA CRC Press ISBN 1 42006 467 3 Arhiv originalu za 8 lipnya 2011 Procitovano 28 zhovtnya 2010 McConnell Steve 1996 Rapid Development Taming Wild Software Schedules vid 1st Redmond WA Microsoft Press ISBN 1 55615 900 5 Wiegers Karl E 2003 vid 2nd Redmond WA Microsoft Press ISBN 0 7356 1879 8 Arhiv originalu za 5 travnya 2021 Procitovano 28 zhovtnya 2010 Andrew Stellman and Jennifer Greene 2005 Cambridge MA O Reilly Media ISBN 0 596 00948 8 Arhiv originalu za 25 travnya 2021 Procitovano 23 travnya 2022 Brian Berenbach Daniel Paulish Juergen Katzmeier Arnold Rudorfer 2009 New York McGraw Hill Professional ISBN 0 07 1605479 Arhiv originalu za 9 travnya 2021 Procitovano 23 travnya 2022 Walter Sobkiw 2008 New Jersey CassBeth ISBN 0615216307 Arhiv originalu za 23 sichnya 2020 Procitovano 28 zhovtnya 2010 PosilannyaVikishovishe maye multimedijni dani za temoyu Analiz vimogRequirements Engineering Process Goodies 23 listopada 2008 u Wayback Machine Requirements Engineering A Roadmap 7 chervnya 2011 u Wayback Machine PDF article by Bashar Nuseibeh and Steve Easterbrook 2000