Для чего нужна спецификация программы

Спецификация программного обеспечения

Включает ряд пользовательских сценариев (англ. 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. Пока процесс обсуждения … Википедия

Источник

Спецификации и их роль в разработке программ

Технология разработки программных продуктов

Составитель Румбешт В.В., кандидат технических наук, доц.

Рецензент Михилев В.М., кандидат технических наук, доц.

Т38 Технология разработки программных продуктов: Методические указания. – Белгород: Изд-во БИЭИ, 2005. – 42 с.

В методических указаниях изложены современные методы специфицирования программного обеспечения такие, как Р-технология
(ГОСТ 19.005–85) и метод структурного анализа. Содержатся задания к выполнению лабораторных работ, посвященных изучению указанных методов.

Предназначены для студентов специальности 22.03.

Ó Белгородский инженерно-экономический
институт (БИЭИ), 2005

ОГЛАВЛЕНИЕ

Спецификации и их роль в разработке программ

Спецификация программы – это описание задачи, которую решает программа. Слово «спецификация» буквально означает «описание» или «получение описания», а «специфицировать» значит «описывать».

В отличие от компьютерной программы спецификация обращена, прежде всего, к человеку и представляет собой описание в терминах, характерных для самой задачи, а не для ее реализации. Спецификация – это задание для программиста, написанное постановщиком задачи. Она служит основой дальнейшей детализации и разработки. С другой стороны, требования к программе, отраженные в техническом задании, также обращены к человеку. Однако спецификация более формально, чем требования, описывает решаемую задачу.

К основным свойствам спецификации можно отнести следующее.

1. Спецификация не должна содержать деталей реализации. В отличие от программы она «говорит», что надо сделать, а не как это делать.

2. Спецификация должна обладать формальностью (однозначностью прочтения, точностью), причем диапазон требований здесь очень широк: от полностью формализованного описания до слегка формализованного. Описание на «естественном языке» обычно считается неудовлетворительным, поскольку оно слишком неформально.

3. Спецификация должна быть понятной (ясной, читабельной). В этом заключается еще одно отличие от программы. В общем случае спецификация должна быть более понятным описанием задачи, чем программа, так как краткость не всегда содействует ясности и понятности.

4. Спецификация должна обладать полнотой описания задачи: ничто существенное не должно быть упущено.

Итак, спецификация – это достаточно точное и достаточно полное описание задачи, которое человеку, участвующему в решении, легче написать, понять и прочесть, чем программисту представить решение этой задачи на доступном ему языке программирования.

Дополненные и уточненные требования к программе – это уже спецификация, которая на пути к готовому программному продукту может претерпеть много изменений, оставаясь спецификацией до тех пор, пока не сможет быть выполнена на машине или пока это выполнение не станет достаточно эффективным.

В спецификации программы имеет смысл выделить по крайней мере две существенно разные части. Одна описывает объекты, действующие в задаче: разбиение задачи на подзадачи; входные и выходные данные, связи между ними, если речь идет о задаче преобразования данных или вычислении функции, процессы и действия, если речь идет о задаче управления или взаимодействия с внешней средой, реакции на исключительные ситуации и т.д. Эта часть называется функциональной спецификацией. Она описывает функцию программы, решающей задачу. Другая часть спецификации касается таких аспектов, как скорость работы программы или используемые ею ресурсы, характеристики аппаратуры, на которой она должна работать, специальные требования к надежности и безопасности и т.д. Эту часть называют эксплуатационной спецификацией.

Спецификациям уделяется все большее внимание, их разработка рассматривается как самостоятельная область технологии и методологии программирования, а сами они — как существенная часть программной документации.

В последнее время появилось большое количество технологий и методов построения функциональных спецификаций, а также языков спецификаций. Для этих языков характерно следующее.

1. Разбиение на уровни абстракций.

2. Ограниченное число элементов, приходящихся на уровень абстракции (не более 7).

3. Ограниченный контекст – включается лишь то, что входит в процесс, а все остальное из рассмотрения исключается.

4. В описание включаются как сами данные, так и действия над ними.

В данных методических указаниях рассмотрим две наиболее распространенные технологии специфицирования: Р-технологию и метод структурного анализа, языки которых можно отнести к так называемым графическим языкам. Эти средства представляют информацию в виде графов и диаграмм, а также содержат определенную методологию построения функциональных спецификаций.

2. Основные принципы Р-технологии

Р-технология была создана в Институте Кибернетики АН УССР. Для написания спецификаций в Р-технологии используется язык нагруженных по дугам ориентированных графов. Конкретная спецификация, созданная с помощью Р-технологии, представляет собой иерархию таких графов, называемых Р-схемами.

На самом деле Р-технология охватывает не только этап специфицирования программ, но и этапы проектирования, кодирования, отладки, и документирования в жизненном цикле программного обеспечения. Она предусматривает следующую цепочку работ по созданию программы:

* построение Р-схемы или иерархии Р-схем, реализующей поставленную задачу;

* генерацию исходного текста программы по заданной Р-схеме;

* компиляцию и компоновку загрузочного модуля программы;

* отладку и тестирование, полученной программы;

* генерацию Р-схемы по исходному тексту программы;

Язык Р-схем является удобной оболочкой, в которую может быть погружен любой язык программирования от ассемблера до языка высокого уровня, и в настоящее время является составной частью Единой системы программной документации (ГОСТ 19.005–85).

2.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 показывает Ваш профессиональный уровень как разработчика.

Источник

Разница между Требованиями и Спецификацией в разработке программного обеспечения

Основное различие между Требованиями и Спецификацией в разработке программного обеспечения заключается в том, что Требования — это потребности заказчика, которые должны учитываться в разрабатываемом программном обеспечении, тогда как Спецификация является техническим документом с проанализированными требованиями. Спецификация описывает функции и поведение программного обеспечения.

Содержание

Что такое Требования в разработке программного обеспечения?

Весь проект зависит от требований. Первым шагом к разработке программного обеспечения является подготовка технико-экономического обоснования. Основное внимание уделяется техническим аспектам продукта. Следующим процессом является сбор требований. Это возможно благодаря общению с клиентами, конечными пользователями и пользователями системы, которые будут использовать продукт в итоге. Интервью, опросы и вопросники являются основными методами сбора требований. П осле сбора требований производится окончательный анализ.

Функциональные и нефункциональные требования являются двумя типами этих требований. Требования, которые определяют функциональный аспект программного обеспечения, является функциональными требованиями. Следовательно, они определяют функцию системы или подсистемы.

Например, система управления библиотекой должна иметь возможность добавления, редактирования, удаления и поиска информации о книге. Также, она должна иметь возможность редактирования и удаления информации читателя книги. Кроме того, она должна уметь рассчитывать штраф за поздний возврат. Это пример некоторых функциональных требований системы на примере библиотеки.

Нефункциональные требования определяют ожидаемые характеристики программного обеспечения. Безопасность, ремонтопригодность, удобство использования, надежность и доступность являются примерами нефункциональных требований.

Другой тип требований — это бизнес-требования. Они определяют бизнес-цели, видение и задачи.

Что такое Спецификация в разработке программного обеспечения?

Эта спецификация работает как соглашение между заказчиком и командой разработчиков о том, что должен делать программный продукт. Правильная спецификация помогает предотвратить сбои программного обеспечения. Это также помогает команде разработчиков получить четкое представление о продукте, который они должны разработать.

Сходства между Требованиями и Спецификацией в разработке программного обеспечения?

В чем разница между Требованиями и Спецификацией в разработке программного обеспечения?

Заключение — Требования против Спецификации в разработке программного обеспечения

Разница между Требованием и Спецификацией в в разработке программного обеспечения (Software Engineering) заключается в том, что Требования — это потребности заказчика, которые должны быть решены программным обеспечением, тогда как Спецификация — это технический документ с проанализированными требованиями.

Источник

Как написать ТЗ, часть 1: ГОСТЫ и спецификации требований

Разработка требований к программному продукту и их оформление в виде технического задания или спецификации – одна из самых частых задач, которую решает бизнес-аналитик. Сегодня рассмотрим, какие стандарты регламентируют структуру и содержание этих документов, разберем разницу между автоматизированной системой и программным изделием, уточним, что такое информационная система и почему зарубежный шаблон SRS популярнее отечественных ГОСТ’ов.

Близнецы или тройняшки: ПО, информационная и автоматизированная системы – отличия и разные ГОСТ’ы

Структура и содержание технического задания (ТЗ) определяется специальным шаблоном – государственным или международным стандартом в зависимости от объекта разработки. Чаще всего таким объектом является:

Таким образом, программа или программное изделие – это часть АС. А термин «информационная система» трактуется согласно следующим определениям:

Поэтому информационная система (ИС), которая помимо программного обеспечения, также включает техническую часть, например, носимые устройства так называемого интернета вещей (IoT) – «умные часы», компоненты комплекса «умный дом» и пр. – является АС. В России ТЗ на создание АС регламентирует ГОСТ 34.602-89, впервые введенный в 1990 году и переизданный в 2009 г. А порядок построения и оформления ТЗ на разработку программы или программного изделия, которые не включает технического и других видов обеспечения, описывает ГОСТ 19.201-78, введенный в 1980 году и переизданный в 2010.

Рассмотрим, чем отличаются эти стандарты. ГОСТ 34.602-89 выделяет следующие разделы в ТЗ на создание АС:

По ГОСТ 19.201-78 в ТЗ на разработку программы должны быть следующие разделы:

Оба стандарта допускают оформлять отдельные разделы ТЗ в виде приложений, вводить дополнительные, исключать или объединять подразделы в зависимости от особенностей и условий эксплуатации объекта разработки.

Однако, сегодня большинство разработчиков и аналитиков считают эти отечественные ГОСТ’ы морально устаревшими и все чаще вместо них для оформления требований к ИС используют шаблоны зарубежных стандартов: ISO IEEE 29148-2011 и IEEE 830-1998, которые регламентируют составление спецификаций требований к ПО. Преимущества этих шаблонов над российскими регламентами и практику их совместного использования рассмотрим далее.

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса

Ближайшая дата курса

Длительность обучения

12 ак.часов

Стоимость обучения

20 000 руб.

Стандарты ISO IEEE 29148-2011 и IEEE 830-1998: в чем разница и как их использовать для разработки ТЗ

SRS по IEEE 830-1998

IEEE 830-1998 – это рекомендуемая методика составления спецификаций требований к ПО (Software Requirements Specification). Она описывает критерии проверки качественно составленной SRS, ее части и шаблоны. Основными рекомендуемыми разделами SRS по IEEE 830-1998 являются следующие:

ТЗ по ГОСТ vs SRS по ISO IEEE 29148-2011

IEEE 830-1998 носит рекомендательный характер – не случайно в оригинале он называется Recommended Practice for Software Requirements Specifications и сегодня не так часто используется на практике, как международный стандарт по инженерии требований ISO IEEE 29148-2011, который обеспечивает единую трактовку процессов и продуктов для всей системы и ПО. По сути, этот стандарт заменяет IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998 и объединяет российские ГОСТ’ы 34.602-89 и ГОСТ 19.201-78. Он содержит два шаблона спецификации требований:

В отличие от BABOK@Guide, стандарт 29148-2011 делит требования к ПО на:

ISO IEEE 29148-2011 описывает не только структуру и содержание SRS, но и регламентирует все процессы работы с требованиями, от их определения, включая выявление у стейкхолдеров, моделирование, анализ, верификацию и валидацию, до процедур управления (изменение, оценка влияния и пр.). Если рассматривать ISO IEEE 29148-2011 как шаблон ТЗ на разработку ПО/ИС, то он выделяет следующие разделы:

Можно сказать, что все эти разделы дополняют и уточняют пункты, предусмотренные отечественными ГОСТ’ами. С практической точки зрения структура SRS по ISO IEEE 29148-2011 дает следующие преимущества по сравнению с ГОСТ 34.602-89 и ГОСТ 19.201-78:

Недостатком SRS по ISO IEEE 29148-2011 можно назвать большой объем этого документа, что отражается в длительности и трудоемкости его разработки. Впрочем, несмотря на это и вышеотмеченные достоинства, хочется подчеркнуть, по сути SRS по ISO IEEE 29148-2011 не лучше и не хуже отечественных ГОСТ’ов. В любом случае, не зависимо от выбранного шаблона ТЗ на создание ИС, АС или ПО, этот документ должен отражать функциональные и нефункциональные требования к объекту разработки так, чтобы их можно было реализовать и проверить, что решение соответствует целям бизнеса и приносит стейкхолдерам пользу. Про ограничения, допущения и зависимости читайте здесь. В следующей статье мы продолжим разговор про разработку ТЗ, а пока предлагаем вам пройти открытый интерактивный тест на проверку знаний о стандартах и требованиях из этого материала.

Источник