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

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

Две категории изисквания

Изискванията за характеристиките, качеството на софтуерните продукти, информационните системи са големи. Те обаче могат да бъдат разделени на две широки категории - функционални и нефункционални изисквания. Важно е в началото на статията да се направи разграничение между тях. Така:
  • Функционални изисквания. Опишете какво точно трябва да бъде приложено в определена система или продукт, какви действия трябва да бъдат направени от потребителите във връзка с това развитие.
  • Нефункционални изисквания. Опишете как работи създадената система или софтуерен продукт, какви свойства и характеристики има специфично развитие.
  • Точка 1. Понятието за функционални и нефункционални изисквания, които сме формирали. Сега, нека преминем към втората точка - нека да разгледаме какво точно може да се припише на последната.


    Каква е категорията?

    По същество функционалните изисквания включват предимно различни характеристики на качеството на продукта. А именно - изискванията, които определят качествените характеристики на развитието (софтуер, информационна система). Това, разбира се, надеждност, мащабируемост, производителност на продукта. Следващото обаче е от голямо значениенефункционални изисквания:
  • Ограничения. Това означава, че условията, които ограничават избора на каквито и да било решения относно изпълнението на определени изисквания (или набори от изисквания). Те стесняват разнообразието от възможности за избор на инструменти, стратегии, инструменти за развитие на структурата (архитектурата) и появата на информационния продукт на софтуерен продукт.
  • Бизнес правила. Те включват насоки, политики, принципи, регулации, които по някакъв начин ограничават някои аспекти на бизнеса. Например, те могат да определят състава и правилата за изпълнение на всякакви бизнес проекти. Какво може да се припише на тази категория? Корпоративна политика, всякакви правителствени постановления и укази, индустриални стандарти, изчислителни алгоритми. Всички правила, които засягат развитието на дадена система, продукт, се използват при работа по проект.
  • Предложения за изпълнение. Групата включва конкретни предложения, които оценяват възможността за прилагане на определени архитектурни и технологични решения.
  • Външни интерфейси. Описание на ключовите аспекти на взаимодействието на продукта с други системи и работна среда. На първо място, това са изискванията за API системата или продукта, както и изискванията на API на други системи, които са планирани да интегрират разработвания продукт.
  • Разработени предложения за тестване, тестване на софтуер. Това е поредица от допълнения към изискванията, указващи как едно или друго изискване трябва да бъде проверено на практика.
  • Правни изисквания. До лицензиране на продукти, наличие на патент и др. Важно е да се отбележи, че нефункционалните системни изискванияпредварително зададени и фиксирани. Само тогава специалистът може да започне да разработва продукт.


    Примери на изисквания

    За да има по-ясна представа за нефункционалните изисквания на информационната система, помислете за няколко примера:
  • Ограничения. "Това развитие се извършва само на платформата на Vendor X". "При удостоверяване на потребител в информационна система трябва да се използват само техники за биометрична идентификация."
  • Бизнес правила. "При изпращане на продукт мениджърът е длъжен да поиска от счетоводителя на фактурата на предприятието и фактурите за доставка и изпращане." "Поръчката ще бъде анулирана, ако плащането по сметката не е получено от доставчика в рамките на 14 дни."
  • Външни интерфейси. "Осигуряване на регистриране на операционната система на такива събития: съобщение за стартиране и спиране на услугата X." "Уверете се, че дневникът на програмата е записан в параметрите на програмата на програмата: ядрото, скенерът, антивирусната база данни и информацията трябва да бъде въведена в дневника както при стартиране, така и при възстановяване на модулите."
  • Как се определят тези изисквания?

    Ние анализирахме конкретни примери за функционални изисквания. И сега друг важен въпрос е: "Как да ги идентифицираме по отношение на определен продукт?"
    На първо място, експерти правят образец, в който са изброени основните видове нефункционални изисквания за продукта. Преди всичко е необходимо, за да не пропуснете нито една позиция от този списък. Разработчиците обикновено избират източници за изготвяне на подобни шаблониследното:
  • ГОСТ (държавен стандарт на Руската федерация) 34-та серия.
  • Книгата "Разработване на софтуерни изисквания" (от K. Wigers). По-специално, трябва да обърнете внимание на раздела "Приложение Ж". Той съдържа конкретни примери за изисквания към документацията.
  • Нека сега разгледаме кой конкретно се занимава с тази работа.

    Определяне на изискванията към продуктите

    В разработването на функционални и нефункционални изисквания за системата участват специални работни групи. Техните членове определят не само, но и проверяват, одобряват тези предписания.
    Що се отнася до нефункционалната категория, важно е да се включат не само потребителите и анализаторите, но също така и ключови продуктови разработчици, системни архитекти, както и група тестери за нейното определение. Защо това е важно? Един архитект, да речем, ще възприеме нефункционалните изисквания като входни данни за избор и проектиране на архитектурата на програмата. И екипът за тестване ще планира подходящите сценарии за тестване на зареждането. Именно чрез последното ще бъдат проверени изискванията за ефективност. Като цяло това се отнася за качествата на качеството.

    Ролите на участниците в работните групи

    Нека сега разгледаме какви роли се споделят между членовете на екипа, които дефинират и одобряват нефункционалните изисквания за продуктите:
  • Потребители. Тези участници оценяват стойностите на параметрите, които определят нефункционалните изисквания.
  • Системен анализатор. Този участник събира, анализира,систематизира и документира нефункционални изисквания.
  • Ключови предприемачи и архитект на системите. Каква роля играе тази група? Участвайте в определянето, анализа на нефункционалните изисквания и ги проверявайте за степента на прилагане в живота.
  • Група за изпитване. Участва и в определянето, анализа на списъка на нефункционалните изисквания за програмата. Освен това разработва тестови сценарии за тези предписания.
  • Сценарий за определяне на изискванията

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

  • Системата получава сигнал за събитието, като започва изпращане на електронни съобщения.
  • Системата изпраща съобщения до потребителите в списък А, като използва шаблон Б. За изпращане на съобщения се използва услугата.
  • В случай, че операцията не може да бъде завършена, системата ще се опита отново да предаде съобщенията.
  • Формиране на продуктовите изисквания по сценарий

    И сега ние ще изискаме сценарий, който е бил формиран в предишния подзаглавие:
  • Изисквания за времето на обявяване на събитие, което задейства разпространението на съобщения: системата трябва да получи уведомление за събитие, инициирайки пощенски списък , не по-късно от X минути след настъпването му.
  • Изисквания за изпращане на съобщения: съобщенията трябва да бъдат изпратени от системата не по-късно от X секунди след получаване на сигнал за събитие.
  • Изисквания за повторно изпращане на съобщения в случай на неуспешен опит: броят на повторенията следва да бъде X. Интервал - X минути от всеки случай на неуспешно изпращане на съобщения.
  • Критерии за важни изисквания

    Най-нефункционалните изисквания трябва стриктно да съответстват на редица качествени критерии спрямо тяхното съдържание:
  • Пълнота (като отделно изискване и пълен списък). Какво означава това? Искането трябва да съдържа цялата необходима информация за нейната реализация.
  • Недвусмислено. Изискването не трябва да противоречи на себе си или други елементи от списъка. Всички професионалисти, работещи с него, трябва да го разбират по същия начин.
  • Правилността на отделно изискване, което гарантира системна последователност.
  • Необходимост. Осъществяването на това изискване е наистина необходимо за потребителите.
  • Осъществимост. Осъзнайте това изискване на живота.
  • Поверителност. Необходимо е да се осигури недвусмислена проверка на нейното изпълнение.
  • Запознахме се с такава концепция като нефункционални изисквания за софтуерен продукт, информационна система. Те също така демонтираха своите конкретни примери, за разлика от функционалната категория, критериите за качество на категорията. Знаете кои групи професионалисти създават и одобряват тези предписания.

    Свързани публикации