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