«Разработка технического задания» по МДК.03.01.Технология разработки программного обеспечения

Министерство образования и науки Нижегородской области

Методическая разработка

«Разработка технического задания»

по МДК.03.01.Технология разработки

программного обеспечения

Разработал преподаватель

_______________ У.А. Никифорова

г. Нижний Новгород

2023 год.

Аннотация

Ко мне часто обращаются, чтобы я посоветовала стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статью и отправлю её. Но не тут-то было! Ни одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашла. Придется сделать методическую разработку самой.

В данной методической разработке изложены основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification).

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

СОДЕРЖАНИЕ

ВВЕДЕНИЕ 4

1 ГОСТ 34 6

2 ГОСТ 19 7

3 IEEE STD 830-1998 8

4 ISO/IEC/ IEEE 29148-2011 10

5 RUP 13

6 SWEBOK, BABOK 14

7 Пример написания ТЗ 15

ЗАКЛЮЧЕНИЕ 22

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 23

ВВЕДЕНИЕ

Основная идея: техническое задание (ТЗ) должно быть составлено так, чтобы программист, получивший этот документ, разработал именно то, что заказчик хотел получить. Грамотно составленное техническое задание – половина успеха разрабатываемого проекта.

Как инструмент коммуникации в связке общения заказчик-исполнитель, техническое задание позволяет:

1 обеим сторонам – представить готовый продукт – выполнить попунктную проверку готового продукта (приемочное тестирование — проведение испытаний) – уменьшить число ошибок, связанных с изменением требований в результате их неполноты или ошибочности (на всех стадиях и этапах создания, за исключением испытаний);

2 заказчику – осознать, что именно ему нужно – требовать от исполнителя соответствия продукта всем условиям, оговоренным в ТЗ;

3 исполнителю – понять суть задачи, показать заказчику «технический облик» программного изделия или автоматизированной системы o – спланировать выполнение проекта и работать по намеченному плану – Отказаться от выполнения работ, не указанных в ТЗ.

Техническое задание — исходный документ на проектирование технического объекта (изделия). ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования.

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

1 ГОСТ 34

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы рекомендует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.

Согласно ГОСТ 34 техническое задание должно включать следующие разделы:

1. Общие сведения.

2. Назначение и цели создания (развития) системы.

3. Характеристика объектов автоматизации.

4. Требования к системе.

5. Состав и содержание работ по созданию системы.

6. Порядок контроля и приемки системы.

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие.

8. Требования к документированию.

9. Источники разработки.

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

2 ГОСТ 19

«ГОСТ 19.ххх Единая система программной документации (ЕСПД)» — это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.

Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:

1 Введение.

2 Основания для разработки.

3 Назначение разработки.

4 Требования к программе или программному изделию.

5 Требования к программной документации.

6 Технико-экономические показатели.

7 Стадии и этапы разработки.

8 Порядок контроля и приемки.

9 Приложения.

Естественно, ГОСТ 34 (и 19) уже устарели, но при правильной интерпретации стандартов, можно получить хорошее ТЗ.

3 IEEE STD 830-1998

Достаточно хорошее определение стандарта 830-1998 — IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании: описывается содержание и качественные характеристики правильно составленной спецификации требований к программному обеспечению (SRS) и приводится несколько шаблонов SRS. Данная рекомендуемая методика имеет своей целью установление требований к разрабатываемому программному обеспечению, но также может применяться, чтобы помочь в выборе собственных и коммерческих программных изделий.

Согласно стандарту, техническое задание должно включать следующие разделы:

1 Введение:

• Назначение.

• Область действия.

• Определения, акронимы и сокращения.

• Ссылки.

• Краткий обзор.

2 Общее описание:

• Взаимодействие продукта (с другими продуктами и компонентами).

• Функции продукта (краткое описание).

• Характеристики пользователя.

• Ограничения.

• Допущения и зависимости.

3 Детальные требования (могут быть организованы по-разному):

