Креирање софтвера се не састоји само од развоја. Пре него што почну да раде на софтверу, програмери морају тачно да знају шта да креирају. Зато развој обично почиње са припремом гомиле докумената који детаљно описују будући пројекат. Документи обухватају бројна истраживања, анализе и спецификације, од којих је једна спецификација софтверских захтева (СРС).
Овај чланак је посвећен СРС-у, његовом значају за ваш пројекат и корацима за креирање висококвалитетних софтверских спецификација. Уронимо у тему дефинисањем СРС.
стд тестирање НИЦ истог дана
Шта је документација захтева софтвера и зашто вам је потребна?
Документација о захтевима софтвера је документ који описује функционалне и нефункционалне спецификације софтвера, начин на који ће се развијати и случајеве употребе – начине на које ће корисници комуницирати са софтвером када буде спреман. Извештај СРС се обично припрема током фаза откривања пројекта . Власници предузећа могу сами структурисати све спецификације или поверити овај задатак професионалцима који имају искуства у развоју софтвера и дефинисању спецификација.
Неки власници предузећа можда желе да прескоче фазу откривања, укључујући припрему документације. Међутим, занемаривање ове фазе може довести до неуспеха пројекта. Према истраживању Пулса професије ПМИ, 35% пројеката пропадају због нетачних захтева. Да ли би било који власник предузећа одбио да одржи скуп СРС-а да је раније знао ову статистику? Сумњамо у то. Дакле, ево како ваш тим има користи од тога да има све софтверске захтеве на једном месту:
- Девелоперс одлучити о техничком стеку који ће им требати да направе позадину и предњи крај софтвера
- Дизајнери добију идеју о томе како могу да одражавају функционалност у софтверском интерфејсу
- Тестери стекну разумевање тест случајева које ће им требати да припреме и осигурају да софтвер испуњава пословне захтеве
- Предузетници добију листу карактеристика неопходних за њихов производ и могу донети информисане одлуке о инвестицијама
Све у свему, документација захтева за софтвер је смерница која обезбеђује да сви укључени у процес развоја софтвера имају јасну визију процеса и иста очекивања. Дакле, извештај СРС омогућава избегавање неспоразума и неспоразума унутар тима.
Ако одлучите да сами радите на креирању спецификација, можете користити неке од спецификација софтвера примери можете пронаћи на интернету. Ако желите да делегирате овај задатак професионалцима, уверите се да сте пронашли поуздану компанију која има јак тим пословних аналитичара, менаџера пројеката, програмера и тестера који могу да обезбеде спецификације високог квалитета.
Ствари које треба да знате пре него што напишете СРС извештај
Да бисте правилно идентификовали софтверске захтеве, важно је знати коју вредност софтвер треба да донесе пословању и корисницима софтвера. Такође је важно знати карактеристике високог квалитета спецификације софтвера .
Захтеви пословања и корисника
Пословни и кориснички захтеви одражавају суштину софтвера који ће бити направљен. Пословни захтеви описују циљеве које власници предузећа желе да постигну са одређеним софтвером. Циљеви могу бити различити: аутоматизација процеса, минимизирање броја запослених и хардвера итд. Захтеви корисника варирају у зависности од врсте софтвера. Међутим, у већини случајева, корисници желе апликације које раде брзо и које су интуитивне за употребу. Важно је узети у обзир ове захтеве да бисте написали детаљне спецификације.
Карактеристике висококвалитетних СРС
Да би извештај спецификације софтверских захтева био од максималне користи за пројекат и тим, важно је да га направите:
- комплетан тако да сваки члан тима укључен у пројекат пронађе потребне информације у извештају. Програмери треба да пронађу техничке захтеве, док УИ/УКС дизајнери треба да имају опште смернице за дизајн. Тестери би требало да разумеју како софтвер треба да ради да би га правилно тестирали. Власницима производа је потребан овај документ да би имали јасну визију свог пројекта.
- Меасурабле тако да можете да упоредите готов производ са спецификацијама које сте припремили на самом почетку. Нема смисла рећи да ваш софтвер треба да испуни све захтеве.
- Флексибилно. СРС извештај није нешто што напишете једном и не можете да промените до краја пројекта. Напротив, захтеви се могу променити како се рад на пројекту одвија. Стога, формат вашег извештаја треба да буде згодан за прилагођавање кад год вам затреба.
- Јасно и тачно. Важно је избегавати сувишне фразе и двосмисленост. Сваки процес треба описати једноставним речима, са листом технологија неопходних за прављење софтвера.
Сада, када знате које су ствари кључне за документацију о захтевима за софтвер високог квалитета, време је да видите од чега се она састоји.
Компоненте спецификације софтверских захтева
Извештај СРС-а треба да буде доследан, тако да је важно да се придржавате специфичне структуре која помаже читаоцима да лако схвате информације. У наставку описујемо главне делове које би пристојан СРС требало да садржи.
Увод
Увод би требало укратко да објасни који ће софтвер бити направљен тако да сваки члан тима добије опште разумевање пројекта на којем ради.
Циљана публика
У овом делу, аутори извештаја помињу све чланове тима који имају приступ документу. По правилу, то су софтверски инжењери, тестери, дизајнери и менаџери пројеката. Власник производа који наручи развој софтвера такође треба да буде укључен у ову листу и да има прилику да погледа документ у било ком тренутку како би се уверио да све иде како је планирано.
Општи опис
Овај одељак описује функције које софтвер треба да изврши. Такође ћете пронаћи корисничке улоге и случајеве коришћења. У овом делу могуће је описати претпоставке и зависности да би се предвидели могући изазови и начини за њихово превазилажење. Ограничења дизајна такође могу бити укључена у овај одељак.
Захтеви за спољни интерфејс
Овај део СРС извештаја описује начин на који би корисници, хардвер и софтвер требало да буду у интеракцији. Одељак се може поделити на четири дела:
- Тхе корисничких интерфејса део описује како ће корисници комуницирати са софтвером.
- Тхе хардверски интерфејси део је о интеракцији између хардвера и софтвера.
- Тхе софтверски интерфејси део објашњава како је софтвер у корелацији са својим компонентама укључујући оперативне системе, библиотеке, базе података итд.
- Тхе комуникациони интерфејси део описује комуникационе канале који се користе унутар софтвера: е-пошту, претраживаче, серверске протоколе итд.
Функционални захтеви
Овај одељак говори о начину на који ће софтвер функционисати. Описује сваку функцију тако да сви чланови тима могу да разумеју обим посла. Функционални захтеви треба да се састоје од описа тока рада система, понашања ако/тада, логике руковања подацима и улаза и излаза података.
Буффало Сабрес распоред 2016 17
Што је детаљнији опис функционалности, мање су шансе за прераду у будућности. Детаљан опис функционалних захтева такође омогућава процену времена и трошкова развоја.
Голден Цоррал Сирацусе Нев Иорк
Нефункционални захтеви
Овај одељак описује жељене перформансе софтвера које се изражавају као његова својства. По правилу, главни нефункционални захтеви су безбедност, употребљивост, могућност тестирања, скалабилност итд.
Прилози
У овом одељку требало би да прикупите све информације које ће вам помоћи да боље разумете главне спецификације. Овај одељак је место за скраћенице, термине и њихове дефиниције, дијаграме, шеме итд.
Горе поменути оквир се може мењати у зависности од пројекта, типа апликације коју треба да се направи, сложености апликације итд. Можете променити нацрт на начин који је погоднији за ваш тим да га перципира, али треба да укључите све главне одељке да бисте имали потпуне информације о пројекту.
Алати за израду СРС извештаја
Без обзира који алат одаберете да креирате спецификације софтверских захтева за ваш пројекат, документ би требало да буде згодан за коришћење и дељење од стране свих чланова укључених у пројекат. У наставку наводимо неколико популарних начина и алата за генерисање СРС извештаја.
Гоогле документи
Многи пословни аналитичари се одлучују за Гоогле услуге као што су Гоогле документи или Гоогле табеле јер су једноставне за коришћење и уређивање. Штавише, аутори извештаја могу експериментисати са приказима докумената како би их учинили читљивијим за друге. Будући да су услуге у облаку, Гоогле документи и табеле су такође погоднији за дељење у поређењу са Мицрософт документима или другим уредницима текста ван мреже.
Пеарл
Пеарл је алатка за управљање захтевима која чини руковање свим задацима у вези са спецификацијама што је могуће лакшим. Све што треба да урадите је да дефинишете случајеве коришћења, корисничке улоге, услове и токове. Када то урадите, можете да генеришете извештај једним кликом. Још једна добра ствар у вези са Пеарл алатом је то што омогућава обавештења и коментаре за згодан тимски рад.
Хелик РМ
Хелик РМ је још један алат који олакшава рад са спецификацијама. Његова опсежна функционалност омогућава тимовима да раде са спецификацијама уз максималну погодност. Конкретно, Хелик РМ својим корисницима пружа графичке алате, могућност праћења захтева, функције сарадње у реалном времену и још много тога. Велика предност алата је његова интеграција са различитим софтвером као што су Слацк, Јира, ГитХуб, итд.
Закључак
Правилно израђена документација о захтевима за софтвер чини ⅓ успеха вашег пројекта, тако да је од виталног значаја да обратите пажњу на овај део када развијате софтвер. СРС извештај можете радити сами или са тимом пословних аналитичара и софтверских инжењера компаније коју одаберете за сарадњу.
Без обзира ко ће писати спецификације и које ће програме користити за то, требало би да се уверите да је документација о вашим софтверским захтевима јасна, доследна, мерљива, флексибилна и потпуна.
