Аналіз програмних вимог із прикладом
Чарльз Мур
⚡ Розумний підсумок
Аналіз вимог до програмного забезпечення розбиває потреби зацікавлених сторін на функціональні та нефункціональні твердження, ранжує їх на бізнес-, архітектурному та системному рівнях, а потім перевіряє кожне з них на відповідність атрибутам якості, щоб гарантувати перевірену, tracспрощена, пріоритетна специфікація.
Вимога до програмного забезпечення — це функціональна або нефункціональна потреба, яка має бути реалізована в системі. Функціональність означає надання певної послуги користувачеві.
Наприклад, у контексті банківського застосунку функціональна вимога полягає в тому, щоб, коли клієнт вибирає «Переглянути баланс», він мав можливість переглянути останній баланс свого рахунку.
Вимога до програмного забезпечення також може бути нефункціональною, наприклад, вимогою до продуктивності. Наприклад, нефункціональна вимога може вказувати, що кожна сторінка системи повинна завантажуватися для користувачів протягом 5 секунд.
Отже, в основному вимога до програмного забезпечення: a
- Функціональний або
- Нефункціональний
необхідність який необхідно впровадити в систему. Вимоги до програмного забезпечення зазвичай виражаються у вигляді заяв.
Типи вимог
Вимоги до бізнесуЦе загальні вимоги, взяті з бізнес-кейсу проекту. Наприклад, система мобільного банкінгу надає банківські послуги в Південно-Східній Азії. Бізнес-вимогою, визначеною для Індії, є зведення рахунку та переказ коштів, тоді як для Китаю це зведення рахунку та оплата рахунків.
| Країна | Компанія, що надає банківські функції або послуги |
|---|---|
| Індія | Підсумок рахунку та переказ коштів |
| Китай | Резюме облікового запису та Bill Оплата |
Archiтектурні та дизайнерські вимогиЦі вимоги є більш детальними, ніж бізнес-вимоги, та визначають архітектуру рішення. Вони визначають загальний дизайн, необхідний для реалізації бізнес-вимог. Для освітньої організації типові варіанти використання архітектури та дизайну включають вхід, деталі курсу та реєстрацію. Вимога буде такою, як показано нижче.
| Банківський варіант використання | Вимога |
|---|---|
| Bill Оплата | Цей варіант використання описує, як клієнт може ввійти в мережевий банкінг і використовувати Bill Платіжний засіб. Клієнт може бачити панель неоплачених рахунків для зареєстрованих платників. Клієнт може додавати, змінювати та видаляти дані платника. Клієнт може налаштувати SMS-сповіщення та сповіщення електронною поштою для різних дій з виставлення рахунків. Клієнт може переглядати історію минулих сплачених рахунків. Учасниками, які починають цей варіант використання, є клієнти банку або персонал служби підтримки. |
Вимоги до системи та інтеграціїНа найнижчому рівні у нас є системні та інтеграційні вимоги. Він містить детальний опис кожної вимоги. Його можна зафіксувати у вигляді історій користувачів, написаних повсякденною бізнес-мовою. Вимоги містять багато деталей, щоб розробники могли розпочати кодування. Bill У прикладі платіжного модуля нижче показано вимогу додавання платника.
| Bill Оплата | Вимога |
|---|---|
| додавати BillERS | Назва постачальника комунальних послуг, номер клієнта, що відповідає за зв'язок, автоматичні платежі – Так/Ні, сплатити повністю Bill – Так/Ні, Ліміт автоматичних платежів – Не платіть, якщо Bill перевищує вказану суму |
Іноді для проекту ви можете не отримати жодних вимог чи документів для роботи. Навіть тоді існують інші джерела інформації про вимоги, на які ви можете покладатися, щоб базувати своє програмне забезпечення або розробку тестів. Інші джерела вимог, на які ви можете покладатися, перелічені нижче.
Інші джерела вимог
- Передача знань від колег або співробітників, які вже працюють над цим проектом
- Обговоріть проєкт з бізнес-аналітиком, менеджером продукту, керівником проєкту та розробниками
- Проаналізуйте попередню версію системи, яка вже впроваджена
- Проаналізуйте старіші документи з вимогами з проекту
- Revпереглядати попередні звіти про помилки; деякі звіти про помилки перетворюються на запити на покращення, які можуть бути реалізовані в поточній версії
- Перевірте посібник з встановлення, якщо він є, щоб дізнатися, які установки потрібні
- Проаналізуйте знання в галузі або галузі, які команда намагається впровадити
Яким би джерелом вимог ви не користувалися, задокументуйте їх у спільному форматі та передайте на перевірку досвідченим членам команди.
Як аналізувати вимоги
Розглянемо приклад освітньої програмної системи, де студент може зареєструватися на різні курси.
Давайте розглянемо, як аналізувати вимоги. Кожна вимога повинна підтримувати набір стандартних атрибутів якості, які включають наступне:
- Atomic
- Унікально ідентифікований
- Цілковита
- Послідовний і однозначний
- Tracможливо
- Пріоритетність
- Перевірений
У наступній таблиці кожен атрибут ілюструється трьома стовпцями:
- Перший стовпець вказує - «вимога якості»
- Другий стовпець вказує на «погану вимогу з певною проблемою»
- У третьому стовпці показано ту саму вимогу, «перетворену на хорошу вимогу».
| Вимога Якість | Приклад поганої вимоги | Приклад хорошої вимоги |
|---|---|---|
| Atomic | Студенти зможуть вступати до бакалаврату та аспірантури | Студенти зможуть записатися на бакалаврські курси. Студенти зможуть записатися на аспірантуру. |
| Унікально ідентифікований | 1. Студенти зможуть записатися на бакалаврські курси. 1. Студенти зможуть записатися на аспірантуру. | Зарахування на курси. Студенти зможуть записатися на бакалаврські курси. Студенти зможуть записатися на аспірантуру. |
| Цілковита | Користувач-професор увійде в систему, надавши своє ім’я користувача, пароль та іншу відповідну інформацію | Користувач-професор увійде в систему, ввівши своє ім'я користувача, пароль і код кафедри |
| Послідовний і однозначний | Студент матиме або бакалаврат, або аспірантуру, але не обидва. Деякі курси будуть відкриті як для студентів, так і для аспірантів | Студент матиме бакалаврат або аспірантуру, але не обидва |
| Tracможливо | Підтримувати інформацію про студента, зіставлену з BRD req.ID? | Зберігайте інформацію про студента – зіставлено з BRD req ID 4.1 |
| Пріоритетність | Зареєстрований студент – Пріоритет 1. Зберігання інформації про користувача – Пріоритет 1. Запис на курси – Пріоритет 1. Перегляд табеля успішності – Пріоритет 1 | Реєстрація студента – Пріоритет 1. Зберігання інформації про користувача – Пріоритет 2. Запис на курси – Пріоритет 1. Перегляд табеля успішності – Пріоритет 3 |
| Перевірений | Кожна сторінка системи завантажуватиметься за прийнятний проміжок часу | Сторінки реєстрації студента та запису на курси системи завантажуються протягом 5 секунд |
Давайте розглянемо кожну з цих властивостей детальніше, починаючи з Atomік.
Atomic
Кожна вимога має бути атомарною, тобто вона має бути на найнижчому рівні деталізації та не може бути розбита далі на компоненти. У наступних прикладах порівнюються атомарні та неатомарні вимоги.
Продовжуючи приклад з системою освітньої сфери: тут погана вимога — «Студенти зможуть записатися на курси бакалаврату та аспірантури». Це погана вимога, оскільки вона не є атомарною — вона поєднує дві різні сутності, курси бакалаврату та аспірантури. Відповідна хороша вимога розділяє її на дві вимоги. Одна вимога охоплює зарахування на курси бакалаврату, а інша — на курси аспірантури.
Унікальна ідентифікація
Наступним атрибутом якості є унікальна ідентифікація. У поганому прикладі дві окремі вимоги мають один і той самий ідентифікатор №1. Якщо команда посилається на вимогу за її ідентифікатором, стає незрозуміло, який з двох мається на увазі. Хороша вимога перегруповує їх у Розділ 1 — Зарахування на курси, з підвимогами 1.1 (зарахування на курси бакалаврату) та 1.2 (зарахування на курси магістратури).
Цілковита
Кожна вимога має бути повною. Наприклад, тут погана вимога говорить, що «користувач-професор увійде в систему, надавши своє ім’я користувача, пароль та іншу відповідну інформацію». «Інша відповідна інформація» є розпливчастою. Повна вимога містить точний перелік полів, таких як код кафедри, які професор повинен надати.
Послідовний і однозначний
Кожна вимога має бути послідовною та однозначною. У поганому прикладі одна вимога говорить: «Студент матиме або курси бакалаврату, або курси магістратури, але не обидва», тоді як інша говорить: «Деякі курси будуть відкриті як для студентів бакалаврату, так і для аспірантів».
Перша вимога передбачає поділ курсів на дві окремі категорії, але друга вимога суперечить їй, відкриваючи деякі курси для обох груп.
Гарна вимога вирішує конфлікт, чітко зазначаючи, що кожен курс позначено або як бакалаврський, або як аспірантський, і студент може записатися лише на курси однієї категорії.
Tracможливо
Кожна вимога має бути tracможливо, оскільки вимоги існують на кількох рівнях: бізнес-рівні, архітектурному та дизайнерському, а також системному та інтеграційному.
Коли ви перетворюєте бізнес-вимогу на архітектурні та проектні вимоги, або архітектурні та проектні вимоги на системні та інтеграційні вимоги, tracПрацездатність має бути збережена. Кожна бізнес-вимога повинна відповідати одній або кільком архітектурним та дизайнерським вимогам. У поганому прикладі «Зберігати інформацію про студента – зіставлено з ідентифікатором вимоги BRD?» ідентифікатор вимоги відсутній.
Вимога до товару містить те саме твердження, але явно відповідає вимозі BRD ID 4.1. Кожна вимога повинна містити tracкарта зручностіpingСистемні та інтеграційні вимоги також повинні відповідати коду, який їх реалізує, та тестовим випадкам, які їх перевіряють.
TracТаким чином, ефективність працює від початку до кінця в усьому проєкті.
Пріоритетність
Кожна вимога має бути пріоритетною, щоб команда знала, що впроваджувати першим, а що може зачекати. У поганому прикладі для «Реєстрації студентів», «Зберігання інформації про користувача», «Запис на курси» та «Перегляду звітної картки» встановлено пріоритет 1. Не все може мати пріоритет 1, тому вимоги мають бути реалістично ранжовані. У хорошому прикладі «Реєстрації студентів» та «Запису на курси» надається найвищий пріоритет 1, «Зберігання інформації про користувача» – пріоритет 2, а «Перегляду звітної картки» – пріоритет 3.
Перевірений
Кожна вимога має бути тестовою. Поганий приклад «кожна сторінка системи завантажиться у прийнятні часові рамки» не тестується з двох причин. По-перше, «кожна сторінка» може означати десятки сторінок, що збільшує зусилля тестування. По-друге, «прийнятні часові рамки» не визначені — прийнятні для кого і за яким критерієм? Гарна вимога вирішує обидві проблеми, називаючи конкретні сторінки («сторінки реєстрації студента та запису на курси») та встановлюючи вимірну ціль у 5 секунд.
