Чому вам потрібно розуміти вимоги до програмного забезпечення як інженер-програміст

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

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

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

Наперед, чому це важливо?

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

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

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

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

Які вимоги до програмного забезпечення?

Вимоги до програмного забезпечення на поверхні звучать просто. Програмне забезпечення має робити X для Y, щоб Z. Подумайте над цим досить довго над будь-якою проблемою, яку могло б вирішити програмне забезпечення (або щодо існуючого програмного забезпечення, яке вже вирішує проблему), і ви, можливо, могли б продумати велику кількість вимог. Легко, правда?

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

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

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

Наскільки глибока та велика область знань? SWEBOK визначає область вимог до програмного забезпечення як " пов'язану з виявленням, аналізом, специфікацією та підтвердженням вимог до програмного забезпечення, а також управління вимогами протягом усього життєвого циклу програмного продукту ".

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

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

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

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

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

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

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

Що пов'язано з вимогами до програмного забезпечення для інженера-програміста?

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

Сфери, де ви можете брати участь:

  • Виявлення - збір вимог до програмного забезпечення
  • Класифікація - категоризація вимоги
  • Валідація - підтвердження вимоги зацікавленими сторонами
  • Розробка та впровадження - побудова програмного забезпечення для задоволення вимог
  • Переговори - вирішення конфлікту зацікавлених сторін
  • Перевірка - оцінка функції програмного забезпечення задовольняє вимогу

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

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

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

Гм, не існує системи управління вимогами ...

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

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

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

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

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

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

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

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

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

Визначення вимог до програмного забезпечення

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

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

Що бере участь у формуванні вимог до програмного забезпечення?

Залежно від рівня участі вашої ролі в процесі вимог, можливо, вам доведеться взяти вимоги з джерела.

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

Звідки беруться вимоги до програмного забезпечення?

Існує багато джерел вимог, таких як:

  • Цілі (також відомі як ділова стурбованість, критичний фактор успіху тощо)
  • Знання домену
  • Зацікавлені сторони
  • Правила ведення бізнесу
  • Операційне середовище

Якщо ви залучені до отримання з джерел, вам потрібно:

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

Як отримати вимоги до програмного забезпечення?

Деякі основні методи, якими ви можете брати участь (надання технічної експертизи), можуть бути:

  • проведення опитування зацікавлених сторін
  • окреслення сценаріїв
  • побудова прототипів
  • спостереження в проблемній зоні
  • історії користувачів

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

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

Класифікація вимог до програмного забезпечення

Після виявлення вимог до програмного забезпечення команда проекту може класифікувати їх за різними категоріями.

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

Типи класифікації можуть включати:

  • Функціональний / Нефункціональний
    • Функціональні вимоги описують функції, які має виконувати програмне забезпечення. Наприклад, надання каналу зв'язку для користувача або передача даних з одного формату в інший. Вони також можуть бути відомі як особливості або можливості продукту.
    • Нефункціональні вимоги діють для забезпечення певних обмежень на рішення, часто з точки зору якості. Вони можуть додатково класифікуватися на безліч типів " таких ", як доступність, надійність, можливість відновлення, ремонтопридатність, масштабованість, продуктивність, безпека тощо
  • Виведено / Накладено / Виникає
    • Чи вимога випливає з інших вимог?
    • Чи чітко висувається вимога зацікавленою стороною?
    • Чи є вимога властивістю, що виникає? Іншими словами, це не може бути вирішено одним компонентом, але залежить від взаємодії всіх програмних компонентів.
  • Процес / продукт
    • Чи пов'язана ця вимога з продуктом? (приклад, " Програмне забезпечення повинно перевірити право людини ")
    • Чи пов'язаний процес з вимогою? (приклад, " Програмне забезпечення має розроблятися поступово і використовувати постійні робочі процеси інтеграції та розгортання )
  • Пріоритет
    • Балансування витрат на розробку та впровадження та потреби у постачанні.
    • Може використовувати шкалу з фіксованою міткою на зразок обов’язкової, дуже бажаної, бажаної та необов’язкової.
  • Сфера дії
    • Використовується для розгляду впливу на архітектуру програмного забезпечення та конструкції компонентів.
    • Нефункціональні особи часто мають глобальний масштаб.
  • Нестабільність / стабільність
    • Потенціал вимоги зміниться протягом життєвого циклу програмного забезпечення.
    • Це допоможе реалізувати конструкції, які толерантні до змін

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

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

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

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

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

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

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

Використання функціональних прототипів

Функціональні прототипи корисні, оскільки дозволяють:

  • підтвердження того, що вимоги зрозумілі
  • полегшення інтерпретації припущень інженера
  • відгуки, які можуть забезпечити нові вимоги

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

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

Який би вибір не вирішила ваша команда, слід враховувати швидкість побудови прототипу та ефективність демонстрації основних функціональних можливостей.

Розробка та впровадження вимог до програмного забезпечення

Коли вимога буде затверджена зацікавленими сторонами, ви можете розпочати розробку / впровадження вимоги.

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

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

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

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

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

Історія користувача

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

Як, я хочу, так що

Приклад:

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

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

Можливо, історія користувача не орієнтована на користувача, а натомість походить від виникла властивості або нефункціональної вимоги. У цих випадках ви можете отримати вимогу в іншому контексті доставки (наприклад, у специфікації чи наборі сценаріїв).

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

Інженери-програмісти (обов'язково) обмежуються планами управління проектами, тому вам слід спробувати вжити заходів, щоб перевірити, що якість вимог є якомога вищою, враховуючи наявні ресурси.

Перед реалізацією історії користувача перевірте:

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

Переговори щодо вимог до програмного забезпечення

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

У більшості випадків вам нерозумно приймати одностороннє рішення.

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

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

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

Важливим завданням для вас є планування, як перевірити кожну вимогу.

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

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

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

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

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

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

Ось у двох словах

Ви це зробили. Слава вам!

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

Ви можете прочитати більше моїх статей у моєму блозі.

Ця стаття розповсюджується вільно, і автор не отримав жодного внеску чи прибутку, як це передбачено дозволами SWEBOK на авторське право та передрук. Будь-які висловлені погляди чи думки не відображають точок зору IEEE або будь-якого органу / організації, до якого я належу, не схвалюється IEEE, і представляють мою власну виключно власну думку та думки.