Какво е функционално изискване в софтуерното инженерство?

по: Чарлз Мур Чарлз Мур
Hours Обновено

⚡ Умно обобщение

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

  • 📘 Определение: Функционалното изискване, наричано още функционална спецификация, посочва какво трябва да прави системата – входни данни, поведение и изходни данни, описани от гледна точка на потребителя или бизнеса.
  • 📄 Обхват на документа: Документът с функционални изисквания обхваща операциите на екрана, логиката за обработка на данни, отчетите, работните процеси, разрешенията и съответствието с регулаторните изисквания.
  • 🗂️ Често срещани типове: Обработка на транзакции, бизнес правила, отчетност, административни функции, нива на оторизация, одит tracкрал, външни интерфейси и законови изисквания.
  • 💡 Примери: Валидирането на вход, записването на продажби, прегледът на приходи въз основа на роли, интеграцията с банков API и съответствието с изискванията за достъпност са част от функционалните изисквания.
  • 🆚 Нефункционален контраст: Функционалните изисквания описват какво прави една система; нефункционалните изисквания описват колко добре го прави – производителност, сигурност и използваемост.
  • ✅ Най-добри практики: Поддържайте изискванията подробни, тестваеми и съпоставени с бизнес цел, и ги извличайте чрез интервюта и семинари.
Прочетете повече

Функционални изисквания в софтуерното инженерство

Какво е функционално изискване?

A Функционално изискване (FR) е описание на услугата, която софтуерът трябва да предлага. То описва софтуерна система или нейния компонент. Функцията се определя от входове, поведение и изходи. Тя може да бъде изчисление, манипулиране на данни, бизнес процес или потребителско взаимодействие, което определя какво трябва да прави системата. Функционалните изисквания в софтуерното инженерство се наричат ​​още Функционална спецификация.

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

Какво да включите в документа с функционални изисквания

Ето какво трябва да обхваща документът с функционални изисквания:

Примерни функционални изисквания

Примерни функционални изисквания

Документът с функционални изисквания обикновено включва:

  • Подробности за операциите, извършени на всеки екран
  • Логика за обработка на данни, която системата трябва да прилага
  • Descriptиони на системни отчети и други резултати
  • Пълна информация за работните процеси, които системата изпълнява
  • Кой има право да създава, променя или изтрива данни в системата
  • Как системата отговаря на приложимите регулаторни изисквания и изисквания за съответствие

Предимства на функционалните изисквания

Основните предимства на добре написан документ с функционални изисквания са:

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

Видове функционални изисквания

Често срещани категории функционални изисквания включват:

  • Обработка на транзакция
  • Бизнес правила
  • Сертифициране Изисквания
  • Изисквания за докладване
  • Административни функции
  • Нива на оторизация
  • Проверка Tracking
  • Външни интерфейси
  • Управление на исторически данни
  • Законови и регулаторни изисквания

СВЪРЗАНИ СТАТИИ

Примери за функционални изисквания

По-долу са дадени практически примери за функционални изисквания:

  • Софтуерът автоматично ще валидира клиентите спрямо системата за управление на контакти ABC.
  • Системата за продажби трябва да позволява на потребителите да записват продажбите на клиенти.
  • Цветът на фона за всички прозорци в приложението трябва да бъде син с шестнадесетична RGB стойност 0x0000FF.
  • Само служители на управленско ниво имат право да преглеждат данните за приходите.
  • Софтуерната система ще се интегрира с банковия API.
  • Софтуерната система трябва да отговаря Раздел 508 изисквания за достъпност.

Функционални срещу нефункционални изисквания

Ето са ключовите разлики между функционалните и нефункционалните изисквания в Софтуерно инженерство:

параметри Функционално изискване Нефункционално изискване
Какво е глагол Атрибути
Изискване Тя е задължителна Не е задължително
Тип заснемане Той е заловен в случай на употреба. Той се улавя като качествен атрибут.
Краен резултат Функция на продукта Свойства на продукта
Прихващане Лесен за заснемане Трудно за улавяне
Цел Помага ви да проверите функционалността на софтуера. Помага ви да проверите ефективността на софтуера.
Зона на фокусиране Фокусирайте се върху изискванията на потребителя Концентрира се върху очакванията на потребителя.
документация Опишете какво прави продуктът Описва как работи продуктът
Тип тестване Функционално тестване като система, интеграция, край до край, API тестванеИ др Нефункционални тестове като производителност, стрес, използваемост, Тестване на сигурносттаИ др
Изпълнение на теста Изпълнението на тестовете се извършва преди нефункционалното тестване. След функционалното изследване
Информация за продукта Характеристики на продукта Свойства на продукта

Най-добри практики за писане на функционални изисквания

Най-важните най-добри практики за писане на документ с функционални изисквания са:

  • Не комбинирайте две изисквания в едно; дръжте всяко изискване подробни.
  • Направете всяко изискване възможно най-пълно и точно.
  • Изгответе всички технически изисквания в документа.
  • Свържете всяко изискване с целите и принципите, които водят до успешното разработване на софтуер.
  • Изяснявайте изискванията чрез интервюта, семинари и неформални разговори.
  • Документирайте всяко известно, проверено ограничение, което съществено влияе върху дадено изискване.
  • Запишете всяко предположение в документа.

Често срещани грешки при писане на функционални изисквания

Често срещани грешки, допускани при създаването на документ с функционални изисквания, включват:

  • Добавяне на неоправдана допълнителна информация, която обърква разработчиците
  • Пропускайки детайлите, които разработчиците трябва да изградят функцията.
  • Правила за смесване, примери, scoping твърдения или цели в самото изискване.
  • Пропускане на информация, която е съществена за пълното и точно формулиране на изискването.
  • Защита на съществуващо изискване при получаване на заявка за промяна, вместо намиране на правилния отговор.
  • Изисквания за писане, които не са свързани с никаква цел или принцип.

Въпроси и Отговори

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

Copilot и GPT създават чернови на потребителски истории, критерии за приемане и shall-statements от кратки подкани. Бизнес анализатор редактира всеки резултат за тестваемост и потвърждава съответствието с бизнес целите преди официален преглед.

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

Използвайте ясен подлог, думата „shall“ и по едно проверимо действие за всяко твърдение. Избягвайте двусмислени думи като „fast“ и обхващайте едно поведение, така че изискването да може да бъде тествано с една проверка за преминаване или неуспех.

EARS, Easy Approach to Requirements Syntax (Лесен подход към синтаксиса на изискванията), предоставя пет шаблона: повсеместен, управляван от събития, управляван от състояния, опционална функция и нежелано поведение. Всеки от тях налага тестваема структура, като например Когато TRIGGER (ЗАПЪЛВАНЕ), системата трябва да ОТГОВОРИ.

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

Функционалните изисквания са движеща сила за тестови случаи в системни, интеграционни, цялостни, API и потребителски тестове за приемане. Всяко изискване е свързано с поне един тестов случай, а изискванията... Traceability Matrix потвърждава покритието преди пускането му.

Agile екипите изразяват функционалните изисквания като потребителски истории, използвайки формата „Като роля, искам способност, така че тази стойност“. Критериите за приемане, прикрепени към историята, превръщат изискването в проверимо определение за „готово“.

Обобщете тази публикация с: