Спецификация программы что это

Как составить ТЗ или спецификацию на программный продукт

В этой статье мы рассмотрим важность спецификации при разработке программного обеспечения и особенности ее составления для eCommerce-проектов.

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

Давайте начнем с небольшого объяснения того, что такое спецификация с точки зрения разработки программного обеспечения.

Зачем нужна Спецификация

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

Чем Спецификация отличается от Технического задания (ТЗ)

Мы не составляем технического задания, поскольку этот документ предполагает подготовку по стандартам (таких как ГОСТ 34, IEEE 29148-2011, Rational Unified Process и другие), усложняющих и удоражающих процесс производства конечной услуги.

Что такое спецификации в Sanergy и как с ними работать

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

CTO Simtech Development

Чем Спецификация отличается от брифа

Спецификация (как и ТЗ) — это детальное описание требований к работе, тогда как бриф — это опросник. Мы отправляем брифы клиентам, чтобы выяснить общие требования и пожелания. Такие опросники помогают понять, что хочет клиент. Пример брифа на дизайн может включать такие вопросы как:

1. Есть ли фирменный логотип, брендбук?
2. Укажите сайты, которые вам нравится и элементы дизайна, на которые нам следует обратить внимание.
3. Что недопустимо на сайте?
4. Опишите требования к дизайну:

• На базе готового решения (шаблон/тема)
• Персонализация готового шаблона/темы (изменения цветовой гаммы/иконок/шрифтов под ваш стиль)
• Индивидуальный дизайн (разработка уникального дизайна)

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

Кто и когда составляет спецификацию

В действительности, нет правильного ответа на этот вопрос. Как заказчик, так и исполнитель могут составлять спецификацию. Часто, — это совместная работа.Все зависит от конкретной ситуации и условий.

Составляет Заказчик

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

Спецификация

Чтобы избежать ошибок, воспользуйтесь услугой “Проектирование архитектуры интернет-магазина”.
Наши специалисты сами соберут требования. Вы получите точное описание всех разделов магазина и карту реализации проекта с указанием этапов и сроков выполнения работ.

Составляет Исполнитель

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

Поэтому так важно выбрать добросовестного подрядчика с самого начала. Все же, при этом подходе от заказчика также требуется активное участие, потом что только он знает особенности своего бизнеса, которые нужно будет учесть в работе.

Совместное составление

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

Что указывается в спецификации

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

Как мы составляем спецификацию в Simtech Development

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

В основной части описываются технические детали: что будет сделано, и какие у проекта есть ограничения.

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

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

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

В заключении указываются сроки и стоимость работ.

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

Когда спецификация не нужна

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

• Что нужно от продукта
• Как и кто его будет использовать
• Что должно быть включено в продукт, а что, наоборот, точно стоит исключить.

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

Вот слова руководителя группы программистов Александра по поводу сложностей работы над новым проектом:

Для того, чтобы начать делать “кастому” — нужно четко понять, что мы хотим получить на выходе. Могут возникнуть разные ситуации, в зависимости от того, с чем пришел клиент: абстрактной бизнес-идеей, или четкой спецификацией. Когда у сторон нет четкого понимания, как будет выглядеть итоговый проект, требуется проектирование — мы анализируем бизнес-требования, после чего проектируем разделы сайта и подробно описываем функционал. Понимание бизнес-идеи клиента для нас критично, от этого зависит итоговый продукт и процесс его разработки

руководитель группы программистов Simtech Development

В нашей компании, гибкий подход к разработке реализуется выделенной командой разработчиков через услугу Проектирование. Команда работает по спринтам и отчитывается перед заказчиком в оговоренное время.

Источник: simtechdev.ru

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

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

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

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

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

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

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

ОГЛАВЛЕНИЕ

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

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

2.1. Графические структуры Р-схем .

2.2. Операции соединения графических структур .

2.3. Дополнительные графические элементы Р-схем .

2.4. Использование Р-схем в программах .

2.5. Система инструментальной поддержки Р-технологии .

3. Метод структурного анализа .

3.1 Диаграммы потоков данных .

3.2. Словарь данных .

3.3. Способы задания спецификаций процессов .

3.4. Диаграммы сущность–связь .

3.5. Диаграммы переходов–состояний .

3.6. Структурные карты .

3.7. Система инструментальной поддержки структурного анализа .

ЛАБОРАТОРНАЯ РАБОТА № 1. Изучение основных принципов Р-технологии .

