Какво представлява анализ и събиране на изисквания в SDLC?

what is requirement analysis

Този урок обяснява какво е анализ на изискванията, стъпки за анализ на изискванията, примери и цели за събиране на изисквания в SDLC:

Разработката на софтуер е огромна задача, която създава работещ софтуерен продукт.

Софтуерният продукт е изграден според изискванията на клиента. Този софтуерен продукт отговаря най-вече на очакванията на крайния клиент / потребител, докато понякога този продукт не отговаря напълно на очакванията на клиента / крайния потребител.

Какво ще научите:

• Какво е анализ на изискванията?
  • Етапи / стъпки за анализ на изискванията
    • # 1) Събиране на изисквания
    • # 2) Анализиране на събраните изисквания
    • # 3) Документиране на анализирани изисквания
  • Преобразуване на бизнес изисквания в софтуерни изисквания
  • Разбиране на случаи на нефункционални изисквания
  • Разлика между бизнес изискванията и софтуерните изисквания
• Заключение
  • Препоръчително четене

Какво е анализ на изискванията?

Нека разберем анализа на изискванията с помощта на пример.

Очаквания на клиента / крайния потребител:

Клиент / краен потребител получават:

Както можете да анализирате от горните изображения, че има несъответствие в крайния продукт с очакванията на клиентите. Това може да се дължи на безброй причини, а именно. неправилно изпълнение на изискванията на клиента, неправилен дизайн, погрешно разбиране на изискванията на клиента от програмисти и екип по качеството и др.

Както можете да видите обаче, независимо дали става въпрос за някаква причина за грешна доставка на продукта, основната причина е изискването. Следователно, ако бяха направени правилно разбиране на изискванията, улавяне, внедряване и тестване, това би спомогнало за смекчаване на грешната и непълна доставка на продукт до клиент / краен потребител.

Добрата доставка на продукти изисква предварително коректно събиране на изискванията, ефективно проучване на събраните изисквания и накрая ясна документация за изискванията. Целият този процес се нарича още Анализ на изискванията в жизнения цикъл на разработката на софтуер (SDLC)

Етапи / стъпки за анализ на изискванията

Както можете да видите, Анализът на изискванията е първата дейност в SDLC, последвана от Функционална спецификация и т.н. Анализът на изискванията е жизненоважна стъпка в SDLC, тъй като резонира с тестове за приемане, които са критични за приемането на продукта от клиентите.

В този урок ще обясним как се прави анализ на изискванията в SDLC. Също така ще видим различните участващи стъпки, резултати, предизвикателства и коригиращи мерки при анализа на изискванията.

Анализът на изискванията започва с:

1. Събиране на изисквания което се нарича още извикване.
2. Това е последвано от анализирам събраните изисквания за разбиране на коректността и възможността за превръщането на тези изисквания във възможен продукт.
3. И накрая, документиране събраните изисквания.

# 1) Събиране на изисквания

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

Много пъти не е възможно събирането на изисквания да се извършва ефективно от бизнес анализаторите от клиента. Това може да се дължи на зависимостта от много хора, свързана с очаквания краен продукт, инструменти, среда и т.н. Поради това винаги е добра идея да се включат всички заинтересовани страни, които биха могли да повлияят или биха могли да бъдат повлияни от крайния продукт.

Възможната група на заинтересованите страни могат да бъдат инженери по качеството на софтуера (както QC, така и QA), всеки доставчик на трета страна, който може да предостави подкрепа в проекта, краен потребител, за когото продуктът е предназначен, софтуерни програмисти, друг екип в организацията, който може да предостави модул или софтуерна платформа, софтуерни библиотеки и др. за разработване на продукти.

Пример: В една организация те разработват продукт ADAS (система за съраунд изглед за престижен OEM), който се нуждае Стека на Autosar и Буутлоудър двоични файлове, получени от друг доставчик.

Участието на различни заинтересовани страни в етапа на събиране на изискванията помага за разбирането на различни зависимости един от друг и всеки възможен бъдещ конфликт може да бъде предотвратен.

Понякога е добра идея да създадете прототип на планирания продукт и да го покажете на клиента. Това е отличен начин да предадете на клиентите какъв продукт очакват и как може да изглежда по-късно. Това помага на клиента да визуализира продукта, който очаква, и му помага да излезе с ясни изисквания.

Създаването на този прототип зависи от два вида продукти:

1. В рамките на организацията съществува подобен продукт, който клиентите са предвидили.
2. Предстои разработване на нов продукт.

(i) В първия случай е по-лесно да покажете на клиента как би изглеждал крайният продукт и как би бил разработен. В автомобилната ADAS е възможно да се покаже на клиентите друг продукт, който вече е на пазара и е разработен в рамките на организацията.

Например, Система за съраунд изглед, разработена за OEM (GM, Volkswagen, BMW и др.) И може да бъде представена на друг OEM.

Моля обърнете внимание , не е разумно да показвате продукт / прото продукт на клиента, който е в процес на разработка, тъй като това може да наруши Споразумението за неразкриване на информация, подписано с друг клиент, за когото този продукт се разработва. Това също може да доведе до ненужна правна борба.

Друг пример може да бъде тази на информационно-развлекателната система, която се разработва от организацията и вече е на пазара. Бизнес анализаторите и други заинтересовани страни в организацията могат да планират демонстрация на семинар за клиента, показвайки информационно-развлекателни системи с осезаем HMI, портове за съединители на устройства, пясъчник и т.н.

Това ще помогне на клиента да разбере как би изглеждал крайният продукт и ще предостави своите изисквания много по-ясно.

(ii) Вторият случай може да бъде постигнат чрез създаване на основен работещ модел чрез просто кодиране и сглобяване (повечето функции тук са кодирани твърдо в софтуерни програми) или чрез създаване на блок-схема или диаграма, която може да убеди клиента как ще изглежда продукта.

Във всеки случай това би било отдих за процеса на събиране на изискванията, тъй като клиентът вече знае какво иска.

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

Събраните изисквания могат да бъдат под формата на потребителски истории (при гъвкава разработка), случаи на употреба, документи на клиент на естествен език, диаграми, блок-схеми и др. Историите на потребителите стават популярни в съвременния жизнен цикъл на разработка на софтуер. Потребителските истории са основно набор от клиентски данни на техния естествен език.

Пример за събиране на изисквания: В системата от камери за съраунд-изглед ADAS една възможна история на потребителя може да бъде: „Като потребител трябва да мога да видя какво има в задното виждане на колата ми“.

Може да са много 'защо,' въпроси, зададени за всяка потребителска история, които ще помогнат на клиента да предостави по-подробна информация за изискването.

В горната история на потребителя, ако клиент каже „Като потребител, трябва да мога да видя какво има в задната част на автомобила ми“, задавайки въпрос 'защо “Бих могъл да дам„ Като потребител трябва да мога да видя какво има в задната част на колата ми, за да мога да паркирам колата си безопасно ”.

Задавайки въпроса 'защо' също помага при създаването на обективни и атомни изисквания от необичайни изявления на естествен език, дадени от клиента. Това може лесно да бъде приложено по-късно в кода.

как да стартирам .jar файлове на Windows

Друг начин за събиране на изискването е под формата на случаи на употреба . Случаят на употреба е подход стъпка по стъпка за постигане на определен резултат. Това не казва как софтуерът ще работи върху потребителското въвеждане, а казва какво се очаква от потребителските въведения.

Пример:

# 2) Анализиране на събраните изисквания

Събиране на изисквания за публикуване, анализ на изискванията започва. На този етап различни заинтересовани страни седят и правят мозъчна атака. Те анализират събраните изисквания и търсят възможността да ги изпълнят. Те обсъждат помежду си и всяка неяснота се подрежда.

Тази стъпка е важна в процеса на анализ на изискванията поради следните основни причини:

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

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

Ако клиентът посочи изискване камерата за обратно виждане за паркинг помощ трябва да работи по всяко време без изключение, а след това Ремарке функцията никога няма да работи и обратно.

(ii) Бизнес анализатор може да е разбрал изискването от клиент различно от това как а програмист би интерпретирал.

Тъй като програмистите мислят като технически експерти, винаги е възможно изискванията на клиентите да бъдат неправилно преобразувани във функционални спецификации, които по-късно ще бъдат неправилно направени в архитектурните и дизайнерските документи и впоследствие в кода. Въздействието е експоненциално и затова трябва да се провери.

Възможна коригираща мярка може да бъде следването на гъвкав метод за разработване на софтуер, следване на случаи на употреба, които клиентът предоставя и т.н.

# 3) Документиране на анализирани изисквания

След като се направи анализ на изискванията, документацията за изискванията започва. Различни видове изисквания излизат от анализа на изискванията.

Някои от тях са:

(i) Спецификация на изискванията на клиента.

(ii) Изискване за софтуерна архитектура.

Пример:

(iii) Изискване за софтуерен дизайн.

Пример:

(iv) Спецификация на функционалните изисквания (директно получена от спецификациите на клиента.)

Пример: „Когато потребителят докосне иконата на Bluetooth в HMI на Infotainment, трябва да се покаже екранът на Bluetooth“

(v) Нефункционална спецификация на изискванията (а именно производителност, напрежение, натоварване и т.н.).

Пример: „Трябва да е възможно да се сдвоят 15 Bluetooth устройства с информационно-развлекателна система без влошаване на производителността на системата“.

(ние) Изисквания на потребителския интерфейс.

Пример: „На екрана на Tuner FM трябва да има бутон за избор на различни станции“

Горните изисквания се записват и документират в инструменти за управление на изискванията, като IBM DOORS, HP QC. Понякога организациите имат свои индивидуални инструменти за управление на изискванията за намаляване на разходите.

Нека сега разгледаме процеса на преобразуване Бизнес изисквания да се Софтуерни изисквания (функционални и нефункционални).

Преобразуване на бизнес изисквания в софтуерни изисквания

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

По този начин бизнес изискванията трябва да бъдат разделени на по-подробни софтуерни изисквания, които ще бъдат допълнително детайлизирани към функционални и нефункционални изисквания.

За целта могат да се изпълнят следните стъпки:

1. Разбийте бизнес изискванията на високо ниво на подробни потребителски истории.
2. Извличане на блок-схема за дефиниране на потока от дейности.
3. Предоставяне на условието, което оправдава изведените потребителски истории.
4. Диаграми на каркаса за обяснение на работния поток на обектите.
5. Определяне на нефункционални изисквания извън бизнес изискванията.

Нека започнем, като вземем примерна автомобилна информационно-развлекателна система.

Бизнес изискването гласи: „Крайният потребител трябва да има достъп до полето за приспособления за навигация от HMI на Infotainment системата и трябва да може да задава адрес на местоназначението“.

И така, изброените по-горе стъпки могат да бъдат приложени като:

# 1) Разбийте бизнес изискванията на високо ниво на подробни потребителски истории.

Нека превърнем това бизнес изискване в потребителска история на високо ниво, “ Като потребител трябва да имам достъп до полето за приспособления за навигация, за да мога да въведа адреса на местоназначението ”. Тази история на потребителя разказва какво е необходимо на крайния потребител. Ще се опитаме да определим как да изпълним това изискване.

Нека започнем с задаване на възможни въпроси към тази потребителска история, а именно.

1. Кои са потребителите?
2. Как мога да вляза в навигацията, на борда (от SD карта) или от SmartPhone?
3. Какъв вид записи за местоназначение мога да въведа?
4. Трябва ли да ми бъде разрешено да влизам в дестинацията, дори когато колата е на паркинг?

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

На този етап можем да вземем една от потребителските под-истории и да започнем да разпитваме. Да вземем (№ 3):

1. Мога ли да въведа записи за местоназначение като гео координати, пощенски адрес, чрез разпознаване на реч и т.н.?
2. Трябва ли ми GPS за въвеждане на геокоординати?
3. Мога ли да въведа текущия адрес на местоназначение чрез търсене в историята на адресите?

# 2) Извеждане на блок-схема за определяне на потока от дейности.

Сега можем да видим, че бизнес изискването е разбито до много подробни случаи на употреба, които могат да бъдат маркирани в блок-схемата по-долу:

# 3) Предоставяне на условия, които оправдават производни потребителски истории.

Можем да видим, че се появява по-подробна информация поради разлагането на изискванията за бизнес на високо ниво в подробни истории на потребителите на ниско ниво и на диаграмата. От тази блок-схема можем да получим техническите подробности, необходими за изпълнението, а именно.

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

