Образец технического задания на закупку программного обеспечения для скорой помощи

Содержание
  1. Пример тз на разработку программного обеспечения, как написать техническое задание
  2. Структура технического задания
  3. Бизнес vs Функциональные требования
  4. Обычно мы включаем
  5. Правильное техническое задание на разработку программного обеспечения – секрет успешного проекта
  6. Основные принципы
  7. Опыт в предметной области
  8. Техническое задание на поставку системного и прикладного лицензионного программного обеспечения Требования к поставляемой продукции
  9. Требования к поставляемойпродукции
  10. Требования по гарантийномуи послегарантийному обслуживанию
  11. Требования к поставке исопровождению программного обеспечения
  12. Техническое задание на закупку – подготовка и образец
  13. Подготовка технического задания
  14. Стандарты и шаблоны для ТЗ на разработку ПО
  15. Гост 34
  16. Гост 19
  17. IEEE STD 830-1998
  18. ISO/IEC/ IEEE 29148-2011
  19. RUP
  20. SWEBOK, BABOK и пр
  21. А как же agile?
  22. Заключение
  23. Образец технического задания на разработку программы. Пишем техническое задание
  24. 1. Введение
  25. 1.2. Назначение и область применения
  26. 2. Требования к программе
  27. 2.2.1 Требования к обеспечению надежного функционирования программы
  28. 2.2.2. Время восстановления после отказа
  29. 2.2.3. Отказы из-за некоректных действий оператора
  30. 3. Условия эксплуатации
  31. 3.2. Требования к квалификации и численности персонала
  32. 3.3. Требования к составу и параметрам технических средств
  33. 3.4.1. Требования к информационным структурам и методам решения
  34. 3.4.2. Требования к исходным кодам и языкам программирования
  35. 3.4.3. Требования к программным средствам, используемым программой
  36. 3.4.4. Требования к защите информации и программ
  37. 3.5. Специальные требования
  38. 4. Требования к программной документации
  39. 5. Технико-экономические показатели
  40. 6. Стадии и этапы разработки
  41. 6.2. Этапы разработки
  42. 7. Порядок контроля и приемки
  43. 7.2. Общие требования к приемке работы
  44. Кому поручить написание ТЗ на программу

Пример тз на разработку программного обеспечения, как написать техническое задание

Образец технического задания на закупку программного обеспечения для скорой помощи

Написание технического задания — один из первых этапов работы над проектом. Он предваряет разработку самой системы.

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

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

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

Мы используем термины «Бизнес-требования» (BRD — Business requirements document), «Функциональные требования» (FRD – Functional requirements document) и Технико-архитектурные требования (TAD – Technical Architecture document).

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

Документ, который мы в большинстве случаев используем для взаимодействия с заказчиками состоит на 70% — из бизнес-требований, на 20% из функциональных требований и только на 10% — из технико-архитектурных требований. Конечно, эта пропорция варьируется в зависимости от специфики и технической сложности системы.

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

Ведь задача аналитиков состоит в том чтобы фактически произвести операцию brain-dump, и результаты расположить на бумаге в структурированном виде.

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

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

Структура технического задания

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

1. Оглавление 2. История изменений документа 3. Участники проекта 4. Назначение документа 5. Терминология

6. Общий контекст

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

В разделе «Терминология» технического задания на баннерную систему мы определяем такие понятия как Показы, Клики, CTR, Охват, Частота контакта, Файл бронирования и т.

п, а в разделе «Общий контекст» — описываем основные бизнес-процессы компании-заказчика, относящиеся к размещению баннерной рекламы, а также — системное окружение, текущие роли менеджеров компании и права доступа. Стоит отметить, что в данном конкретном случае система строилась не на пустом месте.

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

7. Система размещения баннеров
8.

Взаимодействие с биллингом 9. Banner Engine

10. Техническое описание компонента Banner Engine

Самый объемный раздел описываемого нами технического задания – «Система размещения баннеров»; он посвящён ядру разрабатываемой системы и содержит все требования непосредственно к системе управления рекламными местами.

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

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

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

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

Бизнес vs Функциональные требования

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

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

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

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

Пример бизнес-требования:

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

Пример функционального требования:

