Правила за съставяне на спецификация на изискванията към софтуера
Всички знаем много добре как се разработва софтуерът. Мислихме 10 минути и веднага отидохме да кодираме. Цикълът на разработка на софтуер се състои от много ключови моменти. Това са такива моменти като планиране, създаване на архитектура, създаване на SRS, създаване на дизайн и т.н., и т.н.
Какво е СРС?
SRS - Спецификация на софтуерните изисквания- специална документация за софтуер, която съдържа информация за това как трябва да се държи системата, какви функции трябва да изпълнява, какво натоварване трябва да издържа и т.н.
Защо е необходимо?
Всичко е изключително просто. Вие използвате TK (мотор), аз използвам SRS (кола). Надявам се, че аналогията е ясна. :)
Структура на СРС
По-долу е структурата на английски в сурова форма. По-долу в статията ще разгледаме всеки елемент по-подробно.
Предназначена аудитория и предложения за четене
Потребителски класове и характеристики
Ограничения при проектиране и изпълнение
Предположения и зависимости
Системна функция X (може да има няколко такива блока)
Описание и приоритет
Изисквания за външен интерфейс
нефункционални изисквания
Атрибути за качество на софтуера
Приложение A: Речник
Приложение B: Модели за анализ
Приложение C: Списък с проблеми
И така разбрахме структурата, сега нека да преминем към разделите и какво трябва да бъде написано в тях.
Основни изисквания към всички раздели на СРС
Кратко, ясно. Описва всичко много кратко и ясно. Колкото се може повече.
Без двусмислени описания. Човек, който чете СРС-тата, трябва да разбира точно какво пише, а не нещо друго. Закон на Мърфи: Ако можете да бъдете разбранигрешно, ще бъдете погрешно разбрани. Избягвай го
Простота и четливост. Не използвайте твърде неясни завои. Красотата е в простотата :)
DFD диаграми. Спецификацията не може да бъде пълна, ако не знаем какво има на входа на описания софтуер и какво на изхода. Всичко трябва да е ясно обозначено.
Степен на детайлност. Това е евристика. Може да се дефинира по следния начин: ако мога свободно да дам информация за функционалността и написаното не ме смущава, ако изискванията са недвусмислени и не подлежат на двойно разбиране, ако изискванията описват поведението на функционалността в достатъчна степен за мен, тогава разработването на SRS може да се счита за завършено
Обяснение на всяка позиция в структурата на СРС
Въведение \ ЦелВ този раздел ние описваме приложението или продукта, чиято функционалност ще бъде описана в SRS.Въведение \ Конвенции на документаТук описваме всички неясни технически думи или термини, открити в SRS. Имайте предвид, че описанието на неясна дума не може да съдържа друга неясна дума. Опитайте се да опишете възможно най-подробно термина, който използвате, на прост и разбираем език. Не пестете от този раздел, защото колкото повече неща запишете, толкова по-лесно ще бъде да проектирате по-късно.Въведение \ ПрепраткиВ този раздел пишем препратки към литературата, в която можете да намерите основата на използваните технологии и фактите. Да предположим, че можете да вмъкнете RFC, ако пишете приложение, което работи с TCP / IP, да вмъкнете връзки към документи, към които препращате, и т.н. Връзките и тяхното описание трябва да са възможно най-пълни, така че в този случай (връзката току-що умря) можете да търсите в Google този материал.Общо описание \ Характеристики на продуктаВ този раздел ниеописват части от функционалността на високо ниво. Всяка част от функционалността ще бъде описана по-подробно в нейния раздел по-долу. Тук е желателно да се постави DFD диаграма, която да показва цялостното взаимодействие на системата.Общо описание \ Работна средаКакто подсказва името на раздела, тук описваме средата, в която ще работи продуктът. ОС, версии на компилатор, бази данни, сървъри, софтуер, хардуер и други неща, които са необходими за работата на вашия продукт.Общо описание \ Ограничения на дизайна и изпълнениетоТози раздел е отвратителен :). Той ограничава полета на мисълта на разработчика, като налага стандарти за разработка. Такива ограничения могат да бъдат например такива неща:
Език за програмиране, база данни
Комуникационни стандарти
Ограничения, наложени от оперативната среда, разрешена е само съвместимост с FF
Ограничения, които могат да бъдат наложени от бизнес логиката на проекта
Заключение
SRS не е задължителен, но може да бъде полезен за средни до големи проекти. Използването на SRS показва вашето професионално ниво като разработчик.