• Требования к внешним интерфейсам.

• Интерфейсы пользователя.

• Интерфейсы аппаратного обеспечения.

• Интерфейсы программного обеспечения.

• Интерфейсы взаимодействия.

• Функциональные требования

• Требования к производительности

• Проектные ограничения (и ссылки на стандарты)

• Нефункциональные требования (надежность, доступность, безопасность и пр.).

• Другие требования.

4 Приложения.

5 Алфавитный указатель.

На самом деле, новичку достаточно трудно понять, что должно содержаться в данных разделах по вышеприведенной структуре (как и в случае с ГОСТом), поэтому нужно читать сам стандарт, который легко найти в интернете. Как и примеры, правда, на английском языке.

4 ISO/IEC/ IEEE 29148-2011

Стандарт IEEE 29148-2011 обеспечивает единую трактовку процессов и продуктов, используемых при разработке требований на протяжении всего жизненного цикла систем и программного обеспечения. Он приходит на смену стандартов IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.

Данный стандарт содержит два шаблона спецификации требований:

1. System requirements specification (SyRS).

2. Software requirements specification (SRS).

System Requirements Specification (SyRS) определяет технические требования для выбранной системы и удобства взаимодействия предполагаемой системы и человека. Она определяет высокоуровневые требования к системе с точки зрения предметной области, а также информацию об общей цели системы, ее целевой среде и ограничениях, допущениях и нефункциональных требованиях. Она может включать в себя концептуальные модели, спроектированные для иллюстрации содержания системы, сценариев использования, основных сущностей предметной области, данных, информаций и рабочих процессов. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 34.

SyRS может содержать следующие разделы:

1 Введение:

• Назначение системы.

• Содержание системы (границы системы).

• Обзор системы.

• Содержание системы.

• Функции системы.

• Характеристики пользователей.

• Термины и определения.

2 Ссылки.

3 Системные требования:

• Функциональные требования.

• Требования к юзабилити.

• Требования к производительности.

• Интерфейс (взаимодействие) системы.

• Операции системы.

• Состояния системы.

• Физические характеристики.

• Условия окружения.

• Требования к безопасности.

• Управление информацией.

• Политики и правила.

• Требования к обслуживанию системы на протяжении ее жизненного цикла.

• Требования к упаковке, погрузке-разгрузки, доставке и транспортировке.

4 Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3).

5 Приложения:

• Предположения и зависимости.

• Аббревиатуры и сокращений.

SRS - это спецификация требований для определенного программного изделия, программы или набора программ (продуктов), которые выполняют определенные функции в конкретном окружении. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 19, а по структуре очень напоминает SRS из стандарта IEEE 830.

SRS может содержать следующие разделы:

1 Введение

• Назначение.

• Содержание (границы):

• Обзор продукта:

• Взаимодействие продукта (с другими продуктами и компонентами).

• Функции продукта (краткое описание).

• Характеристики пользователей.

• Ограничения.

• Термины и определения.

2 Ссылки.

3 Детальные требования:

• Требования к внешним интерфейсам.

• Функции продукта.

• Требования к юзабилити.

• Требования к производительности.

• Требования к логической структуре БД.

• Ограничения проектирования.

• Системные свойства ПО.

• Дополнительные требования.

4 Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3).

5 Приложения:

• Предположения и зависимости.

• Аббревиатуры и сокращений.

Данный стандарт достаточно сложно найти в открытом виде в интернете, но постараться можно, и опять же только на английском языке.

5 RUP

Структура SRS в RUP (Rational Unified Process) представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований.

Шаблон SRS в RUP адаптирован из стандарта IEEE STD 830 и содержит два варианта:

• Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт.

• Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases):

1. Введение:

• Цель.

• Краткая сводка возможностей.

• Определения, акронимы и сокращения.

• Ссылки.

• Краткое содержание.

1. Обзор системы:

• Обзор вариантов использований.

• Предположения и зависимости.

1. Детальные требований:

• Описание вариантов использования.

