Що таке аналіз та збір вимог у SDLC?

what is requirement analysis

Цей підручник пояснює, що таке аналіз вимог, етапи аналізу вимог, приклади та цілі збору вимог у SDLC:

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

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

Що ви дізнаєтесь:

• Що таке аналіз вимог?
  • Етапи / кроки аналізу вимог
    • # 1) Збір вимог
    • # 2) Аналіз зібраних вимог
    • # 3) Документування аналізованих вимог
  • Перетворення бізнес-вимог на вимоги до програмного забезпечення
  • Розуміння випадків нефункціональних вимог
  • Різниця між вимогами бізнесу та вимогами програмного забезпечення
• Висновок
  • Рекомендована література

Що таке аналіз вимог?

Давайте зрозуміємо Аналіз вимог на прикладі.

Очікування клієнта / кінцевого користувача:

Клієнт / Кінцевий користувач отримує:

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

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

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

Етапи / кроки аналізу вимог

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

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

Аналіз вимог починається з:

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

# 1) Збір вимог

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

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

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

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

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

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

Створення цього прототипу залежить від двох типів продукції:

1. Подібний продукт, який задумали клієнти, існує в організації.
2. Новий продукт, який буде розроблено.

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

Наприклад, Система камер об'ємного огляду, розроблена для OEM (GM, Volkswagen, BMW тощо), і може бути представлена ​​іншому OEM.

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

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

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

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

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

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

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

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

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

У наведеній вище історії користувача, якщо клієнт каже: „Як користувач, я повинен мати змогу побачити, що там є в задньому огляді мого автомобіля”, задаючи запитання “Чому 'Міг би дати' Як користувач, я мав би змогу побачити, що є в задньому огляді мого автомобіля, щоб я міг безпечно припаркувати свою машину '.

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

шлюз за замовчуванням не знайдено

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

Приклад:

# 2) Аналіз зібраних вимог

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

Цей етап важливий у процесі аналізу вимог через наступні основні причини:

(i) Клієнт може надати деякі вимоги, які може бути неможливо реалізувати через різні залежності.

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

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

(ii) Бізнес-аналітик міг зрозуміти вимогу з замовника інакше, ніж як програміст розтлумачив би.

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

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

# 3) Документування аналізованих вимог

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

Деякі з них:

(i) Специфікація вимог замовника.

(ii) Вимога архітектури програмного забезпечення.

Приклад:

(iii) Вимога до дизайну програмного забезпечення.

Приклад:

(iv) Специфікація функціональних вимог (безпосередньо похідна від специфікацій замовника.)

Приклад: 'Коли користувач натискає на піктограму Bluetooth на HMI Infotainment, повинен відображатися екран Bluetooth'

(V) Нефункціональна специфікація вимог (а саме: продуктивність, напруга, навантаження тощо).

Приклад: «Має бути можливість поєднати 15 пристроїв Bluetooth з інформаційно-розважальною системою без погіршення продуктивності системи».

(ми) Вимоги до інтерфейсу користувача.

Приклад: “На екрані тюнера FM повинна бути передбачена кнопка для вибору різних станцій”

Вищевикладені вимоги фіксуються та документуються в засобах управління вимогами, таких як IBM DOORS, HP QC. Іноді організації мають власні інструменти управління вимогами для зменшення витрат.

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

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

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

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

Для цього можна виконати такі дії:

1. Розбийте вимоги бізнесу на високому рівні до детальних історій користувачів.
2. Виведення блок-схеми для визначення потоку діяльності.
3. Надання умови, яка виправдовує похідні історії користувачів.
4. Каркасні діаграми для пояснення робочого процесу об’єктів.
5. Визначення нефункціональних вимог поза бізнес-вимогами.

Почнемо з прикладу автомобільної інформаційно-розважальної системи.

Бізнес-вимога говорить: 'Кінцевий користувач повинен мати доступ до відею навігації з HMI інформаційно-розважальної системи і повинен мати можливість встановити адресу призначення'.

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

