Анализ на софтуерните изисквания с пример
Чарлз Мур
⚡ Умно обобщение
Анализът на софтуерните изисквания разделя нуждите на заинтересованите страни на функционални и нефункционални твърдения, класира ги на бизнес, архитектурно и системно ниво, след което проверява всяко едно от тях спрямо атрибути за качество, за да гарантира тестваемост, 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
Всяко изискване трябва да бъде атомарно, което означава, че трябва да бъде на най-ниско ниво на детайлност и не може да бъде разделено допълнително на компоненти. Следните примери сравняват атомарни и неатомни изисквания.
Продължавайки с примера за образователната система: Тук лошото изискване е „Студентите ще могат да се запишат в бакалавърски и магистърски курсове“. Това е лошо изискване, защото не е атомарно — смесва две различни единици, бакалавърски и магистърски курсове. Съответното добро изискване го разделя на две изисквания. Едното изискване обхваща записване в бакалавърски курсове, а другото обхваща записване в магистърски курсове.
Уникално идентифициран
Следващият атрибут за качество е уникалната идентификация. В лошия пример две отделни изисквания споделят един и същ ID#1. Ако екипът се позове на изискване чрез неговия ID, става неясно кое от двете се има предвид. Доброто изискване ги прегрупира в Раздел 1 - Записване в курсове, с подизисквания 1.1 (записване в бакалавърски курсове) и 1.2 (записване в магистърски курсове).
Пълен
Всяко изискване трябва да бъде попълнено. Например, тук лошото изискване гласи, че „потребителят професор ще влезе в системата, като предостави потребителското си име, парола и друга подходяща информация“. „Друга подходяща информация“ е неясно. Пълното изискване изброява точните полета, като например код на катедрата, които професорът трябва да предостави.
Последователно и недвусмислено
Всяко изискване трябва да бъде последователно и недвусмислено. В лошия пример едно изискване гласи „Студентът ще има или бакалавърски курсове, или магистърски курсове, но не и двете“, докато друго гласи „Някои курсове ще бъдат отворени както за бакалавърски, така и за магистърски студенти“.
Първото изискване предполага, че курсовете са разделени на две отделни категории, но второто изискване му противоречи, като отваря някои курсове и за двете групи.
Доброто изискване разрешава конфликта, като ясно посочва, че всеки курс е обозначен като бакалавърски или магистърски и студентът може да се запише само в курсове от една категория.
Tracвъзможно
Всяко изискване трябва да бъде tracвъзможно е, защото изискванията съществуват на множество нива: бизнес, архитектурно и дизайнерско, и системно и интеграционно.
Когато преобразувате бизнес изискване в архитектурни и дизайнерски изисквания или архитектурни и дизайнерски изисквания в системни и интеграционни изисквания, tracУдобството трябва да се запази. Всяко бизнес изискване трябва да съответства на едно или повече архитектурни и дизайнерски изисквания. В лошия пример „Поддържане на информация за студентите – съответстваща на BRD req ID?“, идентификаторът на изискването липсва.
Изискването за доброто записва същото твърдение, но изрично съответства на BRD изискване ID 4.1. Всяко изискване трябва да носи tracкарта на възможноститеpingСистемните и интеграционните изисквания също трябва да съответстват на кода, който ги имплементира, и на тестовите случаи, които ги проверяват.
TracСледователно, eability работи от край до край в целия проект.
Приоритетната
Всяко изискване трябва да бъде приоритизирано, така че екипът да знае какво да внедри първо и какво може да почака. В лошия пример, „Регистрация на студент“, „Поддържане на потребителска информация“, „Записване на курсове“ и „Преглед на отчетната карта“ са зададени на Приоритет 1. Не всичко може да бъде с Приоритет 1, така че изискванията трябва да бъдат класирани реалистично. Добрият пример дава на „Регистрация на студент“ и „Записване на курсове“ най-висок Приоритет 1, „Поддържане на потребителска информация“ – Приоритет 2, а „Преглед на отчетната карта“ – Приоритет 3.
Тестван
Всяко изискване трябва да може да се тества. Лошият пример „всяка страница от системата ще се зареди в приемлив срок“ не е тестваем по две причини. Първо, „всяка страница“ може да означава десетки страници, което допълнително увеличава усилията за тестване. Второ, „приемлив срок“ е неопределен – приемлив за кого и спрямо какъв критерий? Доброто изискване решава и двата проблема, като назовава конкретните страници („страници за регистрация на студенти и записване на курсове“) и задава измерима цел от 5 секунди.