ЛАБОРАТОРНАЯ РАБОТА № 2. Изучение основных управляющих конструкций Р-схем .

ЛАБОРАТОРНАЯ РАБОТА №3. Ознакомление с CASE-средством EasyCASE .

ЛАБОРАТОРНАЯ РАБОТА №4. Разработка диаграмм потоков данных .

ЛАБОРАТОРНАЯ РАБОТА №5. Разработка диаграмм сущность–связь .

ЛАБОРАТОРНАЯ РАБОТА №6. Разработка диаграмм переходов–состояний .

Лабораторная работа №7. Разработка структурных карт .

Список Литературы . …..

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1. Графические структуры Р-схем

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

Р-технология предполагает, что спецификации создаются по безбумажной схеме и весь процесс разработки выполняется с помощью средств вычислительной техники. При этом элементы Р-схем вводятся в ЭВМ и выводятся из нее с помощью алфавитно-цифровых (не графических) устройств ввода/вывода, а для изображения этих элементов применяются стандартные алфавитно-цифровые символы: “o”, “-” , “=“, “>“, “

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

Примеры фрагментов Р-схем, иллюстрирующие различные варианты текстовой нагрузки дуги, приведены на рис. 1. Как видно из этих примеров, и условие и действие на дуге могут отсутствовать.

Рис. 1. Варианты текстовой нагрузки дуги в Р-схеме

Для изображения переходов между состояниями (вершинами) в
Р-схемах разрешается использовать только горизонтальные линии со стрелками (дуги). Вертикальные линии стрелок не содержат и используются только для соединения дуг, выходящих из одной вершины или входящих в одну вершину.

Дуга, изображенная двумя горизонтальными линиями, соответствует отождествлению соединяемых ею вершин. Такая дуга в Р-схемах называется технологической. Петли в Р-схемах изображаются, как показано на рис. 2.

Рис. 2. Изображение петель на Р–схемах

Построение Р-схемы основывается на комбинации двух структур, называемых базовой и специальной. Структуры Р-схем представлены на
рис. 3.

Рис. 3. Типовые структуры Р-схем:
а – базовая структура; б – специальная структура

На рис. 3 символами: Y1, Y2, … , YN, YN1, YN2, …, YNM обозначены условия прохождения по дуге; символами: D1, D2 ,…, DN, DN1,
DN2, …, DNM – действия, выполняемые, если соответствующие условия истинны; символом Y – условие повторения вида “i = 1 step 1 until K”, “i = 1 … K” и т.п. Условия Y, Y1, Y2 ,…, YNM или действия D1, D2, …, DNM могут отсутствовать на дугах, обозначая тем самым безусловный переход, или переход без выполнения действия.

Базовая структура выполняется по следующему принципу. Если процесс находится в состоянии, соответствующем левой вершине, то анализируют прямые дуги (слева направо).

Первая дуга, у которой условие перехода оказывается истинным, выполняется, т.е. выполняют указанные под ней действия, после чего осуществляется переход по дуге Р-схемы в следующее состояние вычислительного процесса (правая вершина). Дуга с отсутствующим условием просматривается последней независимо от ее места положения. После перехода в правую вершину аналогично просматриваются обратные дуги. Если какое-либо условие перехода по обратной дуге истинно, то выполняются соответствующие действия и осуществляется переход в левую вершину.

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

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

Источник: studopedia.ru

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

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

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

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

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

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

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

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

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

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

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

Прежде всего, клиенты и конечные пользователи описывают свои требования на естественном языке. Документирование этих требований происходит после анализа. Этот документ называется Спецификацией требований к программному обеспечению ( Software Requirements Specification , SRS). Затем системные аналитики переводят их на технический язык для команды разработчиков программного обеспечения.

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

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

• Спецификация — это документ с проанализированными требованиями.

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

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

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

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

Источник: raznisa.ru

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

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

• программа (программное изделие). Российский ГОСТ 19781-90 «Обеспечение систем обработки информации программное» описывает это как данные, предназначенные для управления кон­кретными компонентами системы обработки ин­формации в целях реализации определенного ал­горитма.
• автоматизированная система (АС), которая согласно ГОСТ 34.003-90, состоит из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций. АС включает различные виды обеспечения: организационное, методическое, техническое, программное (ПО), информационное, лингвистическое, математическое, правовое, эргономическое.

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