найкращий безкоштовний конвертер YouTube в mp3

# 1) Розбийте вимоги бізнесу високого рівня до детальних історій користувачів.

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

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

1. Хто такі користувачі?
2. Як я можу отримати доступ до навігації, на борту (із SD-карти) або зі смартфона?
3. Який тип цільових записів я можу ввести?
4. Чи повинен я мати право в'їзду в пункт призначення, навіть коли автомобіль стоїть на стоянці?

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

На цьому етапі ми можемо взяти одну з підпунктів користувача та розпочати опитування. Візьмемо (№ 3):

1. Чи можу я ввести цільові записи, такі як геокоординати, поштова адреса, за допомогою розпізнавання мови тощо?
2. Чи потрібен GPS для введення геокоординат?
3. Чи можу я ввести поточну адресу призначення за допомогою пошуку в історії адрес?

# 2) Виведення блок-схеми для визначення потоку діяльності.

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

# 3) Забезпечення умов, які виправдовують похідні історії користувачів.

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

• Час завантаження екрану для відображення введення пункту призначення повинен становити 1 сек.
• Клавіатура введення пункту призначення повинна мати буквено-цифрові символи та спеціальні символи.
• Кнопка перемикача ввімкнення / вимкнення GPS повинна бути присутньою на екрані введення пункту навігації.

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

# 4) Каркасні діаграми для пояснення робочого процесу об’єктів.

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

# 5) Визначення нефункціональних вимог поза бізнес-вимогами.

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

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

Приклади:

а) Ми візьмемо приклад з наведеної вище автомобільної інформаційно-розважальної системи.

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

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

б) Інший випадок - сценарій стресу.

Візьмемо приклад: інформаційно-розважальна система отримує SMS-повідомлення (можливо, 20 SMS протягом 10 секунд) через підключений телефон Bluetooth. Інформаційно-розважальна система повинна мати можливість обробляти всі вхідні SMS і ні в якому разі не повинна пропускати будь-яке сповіщення про вхідні SMS на HMI Infotainment.

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

Розуміння випадків нефункціональних вимог

У таблиці нижче пояснюються нефункціональні вимоги:

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

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

Різниця між вимогами бізнесу та вимогами програмного забезпечення

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

Давайте розглянемо детальну різницю між двома типами вимог.

Висновок

Аналіз вимог є основою будь-якої моделі SDLC.

Проблема, пропущена під час аналізу вимог і виявлена ​​під час тестування підрозділу, може коштувати організації десятки тисяч доларів, і ця вартість може призвести до мільйонів доларів, якщо вона надійде з ринку як зворотний дзвінок (у 2017 році США, виробник подушок безпеки, Takata a штраф у розмірі 1 млрд доларів через вибух подушок безпеки).

В кінцевому підсумку організація виконувала б такі завдання з контролю збитків, як аналіз корінних причин, підготовка 5, чому документи, аналіз дерева несправностей, 8D-документ тощо, замість того щоб концентруватися на розробці програмного забезпечення та якості.

У найгірших випадках організація буде втягнута в судові позови, подані замовником, якщо порушена функція пов’язана з безпекою / безпекою, наприклад, захисний доступ, подушка безпеки, ABS (антиблокувальна гальмівна система) тощо.

Рекомендована література

• Етапи, методології, процеси та моделі SDLC (життєвий цикл розробки програмного забезпечення)
• Особливості функціональних вимог та не функціональних вимог
• Як перевірити специфікацію вимог до програмного забезпечення (SRS)?
• 5 смертельних помилок в управлінні вимогами та як їх подолати
• Як протестувати заявку без вимог?
• Заходи щодо SSDLC (безпечний життєвий цикл розробки програмного забезпечення)
• Спіральна модель - що таке спіральна модель SDLC?
• Що таке модель водоспаду SDLC?