Анализ на софтуерните изисквания с пример
Чарлз Мур
Например, в контекста на банковото приложение функционалното изискване ще бъде, когато клиентът избере „Преглед на баланса“, той трябва да може да прегледа последното салдо по сметката си.
Софтуерното изискване може да бъде и нефункционално, може да е изискване за производителност. Например, нефункционално изискване е всяка страница от системата да бъде видима за потребителите в рамките на 5 секунди.
И така, основно софтуерното изискване е a
- Функционална или
- Нефункционален
трябва който трябва да бъде внедрен в системата. Софтуерните изисквания обикновено се изразяват като изявления.
Видове изисквания
- Бизнес изисквания: Това са изисквания на високо ниво, които са взети от бизнес случая от проектите. Например, система за мобилни банкови услуги предоставя банкови услуги в Югоизточна Азия. Бизнес изискването, което се решава за Индия, е обобщение на акаунта и превод на средства, докато за Китай обобщението на акаунта и плащането на сметки се определя като бизнес изискване
| Страна | Компания, предоставяща банкови функции или услуги |
|---|---|
| Индия | Резюме на акаунта и превод на средства |
| Китай | Резюме на акаунта и 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
Така че всяко изискване, което имате, трябва да бъде атомарно, което означава, че трябва да бъде на много ниско ниво на детайлност, което не трябва да е възможно да се раздели на компоненти. Тук ще видим двата примера за изисквания, при Atomic и уникално идентифицирани нива на изисквания.
Така че нека продължим с пример за изграждане на система за образователна област. Тук лошото изискване е „Студентите ще могат да се запишат в бакалавърски и следдипломни курсове“ . Това е лошо изискване, защото не е атомарно, защото говори за две различни единици за бакалавърски и следдипломни курсове. Така че очевидно това не е добро, а лошо изискване, така че доброто изискване за съответствие би било да се раздели на две изисквания. Така че единият говори за записване в бакалавърски курсове, докато другият говори за записване в следдипломни курсове.
Уникално идентифициран
По подобен начин следващото изискване за качество е да се провери за уникално идентифициране, тук имаме две отделни изисквания, но и двете имат един и същ ID#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 секунди.
Заключение
Ето как трябва да гледаме на всяко изискване на подходящо ниво. Например, ако ще изградим софтуер по отношение на изискванията за система и интеграция. Трябва да разгледаме системните и интеграционните изисквания, дадени в спецификациите на софтуерните изисквания или потребителските истории, и да приложим към всяко едно качество на изискванията. След това проверете дали всяко изискване е атомарно, уникално идентифицирано и пълно и т.н.
