Аналітик вимог до програмного забезпечення

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

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

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

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

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

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

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

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

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

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

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

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

Часто краще, щоб аналітик вимог з команди розробників взаємодіяв з експертом предметної області, який крім того вибраний як ключового представника користувачів (прихильника продукту). [9]