В теме 14 ответов, и 7 участников, последнее обновление сделано пользователем 
Андрей В. 12 г, 10 мес. назад.
-
Сообщения
-
Те, кто работает с русскоязычными заказчиками, наверное, больше сталкивается с ТЗ. Те, кто с иностранцами, наверняка, больше сталкивается с документами типа SRS, SDD и т.д.
А в каком соотношении находятся ТЗ и SRS? Одна ли цель у этих документов, похожая ли структура и содержание?Юрий Булуй для SEC(R) 2006 готовил презентацию "Классификация требований к програмному обеспечению и ее представление в стандартах и методологиях" (см. вложение). Возможно, она поможет вам в вашем вопросе.Вот этой "рыбой" я стараюсь руководствоваться: http://en.wikipedia.org/wiki/IEEE_830
Кстати, очень удобный способ убедить заказчика не "выдумывать" необычных требований к форме документа — ссылка на международный стандарт.Мне кажется, техзадание и спецификация требований это немного разные вещи. Например, в первом есть раздел, касающийся ввода в эксплуатацию и сопряженных моментов. ТЗ имхо это описание того, что должно быть сделано, чтобы система была создана и запущена. СРС (опять же имхо) это описание того, что должно быть сделано, чтобы система была создана.
Поэтому ТЗ у нас подписывает Заказчик, а СРС это внутренний документ проектной группы. Может, ошибаюсь.СРС (опять же имхо) это описание того, что должно быть сделано, чтобы система была создана.
Если уж подходить формально и следовать дядьке Вигерсу, то SRS — это описание того, КАК требования должны быть реализованы. Хотя это тоже, наверное, оспариваемо. Я руководствуюсь тем, что SRS — это, в первую очередь, каталог требований функционального уровня (плюс набор нефункциональных, если нужно). А на вопрос "Что" у нас отвечают пользовательские требования. С точки зрения документации, такие требования имхо могут быть и в SRS (хотя занимать явно не большую его часть), и в Vision and Scope (вот там они вроде более к месту), и в кастомных каталогах хотелок (если имеются такие).
пусть КАК,
хотя под своим ЧТО я как раз и понимала ЧТО нужно сделать программисту, чтобы пользовательское ЧТО заработало.
ну да ладно суть не в предлогах, я конечно, некорректно выразилась.Суть моего поста в том, что техническое задание охватывает такие разделы (6-8), которых в SRS нет.
ТЗ на АС содержит следующие разделы, которые могут быть разделены на подразделы:
1) общие сведения;
2) назначение и цели создания (развития) системы;
3) характеристика объектов автоматизации;
4) требования к системе;
5) состав и содержание работ по созданию системы;
6) порядок контроля и приемки системы;
7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
8) требования к документированию;
9) источники разработки.И мне кажется, что SRS, грубо говоря, это пункты с 1 по 5 в ТЗ.
Поправьте, если ошибаюсь
ну да ладно суть не в предлогах
то есть не в предлогах, а вопросительных местоимениях
Суть моего поста в том, что техническое задание охватывает такие разделы (6-8), которых в SRS нет.
6) порядок контроля и приемки системы;
7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
8) требования к документированию;
9) источники разработки.Хороший вопрос подняла Алиша.
Если пункты 6-8 не содержаться в SRS и они нужны (а они нужны?), то где-то же они содержаться? У кого какие были варианты? Открыл для этого обсуждения отдельную тему — "Где и как документируем то, что есть в ТЗ, но нету в SRS?".Интересный вопрос!Надо определиться сначала что есть ТЗ и что есть SRS. Кто первый?
Может это одно и тоже?Интересный вопрос!
Надо определиться сначала что есть ТЗ и что есть SRS. Кто первый?
Может это одно и тоже?Так никто и не ответил
Аналитик никакого отношения не имеет к ТЗ? Аналитик занимается только требованиями т.е. SRS?
Вот, что нам говорит ГОСТ:
ГОСТ 34.602-89 Техническое задание на создание автоматизированной системВот, что говорит википедия:
Техническое задание
переключаем на английский и получаем:
Scope StatementМне кажется ТЗ и SRS — это два разных документа, и назначение у них разное, и вообще понимание назначения этих документов у специалистов разное. ИМХО, SRS больше предназначен для проектной команды, а ТЗ для заказчика. Но мы легко можем получить один документ из другого.
В ГОСТ 19.201-78 пишется: В зависимости от особенностей программы или программного изделия в ТЗ допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них., а в SRS имеется достаточно гибкий раздел "нефункциональные требования", где в свою очередь можно добавлять, удалять и объединять подразделы. Все это позволяет нам из SRS получить ТЗ, и из ТЗ получить SRS, вопрос только в том, как нам удобнее называть.Мне кажется ТЗ и SRS — это два разных документа, и назначение у них разное, и вообще понимание назначения этих документов у специалистов разное. ИМХО, SRS больше предназначен для проектной команды, а ТЗ для заказчика.
Благодарю. Понятно.
А вы что чаще делаете ТЗ или SRS?[quote="skan201"]
Мне кажется ТЗ и SRS — это два разных документа, и назначение у них разное, и вообще понимание назначения этих документов у специалистов разное. ИМХО, SRS больше предназначен для проектной команды, а ТЗ для заказчика.Благодарю. Понятно.
А вы что чаще делаете ТЗ или SRS?[/quote]У нас заказчик внутренний, поэтому я использую только SRS. Адаптировал шаблон от К. Вигерса, который пока удовлетворяет.
У нас заказчик внутренний, поэтому я использую только SRS. Адаптировал шаблон от К. Вигерса, который пока удовлетворяет.
Ясно. Благодарю за ответ!
А можно пример как одно требование будет выглядеть в ТЗ, а как в SRS?
Вы должны авторизироваться для ответа в этой теме.