• Дополнительные требования.

• Другие функциональные требования.

• Нефункциональные требования.

1. Вспомогательная информация.

Естественно, что в интернете можно найти шаблон и примеры SRS от RUP.

6 SWEBOK, BABOK

SWEBOK, BABOK, а также множество других методологий разработки ПО и сводов знаний при упоминании SRS ссылаются на вышеупомянутые зарубежные стандарты.

Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, которые каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр. Но это все производные документы от вышеупомянутых стандартов, не имеющих отраслевой стандартизации, хотя, в некоторых случаях, уже и с устоявшейся терминологией.

7 Пример написания ТЗ

Краткая характеристика области применения

«Программа поиска маршрута китайского почтальона» – программа, позволяющая во взвешенном связном неориентированном или во взвешенном сильно связном ориентированном мультиграфе без петель найти кратчайший путь, проходящий через каждое ребро (в неориентированном)/дугу (в ориентированном) мультиграфа без петель, по крайней мере, один раз, начинающийся и заканчивающийся в одной и той же вершине.

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

Задача китайского почтальона и ее решение имеют много потенциальных приложений:

– доставка почты, молока и т.д.;

– сбор мусора;

– проверка электрических, телефонных или железнодорожных линий;

– патрулирование улиц определенного района;

– наилучший маршрут для движения сельскохозяйственных машин по полю при посеве чего-либо;

– минимизация пути обхода ремонтными или проверяющими бригадами.

Краткая характеристика области применения

Инструмент создаётся как компонент системы под названием Research Supporter. Данная система представляет собой интерактивный граф цитирования научных статей, где каждая статья является узлом графа, а рёбрами представлены факты наличия одной статьи в списке источников другой. Данный граф расположен на карте, где его узлы можно произвольно перемещать. Разрабатываемая программа позволяет, разместив на карте некоторое количество научных статей, автоматически разделить их на группы семантически близких документов, а также визуализировать полученные группы статей. Основная цель разрабатываемой программы - облегчить работу и взаимодействие исследователей с научными статьями.

Основания для разработки

• документ(ы), на основании которого(ых) ведется разработка (на ФКН приказ – кем издан, дата, номер, полное наименование);

  • наименование и (или) условное обозначение темы разработки;

  • функциональное и эксплуатационное назначение (что и зачем будет делать программа).

В проекте ТЗ номер приказа не указывается, т.к. его еще нет.

Наименование темы - на русском и на английском языках, можно добавить краткое наименование (условное обозначение).

Функциональное назначение

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

Эксплуатационное назначение

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

Требования к программе

• требования к функциональным характеристикам («программа должна позволять сохранять файл проекта» и т.п.);

• требования к надежности («программа должна обеспечивать проверку корректности входных данных» и т.п.);

• условия эксплуатации - требуемая квалификация и уровень подготовки пользователя;

• требования к составу и параметрам технических средств- описание требований к hardware;

• требования к информационной и программной совместимости - описание требований к software.

• требования к маркировке и упаковке;

• требования к транспортированию и хранению;

• специальные требования.

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

Требования к функциональным характеристикам (пример)

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

Требования к серверной части

На серверной части должен быть реализован алгоритм кластеризации статей, разделяющий находящиеся в базе данных статьи, принадлежащие определённой исследовательской карте (research map), на группы таким образом, чтобы статьи в одной группе были семантически ближе по отношению друг к другу, чем по отношению к статьям из других групп. Семантическая близость между статьями определяется как семантическая близость между текстами их заголовков и аннотаций. Для определения семантической близости используется косинусное расстояние между векторными представлениями текстов с помощью алгоритма paragraph2vec. Также должно быть реализовано взаимодействие с базой данных для получения статей и сохранения сгенерированных кластеров. Каждый сгенерированный кластер должен быть представлен как структура, состоящая из собственного уникального по отношению ко всем сущностям в базе данных идентификатора и списка идентификаторов статей, относящихся к этому кластеру. Должна быть возможность задавать количество кластеров, на которые будут разделены статьи.

