Техническое задание на разработку требований, образец

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

Образец техзадания на разработку ПО

«правильная постановка задачи — это уже половина ее решения»
(Д. Гильберт)

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

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

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

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

Поскольку программа для ЭВМ согласно ст.1261 ГК РФ включает в себя также «подготовительные материалы, полученные в ходе разработки программы», автор «технического проекта» по праву может считаться соавтором программы. В то время как разработчик «эскиза», остается лишь автором документа под названием «техническое задание».

Общие требования к составу, содержанию и оформлению техзадания (образец техзадания) изложены в ГОСТ 34.602-89 и ГОСТ 19.201-78.

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

1) общие сведения о программе (указываются полное/сокращенное наименования ПО и его область применения, также в данном разделе следует указать перечень терминов и сокращений, используемых в ТЗ);
2) назначение, цели и задачи ПО;
3) требования к ПО (в частности, его функциональным характеристикам, надежности, безопасности, условия эксплуатации и т.п.);
4) требования к программной документации (указывается предварительный состав проектной (пояснительная записка к ТЗ, программа испытаний ПО и др.) и эксплуатационной (руководство пользователя, администратора и т.п.) документации);
5) стадии и этапы разработки ПО (поэтапное содержание работ, сроки разработки);
6) порядок контроля и приемки (описание процесса сдачи созданного ПО и требования к приемке работы).

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

Максимально детализированное ТЗ может быть выгодно обеим сторонам договора:

 

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

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

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

разное / Авт констр и техн / Техническое задание на разработку программы

Техническое задание на разработку программы «Анализатор плоских механизмов»

1. Наименование и область применения

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

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

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

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

4.2. Требования к надежности

4.3. Условия эксплуатации

4.4. Требования к составу и параметрам технических средств

4.5. Требования к информационной и программной совместимости

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

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

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

5.1. Экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами

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

6.1. Стадии разработки

6.2. Этапы разработки и содержание работ по этапам

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

1. Наименование и область применения

Наименование программы: «Структурный анализатор плоских механизмов». Программа используется в виде прикладного приложения для анализа файла данных формата .DXF систем автоматизированного проектирования, которые поддерживают этот формат.

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

Задание на курсовое проектирование по дисциплине лингвистическое и программное обеспечение САПР, выданное 10 октября 2011 года.

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

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

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

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

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

Исходные данные: файл в формате .DXF экспортированный из системы Компас.

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

4.2. Требования к надёжности

Программа должна работать с абсолютно корректными данными. Программа должна поддерживать диалоговый режим.

4.3. Условия эксплуатации

Условия эксплуатации программы совпадают с условиями эксплуатации ПЭВМ IBM PC и совместимых с ними ПК. Программа должна быть рассчитана на непрофессионального пользователя т.п.

4.4. Требование к составу и параметрам технических средств

Необходимо наличие ПЭВМ IBM PC совместимого ПК с графическим адаптером EGA (VGA). Необходимое дисковое пространство – не менее 500КБайт. Желательно наличие манипулятора типа «мышь».

[2]

4.5. Требование к информационной и программной совместимости

Программа должна работать, автономна под управлением любой операционной системе. Базовый язык программирования: Java Script. Базовый язык гиперразметки: HTML5. Базовый язык стилизации: CSS.

Читайте так же: Документы прилагаемые к протоколу об административном правонарушении

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

Программное изделие может транспортироваться на любом внешнем носителе.

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

Специальных требований к временным характеристикам программы не предъявляется. Специальных требований к ёмкостным характеристикам программы не предъявляется. Программное изделие может транспортироваться на любом внешнем носителе.

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

5.1. Экономические преимущества разработки по сравнению с лучшими отечественными образцами и аналогами

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

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

6.1. Стадии разработки

6.2. Этапы разработки и содержание работ по этапам

Обоснование необходимости разработки программы — на этом этапе выполняются:

— сбор исходных материалов;

— выбор и обоснование критериев эффективности и качества разрабатываемой программы.

Научно-исследовательские работы — на этом этапе выполняются:

— определение структуры входных и выходных данных;

— предварительный выбор методов решения задачи;

— обоснование целесообразности применения ранее разработанных программ;

— определение требований к техническим средствам;

— обоснование принципиальной возможности решения поставленной задачи.

Разработка и утверждение технического задания — на этом этапе выполняются:

— определение требований к программе;

— разработка технико-экономического обоснования разработки программы;

— определение стадий, этапов и сроков разработки программы и документации на нее;

— выбор языков программирования;

Разработка эскизного проекта — на этом этапе выполняются:

— предварительная разработка структуры входных и выходных данных.

— уточнение методов решения задачи;

— разработка общего описания алгоритма решения задачи;

— разработка технико-экономического обоснования.

Утверждение эскизного проекта — на этом этапе выполняются:

— разработка пояснительной записки;

— согласование и утверждение эскизного проекта.

Разработка технического проекта — на этом этапе выполняются:

— уточнение структуры входных и выходных данных;

— разработка алгоритма решения задачи;

— определение формы представления входных и выходных данных;

— определение семантики и синтаксиса языка;

— разработка структуры программы;

— окончательное определение конфигурации технических средств.

Утверждение технического проекта — на этом этапе выполняются:

— разработка плана мероприятий по разработке и внедрению программы;

— разработка пояснительной записки;

— согласование и утверждение технического проекта.

Разработка программы — на этом этапе выполняется:

— программирование и отладка программы.

Разработка программной документации — на этом этапе выполняется:

— разработка программных документов в соответствии с требованиями ЕСПД

Испытания программы — на этом этапе выполняются:

— разработка согласование и утверждение программы и методики испытаний;

— проведение предварительных государственных, межведомственных, приемо-сдаточных и других видов испытаний;

— корректировка программы и программной документации по результатам испытаний.

Подготовка и передача программы — на этом этапе выполняются:

— подготовка и передача программы и программной документации для сопровождения и /или изготовления;

— оформление и утверждение акта о передаче программы на сопровождение и/или изготовление;

— передача программы в фонд алгоритмов и программ.

7. Порядок контроля и приёмки

Предоставление работающего программного продукта на научном семинаре кафедры.

Техническая документация

разработка техдокументации — аванпроекты, НИР, ОКР — СРПП (ВТ), ЕСКД, ЕСПД, КСАС

Техническое задание (ТЗ) на опытно-конструкторскую работу (ОКР) по ГОСТ 15.016-2016

В ТЗ на ОКР рекомендуется предусматривать учет интересов всех возможных потребителей.

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

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

В ТЗ на ОКР рекомендуется предусматривать следующие положения:

  • оценкутехнического уровня и качества продукции на основе одноименной карты по ГОСТ 2.116;
  • прогнозразвития требований на данную продукцию на предполагаемый период ее выпуска;
  • рекомендуемые этапы модернизации (модифицирования) продукции с учетом прогноза развития требований;
  • соответствие требованиям стран предполагаемого экспорта с учетом прогноза развития этих требований;
  • безопасность и доступность эффективного использования продукции инвалидами и гражданами пожилого возраста (для соответствующей продукции, предусмотренной законодательством государств-участников МГС);
  • требования к утилизациибракованной продукции, продукции с истекшими сроками хранения, выработавшей свой ресурс, морально устаревшей и отходов от нее, к удалению опасных отходов.

ТЗ на ОКР может состоять из разделов, располагаемых в следующем порядке:

ТЗ на ОКР может быть дополнено приложениями.

В зависимости от особенностей разрабатываемого (модернизируемого) изделия, условий его применения и эксплуатации допускается вводить в ТЗ на ОКР другие разделы или исключать разделы, в которых нет необходимости.

Конкретное количество, содержание разделов и подразделов ТЗ на ОКР определяет заказчик на основе требований настоящего стандарта с учетом специфики и особенностей создаваемого изделия, условий его применения и эксплуатации.

При необходимости уточнения отдельных требований ТЗ в процессе выполнения ОКР должен быть указан этап ОКР, на котором эти требования уточняют [из п. 6.1.1 ГОСТ 15.016-2016]

Техническое задание к договору

Должна ли быть на заводе изготовителе создана комиссия по работе с рекламациями? Ее состав? основные задачи?

Здравствуйте! В статье написано, что баллы начисляются:»Лицам, проходившим срочную воинскую службу — 1,8 балла», «Лицам, ухаживающим за пожилым человеком. -1,8 .

[1]

Статья полезная и нужная. Посмотрел, на сайте есть и другие полезные материалы. Большое спасибо!

Добрый день! покупатель написал претензию о том, что ему плохо собрали шкаф-купе. я лично приехала проверить шкаф собран все замечательно, но полы имеют большой у.

4. Техническое задание на проектирование новой техники.

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

Читайте так же: Платят ли пенсионеры налог на гараж и землю под ним , а также с его продажи

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

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

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

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

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

— разработку средств автоматизации, отдельных узлов и систем, технологии, измерительных средств, средств контроля, техники безопасности и др.

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

Техническое задание должно содержать три основных раздела:

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

2. перечень документов, требующих совместного рассмотрения Заказчиком и Разработчиком,

3. порядок сдачи и приемки результатов разработки.

При необходимости техническое задание может содержать также требования к подготовке и освоению производства.

Конкретное содержание технического задания определяют Заказчик и Разработчик, а при инициативной разработке — Разработчик.

При наличии у Заказчика индивидуальных требований к разрабатываемой продукции, которые отличаются от требований стандартов, но не снижают эффективность применения продукции в оговоренных условиях, ему следует получить заключение Госстандарта РФ о возможности разработки и производства данной продукции.

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

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

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

— характеристика рынка сбыта,

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

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

— прогнозируемые показатели технического уровня и качества,

— характеристика рынка сбыта,

— технические и тактико-технические характеристики,

— уровень стандартизации и унификации,

— специальные требования к изделию и др.

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

Общий порядок разработки и утверждения технического задания устанавливает Государственный стандарт России ГОСТ 15.001-88

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

Техническое задание оформляют в соответствии с общими требованиями к текстовым конструкторским документам согласно Государственного стандарта ГОСТ 2.105-95.

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

Основные разделы технического задания

Примерный перечень вопросов,

рассматриваемых в разделе

Наименование и область применения (использования).

Наименование и условное обозначение разрабатываемой продукции.

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

Общая характеристика объекта, в котором используют продукцию.

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

Полное наименование документа, на основании которого разрабатывают продукцию.

Организация, утвердившая этот документ, и дата его утверждения.

Наименование и условное обозначение темы разработки.

Цель и назначение разработки

Эксплуатационное и функциональное назначение, перспективность производства продукции.

Перечень научно-исследовательских и других работ.

Перечень экспериментальных образцов и макетов.

Технические (тактико-технические) требования

Состав продукции и требования к конструктивному решению.

Требования к техническим показателям.

Требования к надежности.

Требования к технологичности.

 

Требования к уровню унификации и стандартизации.

Эстетические и эргономические требования.

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

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

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

Требования к транспортировке и хранению.

Ориентировочная экономическая эффективность и срок окупаемости затрат.

Предполагаемая годовая потребность в продукции.

Экономические преимущества разрабатываемой продукции по сравнению с аналогами.

Состав и этапы разработки

Стадии разработки, этапы работ и сроки их выполнения (сроки, указываемые в техническом задании, являются ориентировочными: основные сроки указываются в плане работ или в договоре на разработку нового изделия).

Предприятие-изготовитель разрабатываемого изделия.

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

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

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

Перечень организаций, с которыми следует согласовывать документы.

Общие требования к приемке работ на стадиях разработки.

Количество изготавливаемых опытных образцов продукции.

Приложения к техническому заданию

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

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

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

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

Стандарты и шаблоны для ТЗ на разработку ПО

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

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

• ГОСТ 34
• ГОСТ 19
• IEEE STD 830-1998
• ISO/IEC/ IEEE 29148-2011
• RUP
• SWEBOK, BABOK и пр.

Читайте так же: Заключение договора – гражданское право (ч. 2 обязательственное право)

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

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

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

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

“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” — это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.
Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:

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

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

IEEE STD 830-1998

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

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

1. Введение

  • 1. Назначение
  • 2. Область действия
  • 3. Определения, акронимы и сокращения
  • 4. Ссылки
  • 5. Краткий обзор

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

  • 1. Взаимодействие продукта (с другими продуктами и компонентами)
  • 2. Функции продукта (краткое описание)
  • 3. Характеристики пользователя
  • 4. Ограничения
  • 5. Допущения и зависимости

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

  • 1. Требования к внешним интерфейсам
    • 1. Интерфейсы пользователя
    • 2. Интерфейсы аппаратного обеспечения
    • 3. Интерфейсы программного обеспечения
    • 4. Интерфейсы взаимодействия
  • 2. Функциональные требования
  • 3. Требования к производительности
  • 4. Проектные ограничения (и ссылки на стандарты)
  • 5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
  • 6. Другие требования

4. Приложения
5. Алфавитный указатель

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

Мне же больше нравится адаптированный шаблон Карла Вигерса, который я использую при разработки ТЗ для коммерческих компаний. И вообще дедушка Вигерс предоставляет множество полезных рекомендаций по работе с требованиями (куда идут деньги при покупке этих рекомендаций, читайте в начале красным). Ну а его книжку вы уже несколько раз, надеюсь, перечитали.

ISO/IEC/ IEEE 29148-2011

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

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

• System requirements specification (SyRS)
• Software requirements specification (SRS)

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

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

  • 1. Назначение системы
  • 2. Содержание системы (границы системы)
  • 3. Обзор системы
    • 1. Содержание системы
    • 2. Функции системы
    • 3. Характеристики пользователей
  • 4. Термины и определения

2. Ссылки

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

  • 1. Функциональные требования
  • 2. Требования к юзабилити
  • 3. Требования к производительности
  • 4. Интерфейс (взаимодействие) системы
  • 5. Операции системы
  • 6. Состояния системы
  • 7. Физические характеристики
  • 8. Условия окружения
  • 9. Требования к безопасности
  • 10. Управление информацией
  • 11. Политики и правила
  • 12. Требования к обслуживанию системы на протяжении ее жизненного цикла
  • 13. Требования к упаковке, погрузке-разгрузки, доставке и транспортировке

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

  • 1. Предположения и зависимости
  • 2. Аббревиатуры и сокращений

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

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

  • 1. Назначение
  • 2. Содержание (границы)
    • 3. Обзор продукта
    • 1. Взаимодействие продукта (с другими продуктами и компонентами)
    • 2. Функции продукта (краткое описание)
    • 3. Характеристики пользователей
    • 4. Ограничения
  • 4. Термины и определения

2. Ссылки

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

  • 1. Требования к внешним интерфейсам
  • 2. Функции продукта
  • 3. Требования к юзабилити
  • 4. Требования к производительности
  • 5. Требования к логической структуре БД
  • 6. Ограничения проектирования
  • 7. Системные свойства ПО
  • 8. Дополнительные требования

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

  • 1. Предположения и зависимости
  • 2. Аббревиатуры и сокращений

Читайте так же: Должностная инструкция заведующего лабораторией

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

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

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

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

  • 1. Цель.
  • 2. Краткая сводка возможностей.
  • 3. Определения, акронимы и сокращения.
  • 4. Ссылки.
  • 5. Краткое содержание.

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

  • 1. Обзор вариантов использований.
  • 2. Предположения и зависимости.

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

  • 1. Описание вариантов использования.
  • 2. Дополнительные требования.
  • 3. Другие функциональные требования.
  • 4. Нефункциональные требования.

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

SWEBOK, BABOK и пр.

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

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

А как же Agile?

Я скажу одной фразой из Манифеста Agile: “Working software over comprehensive documentation”. Поэтому в Agile документации отводится совсем мало места.

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

Заключение

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

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

 

Ну а кто дочитал до конца — тому бонус: пример ТЗ, который я писал много лет назад (сейчас уже просто аналитиком давно не работаю, да и другие более удачные примеры запрещает открывать на всеобщее обозрение NDA).

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

Техническое задание на разработку требований, образец

Должна ли быть на заводе изготовителе создана комиссия по работе с рекламациями? Ее состав? основные задачи?

Здравствуйте! В статье написано, что баллы начисляются:»Лицам, проходившим срочную воинскую службу — 1,8 балла», «Лицам, ухаживающим за пожилым человеком. -1,8 .

Статья полезная и нужная. Посмотрел, на сайте есть и другие полезные материалы. Большое спасибо!

Добрый день! покупатель написал претензию о том, что ему плохо собрали шкаф-купе. я лично приехала проверить шкаф собран все замечательно, но полы имеют большой у.

Как написать техническое задание для тендера

Понятие технического задания

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

Цель — зафиксировать задачи по осуществлению конкретного заказа и достижению результатов, ожидаемых заказчиком. Это исходный документ, который учитывает основное назначение.

ТЗ — внутренний документ, но оно публикуется вместе со всей документицией о проведении тендера.

Как написать техническое задание на тендер

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

Руководитель заказчика или иное уполномоченное лицо утверждает данный документ.

 

Законом N 44-ФЗ не регламентировано содержание ТЗ, однако оно должно быть подробным, детальным и давать ясное представление о потребностях и нуждах заказчика. В связи с этим рекомендуется придерживаться следующего алгоритма:

  1. Указать полное наименование объекта с установлением объема закупаемых предметов, услуг.
  2. Конкретизировать описание товаров, указав детально и четко функциональные, качественные и эксплуатационные характеристики.
  3. Обозначить конечную дату или период времени, к которому ожидается достигнуть поставленный результат закупки или установить график оказания услуг.
  4. Установить требования к гарантии, гарантийному обслуживанию и объему предоставления гарантий качества.
  5. Зафиксировать иные существенные условия заказа: место доставки, условия поставки, монтажа, наладки, обучения.

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

Корпоративные хранилища данных. Интеграция систем. Проектная документация.

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

Г О С У Д А Р С Т В Е Н Н Ы Й С Т А Н Д А Р Т С О Ю З А С С Р

Единая система программной документации

ГОСТ 19.201-78

(СТ СЭВ 1627-79)

ТЕХНИЧЕСКОЕ ЗАДАНИЕ.
ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ

United system for program documentation.
Technical specification for development. Requirements to contents and form of presentation

Дата введения с 01.01.80

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

Стандарт полностью соответствует СТ СЭВ 1627-79.

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляются в верхней части листа над текстом.

1.2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78.

Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.

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

1.4. Техническое задание должно содержать следующие разделы:

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

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

(Измененная редакция, Изм. № 1)

2. СОДЕРЖАНИЕ РАЗДЕЛОВ

2.1. В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

(Измененная редакция, Изм. № 1)

2.2. В разделе «Основания для разработки» должны быть указаны:

  • документ (документы), на основании которых ведется разработка;
  • организация, утвердившая этот документ, и дата его утверждения;
  • наименование и (или) условное обозначение темы разработки.

(Измененная редакция, Изм. № 1)

2.3. В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.

2.4. Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:

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

(Измененная редакция, Изм. № 1)

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

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

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

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

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

При необходимости должна обеспечиваться защита информации и программ.

(Измененная редакция, Изм. № 1)

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

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

 

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

(Введен дополнительно, Изм. № 1).

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

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

2.7. В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы.

2.8. В приложениях к техническому заданию, при необходимости, приводят:

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

Переиздание (Ноябрь 1987 г.) с Изменением № 1, утвержденным в июле 1981 г (ИУС 7-81)

Источники


  1. История Академии Наук СССР. — М.: М.-Л.: АН СССР, 2017. — 484 c.

  2. Марченко, М. Н. Теория государства и права в вопросах и ответах. Учебное пособие / М.Н. Марченко. — М.: Проспект, 2014. — 240 c.

  3. Щепина, Анастасия Петровна Римское право. Шпаргалка / Щепина Анастасия Петровна. — М.: РГ-Пресс, Оригинал-макет, 2016. — 757 c.
  4. Сычев, Павел Хищники. Теория и практика рейдерских захватов / Павел Сычев. — М.: Альпина Паблишер, 2011. — 184 c.
  5. Перевалов, В.Д. Теория государства и права / ред. В.М. Корельский, В.Д. Перевалов. — М.: Норма; Издание 2-е, испр. и доп., 2003. — 616 c.