Видове изисквания към софтуерните продукти, Алексей Киселев

Продуктов мениджър и анализатор на бизнес системи

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

И така, стандартният речник на IEEE за терминологията на софтуерното инженерство дефинира изискванията като:

Условия или възможности, необходими на потребителя за решаване на проблеми или постигане на цели;
Условия или възможности, които една система или системни компоненти трябва да има, за да изпълни договор или да удовлетвори стандарти, спецификации или други официални документи
Документирано представяне на условията или възможностите за клаузи 1 и 2

Какви са изискванията

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

бизнес изисквания

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

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

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

Функционални изисквания

Функционалните изисквания определят функционалността на софтуера, който разработчиците трябва да изградят, така че потребителите да могат да изпълняват своите задачи в рамките на бизнес изискванията. Понякога наричани поведенчески изисквания, те съдържат клаузи с традиционното „трябва“ или „трябва“: „Системата трябва да изпрати имейл на потребителя с потвърждение на поръчката“. Функционалните изисквания са документирани в спецификация на софтуерните изисквания (SRS), която описва, доколкото е необходимо, очакваното поведение на системата.

Системни изисквания

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

Бизнес правила

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

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

Нефункционалните изисквания описват целите и атрибутите на качеството. Атрибутите за качество са допълнително описание на функциите на продукта, изразени чрез описание на неговите характеристики, които са важни за потребителите или разработчиците. Тези характеристики включват: * лекота и лекота на използване * лекота на движение * цялостност * ефективност и устойчивост на грешки * външни взаимодействия между системата и външния свят * ограничения при дизайна и внедряването. Ограниченията (ограниченията) се отнасят до избора на възможността за развитие на външния вид и структурата на продукта

Характеристика на продукта

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

Какви характеристики трябва да имат добрите твърдения?

Качествени характеристики на висшите изисквания:

–Пълнота. Всяко изискване трябва да описва напълно функционалността, която трябва да бъде внедрена в продукта. Тоест трябва да съдържа цялата информациянеобходимо за разработчиците, за да разрешат темите за създаване на тази част от функционалността. Ако установите, че няма достатъчно данни от определен вид, използвайте знака „TBD“ (ще се определи) в полетата като стандартен флаг, за да подчертаете такова място. Попълнете всички пропуски във всеки фрагмент на изискване, преди да започнете да изграждате тази функция.

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

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

–Приоритизиране. Дайте приоритет на всяко изискване за функция, функция или случай на употреба, за да определите какво е необходимо за всяка версия на продукта. Ако всички разпоредби са еднакво важни, за ръководителя на проекта ще бъде трудно да се справи с бюджетни съкращения, пропуснати срокове, загуба на персонал или добавяне на нови изисквания в процеса.развитие, Повече информация Глава 14 обсъжда подробно приоритизирането.

–Уникалност. Всички читатели на изискванията трябва да ги интерпретират по един и същи начин, но естественият език често страда от двусмислие. Поддържайте документацията проста, кратка и точна, като използвате речник, който потребителите могат да разберат. „Яснотата“ е цел за качество на изискване, свързана с точността: читателите трябва ясно да разбират всяко твърдение. Запишете всички технически и объркващи термини в речник.

–Проверяемост. Обмислете разработването на множество тестове или други техники за проверка, като партньорска проверка или демонстрации, за да определите дали всяко изискване действително е внедрено в продукта. Ако дадено изискване не бъде проверено, въпросът за правилното му изпълнение става предмет на заключение, а не цел на анализа. Непълни, непоследователни, неизпълними или двусмислени изисквания също не се тестват.

Какви характеристики трябва да имат спецификациите на изискванията?

Наборът от изисквания, които съставляват спецификацията, трябва да отговаря на следните характеристики:

–Пълнота. Не трябва да се пропускат никакви изисквания или необходими данни.

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