Вовед
-----

**Софтверските барања** се дел од софтверското инженерство што се занимава со **описот, анализа, спецификација и валидација на барањата за софтверот**.
Спецификацијата на софтверските барања претставува почетна фаза во софтверскиот процес и претставува комплетно опишување на однесувањето на системот што треба да се создаде. Во тие барања е вклучено и множество на кориснички случаи, коишто ја опишуваат интеракцијата што ќе ја имаат корисниците со софтверот.

Опис на барањата
----------------

Описот на барањата е процес во кои се извлекуваат, собираат барањата за системот од клиентите, односно од клиентот се дознаваат информации за тоа што сака неговиот систем да прави, кои функции да ги има, кои одлики и друго.

Во описот на барањата се користат различни техники со кои се овозможува од корисникот да бидат добиени сите потребни информации. Такви техники се: интервју, пополнување на прашалници, корисничко набљудување, работилници, бура на идеи, прототип и други.

### Проблеми

Во 1992 година Кристел и Канг (Christel and Kang) ги идентификувале проблемите што можеле да настанатат при описот на барањата:

1. **Проблеми со областа** – границите на системот се лошо дефинирани. Клиентите навеле премногу непотребни технички детали кои доведуваат до забуни, наместо јасно да бидат дефинирани целите на производот.
2. **Проблеми на разбирања** – Клиентите не се сигурни што е потребно, имаат минимални познавања и не го разбираат доменот на проблемот, имаат проблеми со комуникацијата со систем инженерот, не ги наведуваат барањата за кои мислат дека се ,,очигледни‘‘, наведуваат двосмислени и контрадикторни барања.
3. **Проблеми со нестабилноста** – Барањата од време на време се сменуваат, корисниците честопати, откако кажале веќе некое барање, сакаат да го променат. Тоа доведува до зголемување на трошоците.

Анализа на барања
-----------------

Анализата на софтверски барања опфаќа утврдување на барањата или условите кои треба да бидат исполнети, без разлика дали се работи за нов производ или производ кои ќе треба да биде изменет. Аналитичарот честопати доаѓа до конфликтни барања од страна на клиентите и неговата задача е успешно да ги разреши со нивна помош. Оваа фаза се прави на почеток на развојот на софтвер и е доста значајна за успешноста на проектот.

Спецификација на софтверските барања
------------------------------------

Документот за спецификација на софтверските барања ги вклучува сите потребни барања за развојот на проектот. Тој треба да биде напишан на едноставен и на недвосмислен јазик и со минимални технички познавања, така што секој ќе може да го разбере. Во принцип спецификацијата на софтверските барања треба да ги има следните точки:

* Вовед
	+ Цели
	+ Област на производот
	+ Дефиниции
	+ Преглед на системот
	+ Наводи
* Целосен опис
	+ Перспектива на производот
	+ Функции на производот
	+ Одлики на корисниците
	+ Ограничувања, претпоставки и зависности
* Специфични барања
	+ Надворешно однесување
	+ Функционални барања
	+ Барања за перформанси
	+ Ограничувања за дизајнот
	+ Барање за логичка база на податоци
	+ Атрибути на системот
	+ Други барања

Според IEEE стандардите, оние коишто ја пишуваат спецификацијата на барања најмногу внимание треба да посветат на следните прашања: 
  

**Функционални барања** - Што треба софтверот да прави, кои функции да ги извршува?
  

**Надворешно однесување** – Каква треба да биде интеракцијата помеѓу софтверот со корисниците, со хардверот, со друг помошен хардвер и со друг софтвер?
  

**Перформанси** – Какви можности треба да има системот, односно за колку време треба да изврши одредена задача, брзина, меморија и слично?
  

**Атрибути** - Какви критериуми за квалитет треба да поседува: портабилноста, коректност, доверливост, одржливост, размерливост и друго?
  

**Ограничувања во дизајнот** – Дали има дополнителни барања околу дизајнот, имлементација на јазик, ограниченост на ресурси и друго?

Валидација и верификација на барањата
-------------------------------------

Документот со барањата може да биде предмет на валидација и верификација, со цел да се утврди дека софтверскиот инженер ги разбрал барањата и се потврдува дека документот со барањата е според стандардите, разбирлив е и комплетен. Во оваа активност се откриваат грешките во барањата и се прават измени со цел тие да бидат поправени.

Наводи
------

1. ↑  Pierre Bourque and Robert Dupuis, уред. (2004). *Guide to the Software Engineering Body of Knowledge - 2004 Version*. IEEE Computer Society. стр. 2–1. ISBN 0-7695-2330-7.
2. ↑  Requirements Engineering A good practice guide, Ian Sommerville and Pete Sawyer, John Wiley and Sons, 1997
3. ↑  Christel, Michael and Kyo C. Kang (September 1992). „Issues in Requirements Elicitation". *Technical Report CMU/SEI-92-TR-012*. CMU / SEI. Посетено на January 14, 2012.
4. ↑  Kotonya, G. and Sommerville, I. 1998. *Requirements Engineering: Processes and Techniques* Chichester, UK: John Wiley and Sons.
5. ↑  Executive editors: Alain Abran, James W. Moore; editors Pierre Bourque, Robert Dupuis, уред. (2005). *Guide to the software engineering body of knowledge*. Chapter 2: Software Requirements (2004. изд.). Los Alamitos, CA: IEEE Computer Society Press. ISBN 0-7695-2330-7. Архивирано од изворникот на 2009-05-27. Посетено на 2007-02-08. It is widely acknowledged within the software industry that software engineering projects are critically vulnerable when these activities are performed poorly.CS1-одржување: повеќе имиња: список на уредници (link)
6. ↑  Stellman, Andrew and Greene, Jennifer (2005). *Applied software project management*. O'Reilly Media, Inc. стр. 308. ISBN 0596009488.CS1-одржување: повеќе имиња: список на автори (link)
7. ↑  How to write a software requirements specification проверено на 25.03.2012
8. ↑  Requirements Validation Архивирано на 7 април 2012 г. проверено на 01.04.2012