Требование к взаимодействию клиентской и серверной частей

Взаимодействие между клиентской и серверной частями должно осуществляться посредством HTTP-запросов. При получении GET-запроса от клиента, сервер должен ответить сообщением в формате JSON, содержащим список сгенерированных кластеров с их уникальными идентификаторами и идентификаторами статей, относящихся к ним.

Требования к клиентской части

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

- разделить на кластеры все статьи на карте;

- разделить на кластеры выбранные статьи;

- разделить на новые кластеры статьи, помещённые в выбранные кластеры;

- удалить выбранные кластеры;

- удалить все кластеры.

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

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

Требования к надежности (пример):

1 Требования к обеспечению надежного (устойчивого) функционирования программы

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

2 Время восстановления после отказа

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

3 Отказы из-за некорректных действий оператора

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

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

Условия эксплуатации (пример)

1 Климатические условия эксплуатации

Требований к климатическим условиям эксплуатации не предъявляется.

2 Требования к видам обслуживания

Обслуживание не требуется.

3 Требования к численности и квалификации персонала

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

В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик. Не указывайте устаревшие технические характеристики (обычно появляются из-за copy+past старых документов). Все характеристики надо уметь обосновать. Например, вы используете OpenGL 4.5 – вам нужна соответствующую видеокарта, ОС Window10.

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

Требования к исходным кодам и языкам программирования (пример)

Исходные коды программы должны быть написаны на языке C#.

Требования к программным средствам, используемым программой (пример)

Системные программные средства, используемые программой, должны быть представлены лицензионной локализованной версией операционной системы не ниже Windows 7. На системе должен быть установлен .NET Framework 4.5. Для дальнейшей визуализации потребуется Sparx Enterprise Architect версии не ниже 12.0.

В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.

Примеры:

1. Программа поставляется в виде jar-файла и не требует установки. Требования к маркировке и упаковке не предъявляются.

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

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

В подразделе «Требования к транспортированию и хранению» должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях. Пример: Специальные требования к транспортировке не предъявляются.

Состав программной документации (пример):

– «Программа генерации судоку». Техническое задание (ГОСТ 19.201-78);

– «Программа генерации судоку». Пояснительная записка (ГОСТ 19.404- 79);

– «Программа генерации судоку». Руководство оператора (ГОСТ 19.505- 79);

– «Программа генерации судоку». Программа и методика испытаний (ГОСТ 19.301-79);

– «Программа генерации судоку». Текст программы. (ГОСТ 19.401-78);

ЗАКЛЮЧЕНИЕ

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

Содержание (наполнение) в ТЗ — самое главное! Но это уже совсем другая история… Если есть интерес, то можно пройти онлайн курс Разработка и управление требованиями к ПО.

Также рекомендую ознакомиться со следующими материалами:

1. Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях.

2. Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований.

3. Правила составления Software requirements specification (читать вместе с комментариями).

4. Примеры ТЗ и другой документации по разработке АС для МЭР.

5. ГОСТ-овский стиль управления. Статья Gaperton по правильной работе с ТЗ по ГОСТ.

6. Шаблоны документов для бизнес-аналитиков из группы ВК «Business Analysis Magazine».

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. ГОСТ 19.102-77 Стадии разработки.

2. ГОСТ 19.103-77 Обозначения программ и программных документов.

3. ГОСТ 19.104-78 Основные надписи.

4. ГОСТ 19.105-78 Общие требования к программным документам.

5. ГОСТ 19.106-78 Требования к программным документам, выполненным печатным способом.

6. ГОСТ 19.201-78 Техническое задание. Требования к содержанию и оформлению.

7. Стандарты и шаблоны для ТЗ на разработку ПО / Хабр [https://habr.com/ru/post/328822/]

8. Техническое задание [https://www.hse.ru/data/2018/11/28/1144394719/ТЗ%202018-2019.pdf]