Горната информация удовлетворява потребителските истории и дава възможност изискването да бъде тествано дискретно и измеримо, за да се избегне всякакво объркване с изискването, докато се изпълнява като функции.

# 4) Диаграми на каркаса, за да обяснят работния поток на обектите.

От горния случай на употреба ще извлечем диаграма на каркаса, която ще направи по-ясен потребителския интерфейс.

# 5) Определяне на нефункционални изисквания извън бизнес изискванията.

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

Функционалните изисквания обаче не изясняват производителността на системата и други качествени параметри като наличност, надеждност и др.

Примери:

а) Ще вземем примера на горната автомобилна информационно-развлекателна система.

Ако шофьорът (краен потребител) на автомобила възпроизвежда музика от USB и навигацията е в ход, също получава входящо повикване чрез Bluetooth в режим „свободни ръце“, след това натоварването на процесора и RAM консумацията се увеличава до максимално ниво, тъй като се извършват множество процеси работи във фонов режим.

В този момент, ако шофьорът докосне сензорния интерфейс на информационно-развлекателна система, за да отхвърли входящото обаждане чрез SMS с автоматичен отговор (по същия начин, както го правим в нашите мобилни телефони), системата трябва да може да изпълни тази задача и не трябва да виси или да се срива. Това е производителността на системата, когато натоварването е голямо и ние тестваме наличност и надеждност.

б) Друг случай е Сценарият.

Да вземем пример, системата за инфотейнмънт получава обратно SMS съобщения (може би 20 SMS в рамките на 10 секунди) чрез свързан Bluetooth телефон. Информационно-развлекателната система трябва да може да обработва всички входящи SMS и в никакъв момент не трябва да пропуска някое от входящите SMS известия в HMI на Infotainment.

Горните примери са случаи на нефункционални изисквания, които не могат да бъдат тествани само чрез функционални изисквания. Въпреки че понякога клиентите пропускат да предоставят тези нефункционални изисквания. Отговорността на организацията е да им предостави тази информация, когато продуктът се доставя на клиента.

Разбиране на случаи на нефункционални изисквания

Таблицата по-долу обяснява нефункционалните изисквания:

Нефункционалните изисквания, за разлика от функционалните изисквания, изискват пълния жизнен цикъл на даден проект, тъй като те се прилагат постепенно в съответните Agile Sprints или в различни итерации.

И така, ние извличаме софтуерни изисквания от бизнес изискванията.

Разлика между бизнес изискванията и софтуерните изисквания

Видяхме по-горе как да извлечем софтуерни изисквания от бизнес изискванията на високо ниво. Софтуерните изисквания позволяват на програмиста и тестовия инженер да разработят системата и да я тестват ефективно. И така, сега знаем, че бизнес изискванията са изисквания на естествен език на клиентите на високо ниво, докато софтуерните изисквания са подробни изисквания на ниско ниво, които помагат при внедряването на софтуерната система.

Нека разгледаме подробната разлика между двата вида изисквания.

Заключение

Анализът на изискванията е гръбнакът на всеки SDLC модел.

Проблем, пропуснат по време на анализа на изискванията и уловен при тестване на единица, може да струва десетки хиляди долари на организация и този разход може да доведе до милиони долари, ако идва от пазара като обратен разговор (през 2017 г., САЩ, производител на въздушни възглавници, Takata a глоба от 1 млрд. долара поради експлодиращи въздушни възглавници).

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

как да видите .json файлове

В най-лошите случаи организацията ще бъде въвлечена в съдебни дела, заведени от клиента, ако засегнатата функция е свързана със сигурността / безопасността, като достъп до сигурност, въздушна възглавница, ABS (антиблокираща спирачна система) и т.н.

Препоръчително четене

• SDLC (жизнен цикъл на разработка на софтуер) Фази, методологии, процес и модели
• Характеристики на функционалните изисквания и нефункционалните изисквания
• Как да тествате спецификацията на софтуерните изисквания (SRS)?
• 5 смъртоносни грешки в управлението на изискванията и как да ги преодолеете
• Как да тествате приложение без изисквания?
• Мерки за SSDLC (жизнен цикъл на сигурна разработка на софтуер)
• Спирален модел - Какво е SDLC спирален модел?
• Какво е SDLC модел водопад?