Правила составления Software requirements specification
Все мы прекрасно знаем о том, как разрабатывается ПО. Подумали 10 минут и сразу пошли кодить. Цикл создания программного обеспечения состоит из многих ключевых моментов. Это такие моменты как планирование, создания архитектуры, создание SRS, создание дизайна и тд и тп.
SRS — Software Requirement Specification — специальная документация для ПО которая содержит в себе информацию о том, как должна себя вести система, какие функции должна выполнять, какую нагрузку должна выдерживать и тд.
Все предельно просто. Вы используете ТЗ (велосипед), я использую SRS (машину). Надеюсь аналогия получилась ясная? 
Структура SRS
Ниже приведена структура на англ языке в raw виде. Чуть ниже в статье мы рассмотрим каждый пункт более подробно
И так со структурой разобрались, теперь перейдем к разделам и тому, что в них надо писать.
Базовые требования ко всем разделам SRS
Пояснение каждого пункта структуры SRS
Introduction \ Purpose
В данной секции описываем приложение или продукт, функционал которого будет описываться в SRS.
Introduction \ Document conventions
Здесь мы описываем все непонятные технические слова или термины которые встречаются в SRS. Заметьте, что описание непонятного слова не может содержать другое непонятное слово. Старайтесь расписать как можно подробнее термин который Вы используете простым и понятным всем языком. Не экономьте на этой секции потому, что чем больше вы распишете непонятных вещей, тем проще будет потом проектировать.
Introduction \ References
В данной секции мы пишем ссылки на литературу в которой можно найти основания использованных технологий и фактов. Допустим можно вставлять RFC если вы пишете приложение работающее с TCP/IP, вставлять ссылки на документы на которые вы ссылаетесь и тд. Ссылки и их описание должны быть максимально полными, чтобы в случае чего (линк умер просто) можно было нагуглить этот материал.
Overall Description \ Product features
В данном разделе мы описываем части функционала на высоком уровне. Более детально каждая часть функционала будет описана в своем разделе ниже. Тут желательно разместить DFD-диаграмму которая покажет общее взаимодействие системы.
Overall Description \ Operating environment
Как понятно из названия раздела тут мы описываем окружение в котором будет работать продукт. ОС, версии компиляторов, базы данных, сервера, софт, железо и другие вещи которые необходимы для работы вашего продукта.
Overall Description \ User documentation
Описываем какая документация нужна для пользователей данного продукта. Возможно это книга по HTML если это HTML редактор.
System features \ System feature X
Называем фичу проекту и даем ей уникальный идентификатор. Например, server.html.editor. Уникальный идентификатор дается для того, чтобы потом где то в тикетах ваших не писать — «а вот та хреновина, которая позволяет редактировать хтмл»
System features \ System feature X \ Description and priority
Описываем детально фичу продукта. Для чего она? Что должна делать? Какой у нее приоритет выполнения. Из этого раздела читающему срс человеку должно сразу стать понятно зачем этот функционал присутствует в системе.
System features \ System feature X \ Stimulus/Response sequences
Триггер запуска фичи. Когда она запускается и как себя ведет при запуске? Например, HTML редактор показывается при нажатии пользователя на ссылку меню Открыть HTML редактор
System features \ System feature X \ Functional requirements
Подробное и детальное описание фичи. Описываем все: как работает, как реагирует на ошибки, что должно проверять, как отображать данные, как и куда что сохраняет и тд
External interface requirements
Описание того как система будет взаимодействовать с внешним миров. Если будет конечно. Какие API, как получить те или иные данные и тп. Подразделы служат для детализации требований. Какие софт интерфейсы, «железячные» интерфейсы, комуникационные интерфейсы и прочее.
Non functional requirements
Не функциональные требования. Есть требования которые невозможно описать как какую то фичу, например, требования к безопасности.
Non functional requirements \ Performance requirements
Требования к производительности. Это не фича, однако налагает определенные ограничения. Допустим база данных проекта должна выдерживать 1000 запросов в секунду и тп. Эти требования приводят к колоссальной работе по оптимизации проекта.
Non functional requirements \ Software quality attributes
Тут мы описываем требования к качеству кода. Какие тесты использовать? Какие метрики использовать для определения качества кода? Сколько кода должно быть покрыто тестами?
Non functional requirements \ Security requirements
Требования по безопасности. Если это HTML редактор, через которые можно изменять что-то на сайте, то это может быть нечто вроде: через HTML редактор не должно быть возможности поставить shell на сервер и тп
Appendix A: Glossary
Приложение. Иногда в SRS пытаются вставлять описание протоколов и тд и тп. Этого делать не нужно. Однако иногда нужно таки прояснить какую то концепцию. Для этого существует этот раздел. Вставляем ссылочки на такие пояснения. Такой себе словарик.
Appendix B: Analysis Models
Раздел определяет какие диаграммы нужно использовать при написании SRS. Например, DFD, какие то общие диаграммы взаимодействия и работы
Appendix C: Issues list
Данный раздел используется для очень формальных SRS. Описывает пункты TBD(To Be Done) — что в будущем надо еще сделать, но тут не описано.
Заключение
SRS не является обязательным для использования, однако может помочь в средних и больших проектах. Использование SRS показывает Ваш профессиональный уровень как разработчика.
Спецификации и их роль в разработке программ
Технология разработки программных продуктов
Составитель Румбешт В.В., кандидат технических наук, доц.
Рецензент Михилев В.М., кандидат технических наук, доц.
Т38 Технология разработки программных продуктов: Методические указания. – Белгород: Изд-во БИЭИ, 2005. – 42 с.
В методических указаниях изложены современные методы специфицирования программного обеспечения такие, как Р-технология
(ГОСТ 19.005–85) и метод структурного анализа. Содержатся задания к выполнению лабораторных работ, посвященных изучению указанных методов.
Предназначены для студентов специальности 22.03.
Ó Белгородский инженерно-экономический
институт (БИЭИ), 2005
ОГЛАВЛЕНИЕ
Спецификации и их роль в разработке программ
Спецификация программы – это описание задачи, которую решает программа. Слово «спецификация» буквально означает «описание» или «получение описания», а «специфицировать» значит «описывать».
В отличие от компьютерной программы спецификация обращена, прежде всего, к человеку и представляет собой описание в терминах, характерных для самой задачи, а не для ее реализации. Спецификация – это задание для программиста, написанное постановщиком задачи. Она служит основой дальнейшей детализации и разработки. С другой стороны, требования к программе, отраженные в техническом задании, также обращены к человеку. Однако спецификация более формально, чем требования, описывает решаемую задачу.
К основным свойствам спецификации можно отнести следующее.
1. Спецификация не должна содержать деталей реализации. В отличие от программы она «говорит», что надо сделать, а не как это делать.
2. Спецификация должна обладать формальностью (однозначностью прочтения, точностью), причем диапазон требований здесь очень широк: от полностью формализованного описания до слегка формализованного. Описание на «естественном языке» обычно считается неудовлетворительным, поскольку оно слишком неформально.
3. Спецификация должна быть понятной (ясной, читабельной). В этом заключается еще одно отличие от программы. В общем случае спецификация должна быть более понятным описанием задачи, чем программа, так как краткость не всегда содействует ясности и понятности.
4. Спецификация должна обладать полнотой описания задачи: ничто существенное не должно быть упущено.
Итак, спецификация – это достаточно точное и достаточно полное описание задачи, которое человеку, участвующему в решении, легче написать, понять и прочесть, чем программисту представить решение этой задачи на доступном ему языке программирования.
Дополненные и уточненные требования к программе – это уже спецификация, которая на пути к готовому программному продукту может претерпеть много изменений, оставаясь спецификацией до тех пор, пока не сможет быть выполнена на машине или пока это выполнение не станет достаточно эффективным.
В спецификации программы имеет смысл выделить по крайней мере две существенно разные части. Одна описывает объекты, действующие в задаче: разбиение задачи на подзадачи; входные и выходные данные, связи между ними, если речь идет о задаче преобразования данных или вычислении функции, процессы и действия, если речь идет о задаче управления или взаимодействия с внешней средой, реакции на исключительные ситуации и т.д. Эта часть называется функциональной спецификацией. Она описывает функцию программы, решающей задачу. Другая часть спецификации касается таких аспектов, как скорость работы программы или используемые ею ресурсы, характеристики аппаратуры, на которой она должна работать, специальные требования к надежности и безопасности и т.д. Эту часть называют эксплуатационной спецификацией.
Спецификациям уделяется все большее внимание, их разработка рассматривается как самостоятельная область технологии и методологии программирования, а сами они — как существенная часть программной документации.
В последнее время появилось большое количество технологий и методов построения функциональных спецификаций, а также языков спецификаций. Для этих языков характерно следующее.
1. Разбиение на уровни абстракций.
2. Ограниченное число элементов, приходящихся на уровень абстракции (не более 7).
3. Ограниченный контекст – включается лишь то, что входит в процесс, а все остальное из рассмотрения исключается.
4. В описание включаются как сами данные, так и действия над ними.
В данных методических указаниях рассмотрим две наиболее распространенные технологии специфицирования: Р-технологию и метод структурного анализа, языки которых можно отнести к так называемым графическим языкам. Эти средства представляют информацию в виде графов и диаграмм, а также содержат определенную методологию построения функциональных спецификаций.
2. Основные принципы Р-технологии
Р-технология была создана в Институте Кибернетики АН УССР. Для написания спецификаций в Р-технологии используется язык нагруженных по дугам ориентированных графов. Конкретная спецификация, созданная с помощью Р-технологии, представляет собой иерархию таких графов, называемых Р-схемами.
На самом деле Р-технология охватывает не только этап специфицирования программ, но и этапы проектирования, кодирования, отладки, и документирования в жизненном цикле программного обеспечения. Она предусматривает следующую цепочку работ по созданию программы:
* построение Р-схемы или иерархии Р-схем, реализующей поставленную задачу;
* генерацию исходного текста программы по заданной Р-схеме;
* компиляцию и компоновку загрузочного модуля программы;
* отладку и тестирование, полученной программы;
* генерацию Р-схемы по исходному тексту программы;
Язык Р-схем является удобной оболочкой, в которую может быть погружен любой язык программирования от ассемблера до языка высокого уровня, и в настоящее время является составной частью Единой системы программной документации (ГОСТ 19.005–85).
2.1. Графические структуры Р-схем
Р-схема — это управляющая структура программы в виде множества возможных путей ее выполнения, изображенных направленными дугами. Структура Р-схем изображается с помощью простых графических элементов таких, как вершины, соединительные дуги и вертикальные линии.
Состав спецификации
Постановка задачи определяет, что должна делать программа, какие условия налагаются на процесс решения и т.п. Этот пункт спецификации очень важен, т.к. без точной постановки задачи или при её неправильном понимании разработанная программа будет делать не то, что надо, и придётся её переписывать заново. Поэтому заказчик программы должен подробно описать, что именно должна делать программа, какие функции должна выполнять, как реагировать на те или иные ситуации, в частности, некорректные исходные данные.
В таблице данных описываются все переменные, которые будут использоваться в программе.
Имя – это идентификатор, т.е. последовательность из одной и более латинских букв, цифр и символов подчёркивания, которая начинается с буквы или символа подчёркивания. Имена переменных в программе должны быть различны, а также не должны совпадать с ключевыми словами, зарезервированными компилятором. Имена переменных выбираются программистом, но желательно, чтобы имя переменной отражало смысл переменной.
Смысл – это самая важная для программиста графа. Смысл переменной определяет, как она будет использоваться в программе. Например, количество элементов массива должно использоваться для ограничения количества шагов циклов по обработке массивов. Если вы не формируете массив, то нет смысла прибавлять какие-либо числовые значения к этой переменной. Если нужно подсчитать сумму элементов массива, то определяется специальная переменная, которая инициализируется нулём, и затем к ней последовательно прибавляются значения элементов массива. Опять-таки, нет смысла умножать эту переменную на что-то или прибавлять к ней значения, отличные от значений элементов массива.
Таким образом, программист всегда должен точно осознавать, зачем нужна та или иная переменная, и использовать каждую переменную в соответствии с её смыслом.
Тип переменной определяет, какие значения могут в ней храниться, размер переменной, допустимые операции.
Диапазон задаёт минимальное и максимальное возможные значения переменной. Диапазон обычно задаётся для входных данных, впрочем, он не всегда необходим. Например, если мы вводим количество элементов массива и сам массив, то количество элементов массива не должно быть меньше 1 и не должно быть больше максимально допустимого количества элементов. Элементы массива могут принимать любое значение (хотя типы данных накладывают ограничения на допустимые значения).
Формат описывает представление данных, например, может быть задано минимальное и/или максимальное количество символов в представлении числа или строки, количество знаков после запятой для вещественного числа и т.п. Формат обычно задаётся для выходных данных.
3. Входная форма
Описывает, какие данные и где должны быть расположены при вводе данных. При вводе данных с клавиатуры необходимо также выводить для пользователя подсказки, определяющие, что именно надо вводить в данных момент. Во входной форме обычно записываются имена переменных в угловых скобках. Имена переменных подсказывают порядок расположения переменных, а угловые скобки указывают, что при вводе надо набирать не само имя, а значение для данной переменной.
Этот пункт спецификации кажется несущественным, но на самом деле это не так. При вводе из файла данные можно расположить различным образом. При этом нет возможности ввести какие-то пояснения, т.к. программа не будет распознавать текст типа «количество строк матрицы» или «количество столбцов матрицы». Если располагать данные в произвольном порядке и писать подобные пояснения (даже в фиксированной форме), это приведёт к увеличению размера файла с данными и, главное, к увеличению времени обработки этого файла. А объёмы данных могут быть значительными. Наверняка, все любят играть в компьютерные игры. Представьте, какой объём данных должен сохраняться в какой-нибудь RPG – положение героя, состояние игры, имеющиеся у героя предметы, его отношения с соратниками и т.д.
4. Выходная форма
5. Аномалии
Аномалии – это исходные данные, при которых невозможна правильная работа программы. Например, невозможно вычислить логарифм неположительного числа. В спецификации описываются возможные аномальные ситуации и реакция программы на них. Программа, соответственно, должна проверять введённые данные и правильно реагировать на аномальные ситуации – это определяет надёжность программы.
6. Тестовые примеры
Тестовые примеры – это наборы исходных данных, с помощью которых определяется правильность работы программы. Тестовые примеры очень важны для разработки программы. Чем больше тестовых примеров вы используете, тем больше вероятность, что ваша программа написана корректно.
7. Метод
Метод – это описание способа решения задачи на естественном языке, при этом также могут задаваться формулы и общие закономерности, связывающие входные и выходные данные. Метод не является столь формальным описанием способа решения задачи, как алгоритм, однако он не менее важен в процессе разработки программы. Понимание способа решения задачи и умение описать этот способ на естественном языке – важный шаг в этом процессе. Как доказано практикой, программисты, не умеющие объясняться на естественном языке вообще и описывать на нём процесс решения задачи в частности, обычно пишут плохие, неоптимальные программы.
Рассмотрим пример – найти сумму положительных элементов массива. Метод будет следующим – перебираем все элементы массива, и, если очередной элемент массива положителен, прибавляем его в общую сумму (переменную, которую предварительно необходимо обнулить). В данном случае очевидно, что перебор осуществляется с помощью цикла, а предложение «если …» соответствует управляющей структуре «условный блок». Таким образом, подробное словесное описание метода решения задачи приводит нас к алгоритму и программной реализации.
8. Алгоритм
Алгоритм – строго определённая последовательность действий, выполнение которых приводит к решению некоторого класса задач за конечное число шагов.
К сожалению, не существует алгоритма написания алгоритма. Алгоритмизация является задачей творческой и наиболее сложной частью процесса разработки программы. Однако существует ряд шаблонов и приёмов, которые мы, в частности, будем рассматривать в данном курсе. На сайте приведены описания рассматриваемых в курсе алгоритмов.
9. Программа
Программа – это запись алгоритма на некотором языке программирования. Обычно в консольном приложении выделяются три глобальные части: ввод исходных данных, обработка, вывод полученных результатов.
Спецификация программного обеспечения
Включает ряд пользовательских сценариев (англ. use cases ), которые описывают все варианты взаимодействия между пользователями и программным обеспечением.
Пользовательские сценарии являются средством представления функциональных требований. В дополнение к пользовательским сценариям, спецификация также содержит нефункциональные требования, которые налагают ограничения на дизайн или реализацию (такие как требования производительности, стандарты качества, или проектные ограничения).
В стандарте IEEE 830 содержится рекомендации к структуре и методам описания программных требований — «Recommended Practice for Software Requirements Specifications».
Содержание
Рекомендуемая стандартом IEEE 830 [1] структура SRS
См. также
Примечания
Ссылки
Кент Бек • Гради Буч • Фред Брукс • Barry Boehm • Уорд Каннингем • Оле-Йохан Даль • Том Демарко • Эдсгер Вибе Дейкстра • Дональд Кнут • Мартин Фаулер • Чарльз Энтони Ричард Хоар • Watts Humphrey • Майкл Джексон • Ивар Якобсон • Craig Larman • James Martin • Мейер Бертран • Дэвид Парнас • Winston W. Royce • James Rumbaugh • Никлаус Вирт • Эдвард Йордан • Стив Макконнелл
Моделирование данных • Архитектура ПО • Функциональная спецификация • Язык моделирования • Парадигма • Методология • Процесс разработки • Качество • Обеспечение качества • Структурный анализ)
CMM • CMMI • Данных • Function model • IDEF • Информационная • Metamodeling • Object model • View model • UML
Полезное
Смотреть что такое «Спецификация программного обеспечения» в других словарях:
Разработка программного обеспечения — Когда Грейс Хоппер работала с компьютером Гарвард Марк II в Гарвардском университете, её коллеги обнаружили эту моль, застрявшую в реле и таким образом помешавшую работе устройства, после чего она отметила, что они «отлаживали»(debug) систему.… … Википедия
Инженерия программного обеспечения — Новый Airbus A 380 использует довольно много ПО, чтобы создать современную кабину в самолете. Метод инженерии программного обеспечения позволил создать программное обеспечение самолёта, описываемое миллионами строк … Википедия
Архитектура программного обеспечения — (англ. software architecture) это структура программы или вычислительной системы, которая включает программные компоненты, видимые снаружи свойства этих компонентов, а также отношения между ними. Этот термин также относится к… … Википедия
Тестирование программного обеспечения — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен … Википедия
Сопровождение программного обеспечения — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен … Википедия
Качество программного обеспечения — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен … Википедия
Проектирование программного обеспечения — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • … Википедия
Внедрение программного обеспечения — Эта статья слишком короткая. Пожалуйста … Википедия
Качество программного обеспечения — способность программного продукта подтвердить свою спецификацию при условии, что спецификация ориентирована на характеристики, которые желает получить пользователь. См. также: Качество программного обеспечения Программное обеспечение Финансовый… … Финансовый словарь
Цикл разработки программного обеспечения — Эта статья предлагается к удалению. Пояснение причин и соответствующее обсуждение вы можете найти на странице Википедия:К удалению/30 июля 2012. Пока процесс обсуждения … Википедия
Что такое спецификация программы
Единая система программной документации
Требования к содержанию и оформлению
Unified system for program documentation. Specification. Requirements to contents and form of presentation
Дата введения 1980-01-01
Постановлением Государственного комитета СССР по стандартам от 18 декабря 1978 г. N 3351 дата введения установлена 01.01.80
ИЗДАНИЕ (январь 2010 г.) с Изменением N 1, утвержденным в сентябре 1981 г. (ИУС 11-81).
1. Настоящий стандарт устанавливает форму и порядок составления программного документа «Спецификация», определенного ГОСТ 19.101-77.
Стандарт полностью соответствует СТ СЭВ 2090-80*.
(Измененная редакция, Изм. N 1).
2. Структура и оформление документа устанавливаются в соответствии с ГОСТ 19.105-78.
Информационную часть (аннотацию и содержание) допускается в документ не включать.
3. Спецификация является основным программным документом для компонентов, применяемых самостоятельно, и для комплексов.
Для компонентов, не имеющих спецификации, основным программным документом является «Текст программы».
Форма спецификации приведена в приложении.
4. Спецификация в общем случае должна содержать разделы:
Наименование каждого раздела указывают в виде заголовка в графе «Наименование». Для документов, выполненных печатным способом, заголовок подчеркивают.
5. В раздел «Документация» вносят программные документы на данную программу, кроме спецификации и технического задания, в порядке возрастания кода вида документа, входящего в обозначение.
Далее записывают заимствованные программные документы. Запись их производится в порядке возрастания кодов организаций (предприятий)-разработчиков и далее в порядке возрастания кода вида документа, входящего в обозначение.
3-5. (Измененная редакция, Изм. N 1).
6. После каждого раздела спецификации необходимо оставлять несколько свободных строк для дополнительных записей.
7. Графы спецификаций заполняют следующим образом: в графе «Обозначение» указывают:
в графе «Наименование» указывают:
При отсутствии места в графе «Примечание» допускается записывать только порядковые номера примечаний. Текст примечаний записывают в конце соответствующих разделов спецификации. Допускается текст примечаний записывать на последних листах спецификации на листах без граф с проставлением порядкового номера примечания.
(Измененная редакция, Изм. N 1).
8. В графе «Обозначение» запись производят в одну строку. В остальных графах спецификации записи допускаются в несколько строк.
(Введен дополнительно, Изм. N 1).
ПРИЛОЖЕНИЕ
Обязательное
Примечание. Размеры таблицы допускается выполнять кратными шагу печатающих устройств.
Электронный текст документа
подготовлен АО «Кодекс» и сверен по:
Единая система программной документации: