Фаза производње захтева процеса развоја софтвера је Спецификације софтверских захтева (СРС) (такође се зове а документ са захтевима ). Овај извештај поставља основу за активности софтверског инжењеринга и конструише се када се открију и анализирају целокупни захтеви. СРС је формални извештај, који делује као репрезентација софтвера који омогућава корисницима да увере да ли је (СРС) у складу са њиховим захтевима. Такође, садржи захтеве корисника за систем, као и детаљне спецификације системских захтева.

СРС је спецификација за одређени софтверски производ, програм или скуп апликација које обављају одређене функције у одређеном окружењу. Има неколико циљева у зависности од тога ко га пише. Прво, СРС би могао да напише клијент система. Друго, СРС би могао да напише програмер система. Ове две методе стварају потпуно различите ситуације и успостављају различите сврхе за документ. Први случај, СРС, користи се за дефинисање потреба и очекивања корисника. Други случај, СРС, написан је за различите сврхе и служи као уговорни документ између купца и програмера.

Карактеристике доброг СРС

Ово су карактеристике доброг СРС документа:

1. Исправност: Преглед корисника се користи да би се обезбедила тачност захтева наведених у СРС. За СРС се каже да је савршена ако покрије све потребе које се истински очекују од система.

2. Потпуност: СРС је потпун ако и само ако садржи следеће елементе:

(1). Сви суштински захтеви, било да се односе на функционалност, перформансе, дизајн, ограничења, атрибуте или екстерне интерфејсе.

поверсхелл коментар вишелинијски

(2). Дефинисање њихових одговора софтвера на све оствариве класе улазних података у свим доступним категоријама ситуација.

Напомена: Неопходно је навести одговоре на важеће и неважеће вредности.

(3). Пуне ознаке и референце на све слике, табеле и дијаграме у СРС и дефиниције свих појмова и мерних јединица.

3. Конзистентност: СРС је конзистентан ако и само ако нема подскупа појединачних захтева описаних у његовом сукобу. Постоје три врсте могућих сукоба у СРС:

(1). Наведене карактеристике објеката из стварног света могу бити сукобљене. На пример,

(а) Формат излазног извештаја може се у једном захтеву описати као табеларни, ау другом као текстуални.

(б) Један услов може навести да ће сва светла бити зелена, док други наводи да ће сва светла бити плава.

(2). Може постојати разуман или привремени сукоб између две наведене радње. На пример,

(а) Један услов може одредити да ће програм додати два улаза, а други може одредити да ће их програм помножити.

(б) Један услов може да каже да 'А' увек мора следити 'Б', док други захтева да се 'А и Б' појављују заједно.

(3). Два или више захтева могу дефинисати исти објекат из стварног света, али користити различите термине за тај објекат. На пример, захтев програма за кориснички унос може се назвати 'промпт' у једном захтеву и 'цуе' у другом. Употреба стандардне терминологије и описа промовише доследност.

4. Недвосмисленост: СРС је недвосмислен када сваки фиксни захтев има само једно тумачење. Ово сугерише да је сваки елемент јединствено интерпретиран. У случају да се користи метода са више дефиниција, извештај о захтевима треба да одреди импликације у СРС-у тако да буде јасан и једноставан за разумевање.

5. Рангирање по важности и стабилности: СРС се рангира по важности и стабилности ако сваки захтев у њему има идентификатор који указује на значај или стабилност тог конкретног захтева.

Обично сви захтеви нису подједнако важни. Неки предуслови могу бити неопходни, посебно за апликације које су критичне за живот, док други могу бити пожељни. Сваки елемент треба идентификовати како би ове разлике биле јасне и експлицитне. Други начин за рангирање захтева је разликовање класа ставки као основних, условних и опционих.

6. Промењивост: СРС би требало да буде могуће модификовати што је вероватније и требало би да буде способан да у одређеној мери брзо добије промене у систему. Измене треба да буду савршено индексиране и укрштене.

7. Проверљивост: СРС је тачан када се наведени захтеви могу верификовати помоћу исплативог система да би се проверило да ли коначни софтвер испуњава те захтеве. Захтеви се проверавају уз помоћ прегледа.

8. Следљивост: СРС је следљив ако је порекло сваког од захтева јасно и ако олакшава референцирање сваког услова у документацији о будућем развоју или побољшању.

Постоје две врсте следљивости:

карактер на стринг

1. Следљивост уназад: Ово зависи од тога да сваки захтев експлицитно наводи свој извор у ранијим документима.

2. Следљивост унапред: Ово зависи од тога да ли сваки елемент у СРС има јединствено име или референтни број.

на стринг метод јава

Сљедивост СРС-а је посебно кључна када софтверски производ улази у фазу рада и одржавања. Како се шифра и пројектни документ мењају, неопходно је бити у стању да утврди комплетан скуп захтева који се могу односити на те измене.

9. Независност дизајна: Требало би да постоји могућност избора између вишеструких алтернатива дизајна за коначни систем. Тачније, СРС не би требало да садржи никакве детаље о имплементацији.

10. Тестабилност: СРС треба да буде написан на такав начин да се из извештаја лако генеришу тест случајеви и планови тестирања.

11. Разумљиво за купца: Крајњи корисник може бити стручњак у свом експлицитном домену, али можда није обучен у рачунарству. Стога, сврху формалних ознака и симбола треба избегавати у највећој могућој мери. Језик треба да буде једноставан и јасан.

12. Прави ниво апстракције: Ако је СРС написан за фазу захтева, детаље треба експлицитно објаснити. Док се за студију изводљивости може користити мање анализа. Дакле, ниво апстракције се мења у складу са циљем СРС.

Особине доброг документа СРС

Основна својства доброг СРС документа су следећа:

Јасан: Извештај СРС треба да буде сажет и истовремено недвосмислен, доследан и потпун. Опширни и нерелевантни описи смањују читљивост и такође повећавају могућност грешке.

Структурирано: Требало би да буде добро структурисано. Добро структуиран документ је једноставан за разумевање и измену. У пракси, СРС документ се подвргава неколико ревизија како би задовољио захтеве корисника. Често се захтеви корисника развијају током одређеног временског периода. Стога, да би се олакшале измене документа СРС, од виталног је значаја да извештај буде добро структуриран.

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

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

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