«Для решения этой задачи [какой – см. выше] предполагается использовать внешний сервис, к которому баннерные сервера будут обращаться при каждом показе баннера. Поскольку данный сервис является точкой отказа, баннерные сервера должны корректно обрабатывать ситуацию когда внешний сервис недоступен или отвечает с задержками».

Обычно мы включаем

Техническое задание содержит описание ролей и основных пользовательских сценариев в разрабатываемой системе.

Правильное техническое задание на разработку программного обеспечения – секрет успешного проекта

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

Название сценария: Создание рекламного места

Роль: Администратор

Пример функционального требования:

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

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

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

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

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

Каждый показ баннера сопровождается запросом от системы управления сайтом к баннерной системе.

Эти системы, кроме того, используют общие идентификаторы площадок и рекламных мест, а также согласованные имена параметров таргетирования».

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

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

Частота контакта – количество уникальных пользователей, посмотревших рекламный баннер определенное число раз. Например, частота контакта 5 – количество уникальных пользователей, каждый из которых посмотрел данный рекламный баннер не менее 5 раз. Частота контакта 1 = Охват.

Основные принципы

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

В данном контексте, мы видим своей целью т.н. рисование ТЗ, т.е.

представление всех более-менее сложных фрагментов системы в графическом виде и использование текста в качестве комментариев к графическим материалам.

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

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

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

Вот такой прототип экрана редактирования рекламной кампании был включен в ТЗ на систему баннерной рекламы.

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

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

Опыт в предметной области

Большое значение при создании технического задания имеет опыт разработки похожих систем. Он помогает быстрее вникать в бизнес-процессы и потребности заказчика, делать «по аналогии» многие вещи, которые ранее казались бы нам сложными.

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

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

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

Источник: https://steptosleep.ru/%D1%82%D0%B5%D1%85%D0%BD%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5-%D0%B7%D0%B0%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BD%D0%B0-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%83/

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

Образец технического задания на закупку программного обеспечения для скорой помощи

Сохрани ссылку в одной из сетей:

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

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

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

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

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

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

Все поставляемое программноеобеспечение должно быть лицензировано.Обладателем лицензии должен бытьКазанский федеральный университет(КФУ). Передача лицензии от третьих лицне допускается.

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

Требования по гарантийномуи послегарантийному обслуживанию

Гарантийное обслуживаниепоставляемого товара должно осуществлятьсябез затрат со стороны Заказчика в течение1 (Одного) года.

Поставщик должен обеспечитьфункционирование в режиме 8 часов х 5дней специализированного ресурсатехнической поддержки на русском языке.Поставщик обязан предоставить контактнуюинформацию (телефон и адрес электроннойпочты), по которой представители Заказчикамогут получать техническую поддержку.Указанный телефон должен функционироватьпо рабочим дням с 10 до 18 часов по местномувремени.

Продолжительность техническойподдержки программного обеспечениядолжна составлять не менее 3 (Трех)месяцев с момента поставки программногообеспечения.

Поставщик должен продемонстрироватьвозможность удаленного (через сетьInternet) доступа к ресурсам техническойподдержки.

Требования к поставке исопровождению программного обеспечения

Срок поставки программногообеспечения не может превышать 1 (одного)месяца с момента подписания договора.

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

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

Ответственный исполнительРуководитель подразделения
(ФИО, подпись)(ФИО, подпись)

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

Наименованиепоставляемогопрограммного обеспеченияТехнические характеристикиКол-во
1Mathcad Education – University Edition (100 pack)Программное обеспечение РТС Mathcad представляет собой интегрированную систему решения математических, инженерно-технических и научных задач. РТС Mathcad включает текстовый и формульный редакторы, вычислитель, средства научной и деловой графики, базу справочной информации (математической и инженерной). Информационная база организована в виде встроенного справочника, комплекта электронных книг и печатных изданий, в том числе и на русском языке.Программное решение PTC MathCad является универсальной системой, что позволяет использовать ее в любой области науки и техники, где применяются математические методы. Запись команд в системе Mathcad осуществляется на языке, который приближен к стандартному языку математических расчетов.РТС Mathcad включает:
  • Текстовый редактор предназначен для ввода и редактирования комментариев. В состав комментариев могут входить символы, выражения, формулы.
  • Формульный процессор дает возможность простого «многоэтажного» набора формул.
  • Вычислитель обеспечивает процесс расчета по математическим формулам, содержит набор встроенных математических функций. Модуль позволяет вычислять ряды, суммы, произведения, интегралы, производные, работать с комплексными числами, решать линейные, нелинейные и дифференциальные уравнения и системы, проводить минимизацию и максимизацию функций, выполнять векторные и матричные операции, статистический анализ и т.д. Система дает возможность менять разрядность и базу чисел, погрешность итерационных методов. Кроме того, ведется контроль размерностей и пересчет в разных системах измерения (СИ, СГС, англо-американская, пользовательская).
  • Графический процессор служит для создания графиков и диаграмм, сочетает простоту интерфейса с возможностями средств деловой и научной графики. Процессор ориентирован на решение типичных математических задач. Возможно быстрое изменение вида и размера графиков, наложение на них текстовых надписей и перемещение в любое место документа.

