Спецификация программного обеспечения
Включает ряд пользовательских сценариев (англ. 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. Пока процесс обсуждения … Википедия
Что такое спецификация программного обеспечения
Аналитик
Template tips
Включает ряд пользовательских сценариев (англ. use cases ), которые описывают все варианты взаимодействия между пользователями и программным обеспечением.
Пользовательские сценарии являются средством представления функциональных требований. В дополнение к пользовательским сценариям, спецификация также содержит нефункциональные требования, которые налагают ограничения на дизайн или реализацию (такие как требования производительности, стандарты качества, или проектные ограничения).
В стандарте IEEE 830 содержится рекомендации к структуре и методам описания программных требований — «Recommended Practice for Software Requirements Specifications».
Введение\ Цели
В данной секции описываем приложение или продукт, функционал которого будет описываться в SRS.
Введение\ Соглашение о терминах
Здесь мы описываем все непонятные технические слова или термины которые встречаются в SRS. Заметьте, что описание непонятного слова не может содержать другое непонятное слово. Старайтесь расписать как можно подробнее термин который Вы используете простым и понятным всем языком. Не экономьте на этой секции потому, что чем больше вы распишете непонятных вещей, тем проще будет потом проектировать.
Введение \ Ссылки на источники
В данной секции мы пишем ссылки на литературу в которой можно найти основания использованных технологий и фактов. Допустим можно вставлять RFC если вы пишете приложение работающее с TCP/IP, вставлять ссылки на документы на которые вы ссылаетесь и тд. Ссылки и их описание должны быть максимально полными, чтобы в случае чего (линк умер просто) можно было нагуглить этот материал.
Общее описание\ Функциональность продукта
В данном разделе мы описываем части функционала на высоком уровне. Более детально каждая часть функционала будет описана в своем разделе ниже. Тут желательно разместить DFD-диаграмму которая покажет общее взаимодействие системы.
Общее описание\ Среда функционирования продукта
Как понятно из названия раздела тут мы описываем окружение в котором будет работать продукт. ОС, версии компиляторов, базы данных, сервера, софт, железо и другие вещи которые необходимы для работы вашего продукта.
Общее описание\ Документация для пользователей
Описываем какая документация нужна для пользователей данного продукта. Возможно это книга по HTML если это HTML редактор.
Функциональность системы \ Функциональный блок X
Называем фичу проекту и даем ей уникальный идентификатор. Например, server.html.editor. Уникальный идентификатор дается для того, чтобы потом где то в тикетах ваших не писать — «а вот та хреновина, которая позволяет редактировать хтмл»
Функциональность системы \ Функциональный блок X\ Описание и приоритет
Описываем детально фичу продукта. Для чего она? Что должна делать? Какой у нее приоритет выполнения. Из этого раздела читающему срс человеку должно сразу стать понятно зачем этот функционал присутствует в системе.
Функциональность системы \ Функциональный блок X \ Прицинно-следственные связи, алгоритмы
Триггер запуска фичи. Когда она запускается и как себя ведет при запуске? Например, HTML редактор показывается при нажатии пользователя на ссылку меню Открыть HTML редактор
Функциональность системы \ Функциональный блок X \ Функциональные требования
Подробное и детальное описание фичи. Описываем все: как работает, как реагирует на ошибки, что должно проверять, как отображать данные, как и куда что сохраняет и тд
Требования к внешним интерфейсам
Описание того как система будет взаимодействовать с внешним миров. Если будет конечно. Какие API, как получить те или иные данные и тп. Подразделы служат для детализации требований. Какие софт интерфейсы, «железячные» интерфейсы, комуникационные интерфейсы и прочее.
Не функциональные требования
Не функциональные требования. Есть требования которые невозможно описать как какую то фичу, например, требования к безопасности.
Не функциональные требования \ Требования к производительности
Требования к производительности. Это не фича, однако налагает определенные ограничения. Допустим база данных проекта должна выдерживать 1000 запросов в секунду и тп. Эти требования приводят к колоссальной работе по оптимизации проекта.
Не функциональные требования \ Критерии качества программного обеспечения
Тут мы описываем требования к качеству кода. Какие тесты использовать? Какие метрики использовать для определения качества кода? Сколько кода должно быть покрыто тестами?
Не функциональные требования \ Требования к безопасности системы
Требования по безопасности. Если это HTML редактор, через которые можно изменять что-то на сайте, то это может быть нечто вроде: через HTML редактор не должно быть возможности поставить shell на сервер и тп
Приложение A: Глоссарий
Приложение. Иногда в SRS пытаются вставлять описание протоколов и тд и тп. Этого делать не нужно. Однако иногда нужно таки прояснить какую то концепцию. Для этого существует этот раздел. Вставляем ссылочки на такие пояснения. Такой себе словарик.
Приложение B: Модели процессов предметной области и другие диаграммы
Раздел определяет какие диаграммы нужно использовать при написании SRS. Например, DFD, какие то общие диаграммы взаимодействия и работы
Приложение C: Список ключевых задач
Данный раздел используется для очень формальных SRS. Описывает пункты TBD(To Be Done) — что в будущем надо еще сделать, но тут не описано.
Разница между Требованиями и Спецификацией в разработке программного обеспечения
Основное различие между Требованиями и Спецификацией в разработке программного обеспечения заключается в том, что Требования — это потребности заказчика, которые должны учитываться в разрабатываемом программном обеспечении, тогда как Спецификация является техническим документом с проанализированными требованиями. Спецификация описывает функции и поведение программного обеспечения.
Содержание
Что такое Требования в разработке программного обеспечения?
Весь проект зависит от требований. Первым шагом к разработке программного обеспечения является подготовка технико-экономического обоснования. Основное внимание уделяется техническим аспектам продукта. Следующим процессом является сбор требований. Это возможно благодаря общению с клиентами, конечными пользователями и пользователями системы, которые будут использовать продукт в итоге. Интервью, опросы и вопросники являются основными методами сбора требований. П осле сбора требований производится окончательный анализ.
Функциональные и нефункциональные требования являются двумя типами этих требований. Требования, которые определяют функциональный аспект программного обеспечения, является функциональными требованиями. Следовательно, они определяют функцию системы или подсистемы.
Например, система управления библиотекой должна иметь возможность добавления, редактирования, удаления и поиска информации о книге. Также, она должна иметь возможность редактирования и удаления информации читателя книги. Кроме того, она должна уметь рассчитывать штраф за поздний возврат. Это пример некоторых функциональных требований системы на примере библиотеки.
Нефункциональные требования определяют ожидаемые характеристики программного обеспечения. Безопасность, ремонтопригодность, удобство использования, надежность и доступность являются примерами нефункциональных требований.
Другой тип требований — это бизнес-требования. Они определяют бизнес-цели, видение и задачи.
Что такое Спецификация в разработке программного обеспечения?
Эта спецификация работает как соглашение между заказчиком и командой разработчиков о том, что должен делать программный продукт. Правильная спецификация помогает предотвратить сбои программного обеспечения. Это также помогает команде разработчиков получить четкое представление о продукте, который они должны разработать.
Сходства между Требованиями и Спецификацией в разработке программного обеспечения?
В чем разница между Требованиями и Спецификацией в разработке программного обеспечения?
| Требования против Спецификации в разработке программного обеспечения | |
| Требования представляют собой описания услуг, которые должна предоставлять программная система, и ограничения, при которых она должна работать | Спецификация — это технический документ, который описывает функции и поведение программного приложения |
| Использование | |
| Требования помогают описать, что должно делать программное обеспечение | Спецификация помогает получить четкое представление о продукте для его разработки и минимизировать сбои программного обеспечения |
Заключение — Требования против Спецификации в разработке программного обеспечения
Разница между Требованием и Спецификацией в в разработке программного обеспечения (Software Engineering) заключается в том, что Требования — это потребности заказчика, которые должны быть решены программным обеспечением, тогда как Спецификация — это технический документ с проанализированными требованиями.
Что такое спецификация программного обеспечения
Единая система программной документации
Требования к содержанию и оформлению
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).
ПРИЛОЖЕНИЕ
Обязательное
Примечание. Размеры таблицы допускается выполнять кратными шагу печатающих устройств.
Электронный текст документа
подготовлен АО «Кодекс» и сверен по:
Единая система программной документации:
Правила составления 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 показывает Ваш профессиональный уровень как разработчика.