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

SRS е спецификация за конкретен софтуерен продукт, програма или набор от приложения, които изпълняват определени функции в специфична среда. Той служи на няколко цели в зависимост от това кой го пише. Първо, SRS може да бъде написан от клиента на системата. Второ, СРС може да бъде написан от разработчик на системата. Двата метода създават напълно различни ситуации и установяват напълно различни цели за документа. Първият случай, SRS, се използва за определяне на нуждите и очакванията на потребителите. Вторият случай, SRS, се пише за различни цели и служи като договорен документ между клиента и разработчика.

Характеристики на доброто SRS

Следват характеристиките на добрия СРС документ:

1. Коректност: Потребителският преглед се използва за осигуряване на точността на изискванията, посочени в SRS. SRS се смята за перфектен, ако покрива всички нужди, които наистина се очакват от системата.

2. Пълнота: СРС е пълна тогава и само ако включва следните елементи:

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

връщане на масив java

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

Забележка: Важно е да посочите отговорите както за валидни, така и за невалидни стойности.

(3). Пълни етикети и препратки към всички фигури, таблици и диаграми в SRS и дефиниции на всички термини и мерни единици.

3. Консистенция: SRS е последователен, ако и само ако няма подмножество от индивидуални изисквания, описани в неговия конфликт. Има три вида възможни конфликти в СРС:

(1). Посочените характеристики на обекти от реалния свят може да са в конфликт. Например,

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

(b) Едно условие може да гласи, че всички светлини трябва да са зелени, докато друго гласи, че всички светлини трябва да са сини.

(2). Възможно е да има разумен или временен конфликт между двете посочени действия. Например,

(a) Едно изискване може да определи, че програмата ще добави два входа, а друго може да определи, че програмата ще ги умножи.

(b) Едно условие може да гласи, че „A“ трябва винаги да следва „B“, докато друго изисква „A и B“ да се срещат едновременно.

(3). Две или повече изисквания могат да дефинират един и същ обект от реалния свят, но да използват различни термини за този обект. Например заявка на програма за потребителски вход може да се нарече „подкана“ в едно изискване и „подсказка“ в друго. Използването на стандартна терминология и описания насърчава последователността.

4. Еднозначност: СРС е еднозначна, когато всяко фиксирано изискване има само едно тълкуване. Това предполага, че всеки елемент се интерпретира уникално. В случай че има използван метод с множество дефиниции, докладът за изискванията трябва да определи последиците в SRS, така че да е ясен и лесен за разбиране.

int към преобразуване на низ

5. Класиране по важност и стабилност: SRS се класира по важност и стабилност, ако всяко изискване в него има идентификатор, който да показва или значимостта, или стабилността на това конкретно изискване.

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

6. Възможност за промяна: SRS трябва да бъде възможно най-много модифицируем и трябва да може бързо да получава промени в системата до известна степен. Модификациите трябва да бъдат перфектно индексирани и кръстосано препратени.

7. Проверяемост: SRS е правилен, когато посочените изисквания могат да бъдат проверени с рентабилна система, за да се провери дали крайният софтуер отговаря на тези изисквания. Изискванията се проверяват с помощта на прегледи.

8. Проследимост: SRS е проследим, ако произходът на всяко от изискванията е ясен и ако улеснява позоваването на всяко условие в документацията за бъдещо развитие или подобрение.

Има два вида проследимост:

1. Проследимост назад: Това зависи от всяко изискване, което изрично се позовава на своя източник в по-ранни документи.

2. Проследяемост: Това зависи от това дали всеки елемент в SRS има уникално име или референтен номер.

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

9. Независимост на дизайна: Трябва да има опция за избор от множество алтернативи на дизайна за крайната система. По-конкретно, SRS не трябва да съдържа никакви подробности за изпълнението.

10. Тестваемост: SRS трябва да бъде написан по такъв метод, че да е лесно да се генерират тестови случаи и тестови планове от доклада.

11. Разбираемо за клиента: Крайният потребител може да е експерт в своята изрична област, но може да не е обучен по компютърни науки. Следователно целта на формалните означения и символи също трябва да се избягва във възможно най-голяма степен. Езикът трябва да бъде прост и ясен.

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

Свойства на добър СРС документ

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

Кратко: Докладът за СРС трябва да бъде кратък и в същото време недвусмислен, последователен и пълен. Многословните и неуместни описания намаляват четливостта и също така увеличават възможностите за грешки.

Структуриран: Тя трябва да бъде добре структурирана. Добре структуриран документ е лесен за разбиране и модифициране. На практика SRS документът претърпява няколко ревизии, за да се справи с изискванията на потребителите. Често изискванията на потребителя се развиват за определен период от време. Ето защо, за да направите промените в СРС документа лесни, е жизненоважно отчетът да бъде добре структуриран.

Изглед в черна кутия: Трябва само да дефинира какво трябва да прави системата и да се въздържа от посочване как да се направи това. Това означава, че SRS документът трябва да определя външното поведение на системата, а не да обсъжда проблемите на внедряването. Докладът за SRS трябва да разглежда системата, която ще бъде разработена, като черна кутия и трябва да определя външно видимото поведение на системата. Поради тази причина докладът SRS е известен също като спецификацията на черната кутия на системата.

Концептуална цялост: Тя трябва да показва концептуална цялост, така че читателят да може просто да я разбере. Отговор на нежелани събития: Трябва да характеризира приемлив отговор на нежелани събития. Те се наричат ​​реакция на системата при изключителни условия.

какво е uri

Проверими: Всички изисквания на системата, както са документирани в SRS документа, трябва да са правилни. Това означава, че трябва да е възможно да се реши дали изискванията са били изпълнени или не при изпълнение.