Основные возможности:

Источник: https://gigabaza.ru/doc/78182.html

Техническое задание на закупку – подготовка и образец

Образец технического задания на закупку программного обеспечения для скорой помощи

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

Чем точнее и корректнее будет составлено ТЗ, тем проще будет и поставщику и самому заказчику.

Техническое задание на закупку должно соответствовать требованиям законодательства. И помимо 44-ФЗ при подготовке ТЗ необходимо учитывать нормативные требования Антимонопольной службы и законодательства о техническом регулировании.

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

Разработка технического задания по 44-ФЗ

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

Совет: стоит помнить, что излишние требования и конкретизация могут противоречить требованиям 44-ФЗ, поэтому всегда стоит следовать его нормам.

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

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

  1. в какой форме будут проводиться тендеры;

  2. можно ли объединить некоторые лоты в одну закупку или разумнее будет произвести несколько операций;

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

От всех этих нюансов зависит, как именно будет составлен план закупок и план-график соответственно.

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

При подготовке техзадания на закупку, заказчик должен максимально открыто и точно указывать все параметры, чтобы подрядчик смог подготовить качественное предложение, оценив объем и сложность. Очень важно указывать требования в соответствии с 44-ФЗ, не превышая полномочий.

Обычно техническое задание закупки содержит следующие пункты:

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

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

Рассматривая эти конкретные показатели заказчик будет принимать решение о допуске поставщиков к участию в аукционе.

Образец технического задания на закупку

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

Пример технического задания по 44 ФЗ и ответа на него вы можете посмотреть на нашем сайте на странице “Подготовки и подачи заявки”. В данном примере подробно описано, как должно выглядеть ТЗ в тендерной документации заказчика и каким образом должен писать ответ подрядчик. Эта информация будет полезна для всех участников торгов.

©ООО МКК “РусТендер” 

Материал является собственностью tender-rus.ru. Любое использование статьи без указания источника – tender-rus.ru запрещено в соответствии со статьей 1259 ГК РФ

Первая часть заявки на участие в аукционе

Вторая часть заявки на участие в тендере

Декларация соответствия участника требованиям ФЗ 44 – образец

Поделитесь ссылкой на эту статью

Источник: https://tender-rus.ru/vopros-otvet/zayavka-na-tender/tehnicheskie-zadaniya-na-zakupku

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

Образец технического задания на закупку программного обеспечения для скорой помощи

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

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

Придется сделать такую статейку самому… И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification): • Гост 34 • Гост 19 • IEEE STD 830-1998 • ISO/IEC/ IEEE 29148-2011 • RUP • SWEBOK, BABOK и пр.

Гост 34

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

Согласно Гост 34 техническое задание должно включать следующие разделы: 1. Общие сведения 2. Назначение и цели создания (развития) системы 3. Характеристика объектов автоматизации 4. Требования к системе 5. Состав и содержание работ по созданию системы 6.

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

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

Гост 19

“Гост 19.

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

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

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

IEEE STD 830-1998

Достаточно хорошее определение стандарта 830-1998 — IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании: Описывается содержание и качественные характеристики правильно составленной спецификации требований к программному обеспечению (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. Введение

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

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

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

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

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

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

Введение

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

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

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

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

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

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

RUP

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

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

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

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

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

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

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

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

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

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

SWEBOK, BABOK и пр

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

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

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

А как же agile?

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

Заключение

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

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

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

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

  • Анализ и проектирование систем

Источник: https://habr.com/ru/post/328822/

Образец технического задания на разработку программы. Пишем техническое задание

Образец технического задания на закупку программного обеспечения для скорой помощи

1. Введение 1.1. Наименование программы 1.2. Назначение и область примененияпрограммы2. Требования к программе 2.1. Требования к функциональным характеристикампрограммы2.2. Требования к надежностипрограммы2.2.1. Требования к обеспечению надежного функционирования программы 2.2.2.

Время восстановления программы после отказа 2.2.3. Отказы программы из-за некоректных действий оператора 3. Условия эксплуатации программы3.1. Климатические условия эксплуатации программы 3.2. Требования к квалификации и численности персонала 3.3. Требования к составу и параметрам технических средств 3.4.

Требования к информационной совместимости 3.4.1. Требования к информационным структурам и методам решения 3.4.2. Требования к исходным кодам и языкам программирования 3.4.3. Требования к программным средствам, используемым программой 3.4.4. Требования к защите информации и программ 3.5. Специальные требования

4.

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

4.1. Предварительный состав программной документации 5. Технико-экономические показатели 5.1. Экономические преимущества разработкипрограммы6. Стадии и этапы разработкипрограммы6.1. Стадии разработкипрограммы6.2. Этапы разработкипрограммы6.3. работ по этапам 7. Порядок контроля и приемки 7.1. Виды испытаний

7.2. Общие требования к приемке работы

1. Введение

Наименование программы: “Тестовая программа”

1.2. Назначение и область применения

Программа предназначена для…

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

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

2.2.1 Требования к обеспечению надежного функционирования программы

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

б) использованием лицензионного программного обеспечения;

в) регулярным выполнением рекомендаций Министерства труда исоциального развития РФ, изложенных в Постановлении от 23 июля 1998 г.

Об утверждении межотраслевых типовых норм времени на работы посервисному обслуживанию ПЭВМ и оргтехники и сопровождению программныхсредств»;

г) регулярным выполнением требований ГОСТ 51188-98.

Защитаинформации. Испытания программных средств на наличие компьютерныхвирусов

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

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

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

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

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

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

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

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

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

Системный администратор должен иметь высшее профильноеобразование и сертификаты компании-производителя операционной системы.

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

г) задача создания резервных копий базы данных.

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

3.3.1. В состав технических средств должен входить IВМ-совместимыйперсональный компьютер (ПЭВМ), выполняющий роль сервера, включающий всебя: 3.3.1.1. процессор Pentium-2.0Hz, не менее; 3.3.1.2.

оперативную память объемом, 1Гигабайт, не менее; 3.3.1.3. оперативную память объемом, 1Гигабайт, не менее; 3.3.1.4. операционную систему Windows 2000 Server или Windows 2003; 3.3.1.5.

операционную систему Windows 2000 Server или Windows 2003;

3.3.1.6. Microsoft SQL Server 2000

3.4.1. Требования к информационным структурам и методам решения

База данных работает под управлением Microsoft SQL Server.Используется много поточный доступ к базе данных. Необходимо обеспечитьодновременную работу с программой с той же базой данной модулейэкспорта внешних данных.

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

Дополнительные требования не предъявляются

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

Системные программные средства, используемые программой, должны бытьпредставлены лицензионной локализованной версией операционной системыWindows 2000 Server или Windows 2003 и Microsoft SQL Server 2000

3.4.4. Требования к защите информации и программ

Требования к защите информации и программ не предъявляются

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

Специальные требования к данной программе не предьявляются

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

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

4.1.3. руководство оператора;

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

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

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

Разработка должна быть проведена в три стадии: 1. разработка технического задания; 2. рабочее проектирование;

3. внедрение.

6.2. Этапы разработки

На стадии разработки технического задания должен быть выполнен этапразработки, согласования и утверждения настоящего технического задания. На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ: 1. разработка программы; 2. разработка программной документации; 3. испытания программы.

На стадии внедрения должен быть выполнен этап разработки подготовка и передача программы

На этапе разработки технического задания должны быть выполнены перечисленные ниже работы: 1. постановка задачи; 2. определение и уточнение требований к техническим средствам; 3. определение требований к программе; 4.

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

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

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

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

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

Приемо-сдаточные испытания должны проводиться на объекте Заказчика в оговоренные сроки. Приемо-сдаточные испытания программы должны проводиться согласноразработанной Исполнителем и согласованной Заказчиком Программы иметодик испытаний.

Ход проведения приемо-сдаточных испытаний Заказчик и Исполнитель документируют в Протоколе проведения испытаний

7.2. Общие требования к приемке работы

На основании Протокола проведения испытаний Исполнитель совместно сЗаказчиком подписывает Акт приемки-сдачи программы в эксплуатацию.

МИНИСТЕРСТВО НАУКИ И ОБРАЗОВАНИЯ

РОССИЙСКОЙ ФЕДЕРАЦИИ

ГОУ ВПО «АДЫГЕЙСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»

ФИЗИЧЕСКИЙ ФАКУЛЬТЕТ

КАФЕДРА АСОИУ

ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ ПРОГРАММНОГО

ПРОДУКТА

ВВЕДЕНИЕ…………………………………………….…………………………. … 3

1. ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ……………………………………….. ……4

1.1. Документ, на основании которого ведётся разработка……………………….4

1.2. Организация, утвердившая основание разработки, и дата его утверждения4

1.3. Наименование темы разработки…………….………………………………….4

2. НАЗНАЧЕНИЕ РАЗРАБОТКИ……………….…………………………………..5

2.1 Критерии эффективности и качества программы…….………………………..5

2.2 Цели разработки программы…………………………….………………………5

3. ТРЕБОВАНИЯ К ПРОГРАММЕ…………………………….……………………6

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

3.1.1 Состав выполняемых функций………………………………..……………….6

3.1.2 Организация входных и выходных данных…………………….…………….6

3.1.3 Временные характеристики и размер занимаемой памяти……..……………6

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

3.2.1 Требования к надежному функционированию……………………….………6

3.2.2 Контроль входной и выходной информации……………………………..…..7

3.2.3 Время восстановления после отказа……………………………………….….7

3.3 Условия эксплуатации……………………………………………………………7

3.4 Требования к составу и параметрам технических средств……………………7

3.5 Требования к языкам программирования……………………………………….8

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

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

4. ТЕХНИКО-ЭКОНОМИЧЕСКИЕ ПОКАЗАТЕЛИ………………………… ….. 9

5. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ………………………………………………9

6. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ……………………………………………9

6.1 Виды испытаний…………………………………………………………………..9

6.2 Общие требования к приёмке…………………………………………………..10

7. ЭТАПЫ ВНЕДРЕНИЯ……………………………………………………………10

ВВЕДЕНИЕ

Полное наименование программной разработки: “Программа К”, в дальнейшем именуемая как “программа”. Краткое название программы – «ПК».

На данный момент аналогичных программных продуктов не существует.

Разрабатываемая программа применяется на любом предприятии, где имеется рабочий персонал.

Разработчик данного программного продукта – студент группы 4А1 Иванов А.В. в дальнейшем именуемый как “разработчик “.

Заказчик программного продукта – ОАО «РТС», в лице директора А.М. Гутенко.

1 ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ

1.1 Документ, на основании которого ведётся разработка

Работа ведётся на основании задания по дисциплине «Теоретические основы автоматизированного управления»

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

Задание утверждено и выдано начальником технического отдела ОАО «РТС» Козаковым А.В.

Козаков А.В.

1.3 Наименование темы разработки

Наименование темы разработки – «Учёт рабочего времени».

2 НАЗНАЧЕНИЕ РАЗРАБОТКИ

Данная разработка является семестровой работой по дисциплине «Теоретические основы автоматизированного управления»

2.1 Критерии эффективности и качества программы

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

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

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

Технология создания программы в визуальных средах программирования делает ее интерфейс универсальным и совместимым с операционными системами Windows 95/98/2000/XP.

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

2.2 Цели разработки программы

Создание данной программы преследует ряд технико-экономических целей:

Создание программного продукта, необходимого для учёта рабочего времени.

Создание дешевой альтернативы существующим в настоящее время дорогим программам.

Создание интуитивно понятной программы с удобным и универсальным Windows.

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

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

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

Кому поручить написание ТЗ на программу

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

Источник: https://telebrands24.ru/provoloka/sample-specifications-for-the-development-of-the-program-write-a-technical-assignment/

Указ и право
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: