D>Не смотря на всю очевидность различий между двумя данными артефактами мне не удалось найти фразу, однозначно объясняющую различия между ними.
Если не удалось найти — то может не тк уж очевидно различие?
Техническое задание на софт описывает различные требования к этому софту и процессу его разработки.
Sofware Requirements Specifications — буквально это тоже перечень требований к софту.
ОЧЕВИДНЫХ различий я тут не вижу.
И вообще какой может быть очевидное отличие между каким-то абстрактным документом, носящим название "ТЗ" и таким же абстрактным документом, носящим название "SRS".
Если скажешь ТЗ ГОСТ такой-то и SRS стандарт такой-то — тогда можно сравнивать. А так — чего сравнивать-то?
Re[2]: Software Requirements Specifications vs. Техническое
Здравствуйте, Igor Trofimov, Вы писали:
D>>Не смотря на всю очевидность различий между двумя данными артефактами мне не удалось найти фразу, однозначно объясняющую различия между ними.
iT>Если не удалось найти — то может не тк уж очевидно различие?
iT>Техническое задание на софт описывает различные требования к этому софту и процессу его разработки.
iT>Sofware Requirements Specifications — буквально это тоже перечень требований к софту.
iT>ОЧЕВИДНЫХ различий я тут не вижу.
iT>И вообще какой может быть очевидное отличие между каким-то абстрактным документом, носящим название "ТЗ" и таким же абстрактным документом, носящим название "SRS".
iT>Если скажешь ТЗ ГОСТ такой-то и SRS стандарт такой-то — тогда можно сравнивать. А так — чего сравнивать-то?
ТЗ ГОСТ номер не скажу, последний по программному обеспечению. SRS определенный Rational Unified Process.
Неужели и впрямь только мне очевидно различие?
Re[3]: Software Requirements Specifications vs. Техническое
Здравствуйте, Igor Trofimov, Вы писали:
D>>ТЗ ГОСТ номер не скажу, последний по программному обеспечению. SRS определенный Rational Unified Process.
iT>Ну вот.. берешь и сравниваешь. iT>Что должно быть описано в том документе и что — в другом.
Вы неверно поняли мою проблему. Я прекрасно способен сравнить оба документа. Но объяснить своему коллеге что это суть разные вещи не получается.
Re[3]: Software Requirements Specifications vs. Техническое
Здравствуйте, descartes, Вы писали:
D>ТЗ ГОСТ номер не скажу, последний по программному обеспечению. SRS определенный Rational Unified Process.
D>Неужели и впрямь только мне очевидно различие?
Не поделишься очевидным? а то сравнивать ломает, а интересно — жутко
Здравствуйте, bralgin, Вы писали:
B>Здравствуйте, descartes, Вы писали:
D>>ТЗ ГОСТ номер не скажу, последний по программному обеспечению. SRS определенный Rational Unified Process.
D>>Неужели и впрямь только мне очевидно различие?
B>Не поделишься очевидным? а то сравнивать ломает, а интересно — жутко
Первое и самое сильное различие: рабочие продукты принадлежат разным методологиям. Продолжать?
Re[5]: Software Requirements Specifications vs. Техническое
D>Первое и самое сильное различие: рабочие продукты принадлежат разным методологиям. Продолжать?
Сперва с этим разберемся... Продукт не может принадлежать методологии
Вероятно, ты имеешь в виду, что и первый и второй документ наряду с требованиями к результату содержат и требования к процессу разработки. И вот там и там требуется, чтобы разработка велась по определенной методологии, и эти методологии различны.
Так?
Re[6]: Software Requirements Specifications vs. Техническое
Здравствуйте, Igor Trofimov, Вы писали:
D>>Первое и самое сильное различие: рабочие продукты принадлежат разным методологиям. Продолжать?
iT>Сперва с этим разберемся... Продукт не может принадлежать методологии iT>Вероятно, ты имеешь в виду, что и первый и второй документ наряду с требованиями к результату содержат и требования к процессу разработки. И вот там и там требуется, чтобы разработка велась по определенной методологии, и эти методологии различны.
iT>Так?
Совершенно верно. Я просто неверно выразил свою мысль. Возможно это лишь борьба за чистоту. Если методология подразумавает спецификацию требований называть SRS то путь это будет SRS, если ТЗ — то ТЗ или там в зависимости от хоть горшок.
Re[5]: Software Requirements Specifications vs. Техническое
Здравствуйте, descartes, Вы писали:
D>Здравствуйте, bralgin, Вы писали:
B>>Здравствуйте, descartes, Вы писали:
D>>>ТЗ ГОСТ номер не скажу, последний по программному обеспечению. SRS определенный Rational Unified Process.
D>>>Неужели и впрямь только мне очевидно различие?
B>>Не поделишься очевидным? а то сравнивать ломает, а интересно — жутко
D>Первое и самое сильное различие: рабочие продукты принадлежат разным методологиям. Продолжать?
[overtopic]
Во-первых, ТЗ и SRS продуктами обычно не называют. Либо артефакты, либо проектная документация.
Во-вторых, такие понятия, как ТЗ и SRS имеют смысл вне методологий так же, так что говорить, что они принадлежат разным методологиям не корректно. К примеру, многие конторы работая по RUP-like методологии пишут ТЗ. Опять же компании, работающие без методологии могут время от времени составлять SRS.
[/overtopic]
От себя могу добавить, что теоритизированные сравнения трактовок ТЗ и SRS в разных методологиях вряд ли имеют пользу.
К примеру, в некоторых организациях составляют кипу документов, каждый из которых имеет свое название и свое предназначение. В других же предпочитают один большой мега-документ, в котором есть все (ну или два документа )! С такой точки зрения какой смысл имеет дискуссия?
Можно еще сильнее изменить точку зрения. Известна тенденция в ИТ иметь минимально необходимый набор документации для каждого проекта. Т.е. в одном проекте это могут быть макеты веб-страниц и краткое описание их работы, в другом это могут быть многостраничные документы с UML диаграммами и сценариями, дополненные подробным описанием ключевых архитектурных решений и планами тестирования, результатами прототипирования и т.п. Главная идея — держать всю нужную документацию, ни больше, ни меньше. Соответственно, вопрос о том, какие шаблоны входят в разные стандарты и методологии с практической точки зрения бессполезен.
Так что если кому-то не лень, просьба провести сравнение шаблонов ГОСТа и SRS из RUP'а, а потом поместить в топик. Было б интересно в целях просвящения, но не более.
... << RSDN@Home 1.1 beta 2 >>
Re[2]: Software Requirements Specifications vs. Техническое
Здравствуйте, Igor Trofimov, Вы писали:
D>>Не смотря на всю очевидность различий между двумя данными артефактами мне не удалось найти фразу, однозначно объясняющую различия между ними.
iT>Если не удалось найти — то может не тк уж очевидно различие?
iT>Техническое задание на софт описывает различные требования к этому софту и процессу его разработки.
iT>Sofware Requirements Specifications — буквально это тоже перечень требований к софту.
iT>ОЧЕВИДНЫХ различий я тут не вижу.
Ну одно из различий ты сам же и указал.
В SRS обычно нет требований на процесс разработки.
В SRS специфицируется программная компонента системы (что должна делать система).
Не больше и не меньше. Есть кто-то в SRS засунет сроки, или описание архитектуры,
или тесты, или еще бог знает что, то это плохой SRS.
Re[5]: Software Requirements Specifications vs. Техническое
Здравствуйте, descartes, Вы писали: D>Вы неверно поняли мою проблему. Я прекрасно способен сравнить оба документа. Но объяснить своему коллеге что это суть разные вещи не получается.
Короче, интуитивно понятно, что ТЗ относится к SRS так же, как
— винный напиток "рябиновая гроздь" к Johnny Walker
— Дед Мороз к Santa Claus
— Лангет к File Mignon
Далее продолжать?..
А научного ответа все едино нету.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, descartes, Вы писали:
D>Коллеги!
D>Возник жесткий спор на тему: "Sofware Requirements Specifications" суть одно и то же что и документ "Техническое задание".
D>Не смотря на всю очевидность различий между двумя данными артефактами мне не удалось найти фразу, однозначно объясняющую различия между ними.
D>Помогите!!!
Давайте подумаем вместе.
Ну во первых, с документами все просто. Название не значит нечего. Хоть горшком назови,только в печь не ставь. Нам сильно поможет, если для каждого документа мы ответим на три вопроса:
1) Целевая аудитория. Кто будет читать этот документ?
2) Цель создания и предназначение. Зачем мы создаем этот документ? Какие проблемы нас на это сподвигли? В чем его цель и какого его предназначение?
3) Способ прочтения документа. Весело, правда? На самом деле этот пункт определяет структуру документа. Способ прочтения русско-английского словаря, книжки Довлатова, и справочника пользователя чего-нибудь сильно отличаются.
В нашей практике техническим заданием мы называли документ, который подписывается заказчиком и определяет что, собственно, будет разработано и за что будут уплачены деньги (и какие). Задача и цель ТЗ состоит в том, что как только он подписан заказчиком, мы гарантируем (1) сроки выполнения заказа и бюджет по данному ТЗ, (2) что мы сделаем тот продукт, который соответствует ТЗ, (3) что мы не сделаем ничего кроме указанного в ТЗ (т.е. все изменения к ТЗ оплачиваются отдельно). Факт подписи ТЗ с нашей стороны означает, что нам понятна задача (по крайней мере процентов на 90) и мы знаем как ее решать настолько, что можем гарантировать сроки и бюджет. При этом мы хотим защититься от изменений требований, желаний, и бизнес-процессов "на халяву" со стороны заказчика.
Требование гарантии по срокам и бюджету и делает наш документ иногда отличным от SRS.
А что вы думаете по этому поводу?
Re: Software Requirements Specifications vs. Техническое зад
Здравствуйте, descartes, Вы писали:
D>Коллеги!
D>Возник жесткий спор на тему: "Sofware Requirements Specifications" суть одно и то же что и документ "Техническое задание".
D>Не смотря на всю очевидность различий между двумя данными артефактами мне не удалось найти фразу, однозначно объясняющую различия между ними.
D>Помогите!!!
Вот это ход.... Ну ты блин даешь
(это лично для автора сабж, он поймет)
Re[2]: Software Requirements Specifications vs. Техническое
Здравствуйте, ATokma, Вы писали:
AT>Здравствуйте, descartes, Вы писали:
D>>Коллеги!
D>>Возник жесткий спор на тему: "Sofware Requirements Specifications" суть одно и то же что и документ "Техническое задание".
D>>Не смотря на всю очевидность различий между двумя данными артефактами мне не удалось найти фразу, однозначно объясняющую различия между ними.
D>>Помогите!!!
Фразу он найти не может!!!
Ну заходи, найду... А то прислал стандарт СССP от 1978 года по составлению ТЗ.
)! С такой точки зрения какой смысл имеет дискуссия?
Весело, правда? На самом деле этот пункт определяет структуру документа. Способ прочтения русско-английского словаря, книжки Довлатова, и справочника пользователя чего-нибудь сильно отличаются.