• совокупность информации, содержащейся в базах данных, информационных технологий и технических средств, которые обеспечивают её обработку [ФЗ РФ от 27.06.2006 г. № 149-ФЗ «Об информации, информационных технологиях и о защите информации», ГОСТ Р 50922-2006];
• автоматизированная система, результатом функционирования которой является представление выходной информации для последующего использования [ГОСТ РВ 51987].

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

С 1 января 2022 года ГОСТ 34.602-89 признан недействующим и заменен на ГОСТ 34.602-2020, что мы рассматриваем в новой статье.

А порядок построения и оформления ТЗ на разработку программы или программного изделия, которые не включает технического и других видов обеспечения, описывает ГОСТ 19.201-78, введенный в 1980 году и переизданный в 2010.

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

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

1. Введение
2. Основания для разработки
3. Назначение разработки
4. Требования к программе или программному изделию
5. Требования к программной документации
6. Технико-экономические показатели (можно взять из ТЭО)
7. Стадии и этапы разработки
8. Порядок контроля и приемки
9. Приложения

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

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

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

Код курса

TTIS

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

30 января, 2023

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

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 являются следующие:

1. Введение
2. Назначение
3. Область действия
4. Определения, акронимы и сокращения
5. Ссылки
6. Краткий обзор
7. Общее описание
8. Взаимодействие продукта с другими продуктами и компонентами
9. Функции продукта (краткое описание)
10. Характеристики пользователя
11. Ограничения
12. Допущения и зависимости
13. Детальные требования
14. Требования к внешним интерфейсам
15. Интерфейсы пользователя
16. Интерфейсы аппаратного обеспечения
17. Интерфейсы программного обеспечения
18. Интерфейсы взаимодействия
19. Функциональные требования
20. Требования к производительности
21. Проектные ограничения (и ссылки на стандарты)
22. Нефункциональные требования (надежность, доступность, безопасность и пр.)
23. Другие требования
24. Приложения
25. Алфавитный указатель

ТЗ по ГОСТ 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. Он содержит два шаблона спецификации требований:

• System requirements specification (SyRS)– технические требования к системе и удобству взаимодействия человека с ней;
• Software requirements specification (SRS)— спецификация требований к ПО, включая программное изделие, программу или набору программ (продукт), которые выполняют определенные функции в конкретном окружении.

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

1. Введение
2. Цели
3. Соглашения о терминах
4. Предполагаемая аудитория и последовательность восприятия
5. Масштаб проекта
6. Ссылки на источники
7. Общее описание
8. Видение продукта
9. Функциональность продукта
10. Классы и характеристики пользователей
11. Среда функционирования продукта (операционная среда)
12. Рамки, ограничения, правила и стандарты
13. Документация для пользователей
14. Допущения и зависимости
15. Функциональность системы
16. Функциональный блок X (таких блоков может быть несколько)
17. Описание и приоритет
18. Причинно-следственные связи, алгоритмы (движение процессов, workflows)
19. Функциональные требования
20. Требования к внешним интерфейсам
21. Интерфейсы пользователя (UX)
22. Программные интерфейсы
23. Интерфейсы оборудования
24. Интерфейсы связи и коммуникации
25. Нефункциональные требования
26. Требования к производительности
27. Требования к сохранности (данных)
28. Требования к качеству программного обеспечения
29. Требования к безопасности системы
30. Требования на интеллектуальную собственность
31. Прочее
32. Приложение А: Глоссарий
33. Приложение Б: Модели процессов и предметной области и другие диаграммы
34. Приложение В: Список ключевых задач

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

• глубокий уровень детализации, в частности, подробное описание различных категорий пользователей, интерфейсов, разделение допущений и ограничений;
• разделение требований на функциональные и нефункциональные;
• рекомендации представлять функциональные требования в форме сценариев (вариантов) использования, т.н. use case, которые мы разбирали здесь;
• структурированный и детальный набор разных требований легко разделяется по итерациям гибкой разработки (Agile) через определение их приоритета и очередности реализации по релизам;
• тесная связь с бизнесом благодаря детальному описанию контекста, правил, процессов, организационной среды и других аспектов, описываемых в спецификации требований стейкхолдеров (StRS, Stakeholder requirements specification) в разделах «Видение» и «Общее описание»;
• наглядность трассировки требований разных уровней друг к другу, а также к бизнес-правилам и регламентирующим документам.

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

Источник: babok-school.ru