asafreeХочу уточнить у инициатора. Интересует мнение по поводу написания ТЗ именно по этому ГОСТ? Или вообще, мнение о написании ТЗ, его назначении и т.п., неважно по какому стандарту?

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

Xoxerixкорректнее то оно корректнее - с этим нельзя не согласиться.

но отечественному заказчику слово ТЗ знакомо больше чем SRS, и я думаю лучше говорить с ним на одном языке :-)

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

mcureenab byur
А вы что собираетесь писать для отчественного заказчика требования по американскому стандарту?

1. Это не запрещено. Каждая фирма пишет ТЗ так как ей удобно. Конечно в случае государственного заказа соблюдение ГОСТов может быть необходимым требованием.
2. ГОСТ 34.602-89 был создан в СССР. Тоже как бы не совсем наш стандарт. :o)))

1. ТЗ суть документ по ГОСТ ... строго говоря, если не соблюдаются требования ГОСТ, а используется вольный формат -- то это уже не ТЗ а просто "документация/спецификация требований". Просто нужно называть вещи своими именами -- иначе только путаница. Пример -- говоря "SQL Сервер" -- полразумеваем класс продуктов или специфический продукт MS SQL Server ... вот вам и путаница.
2. Фирма может писать "ТЗ" как ей удобно, если на это нет возражения Заказчика. Так что тут it depends on ...
3. Стандарт ISO вообще международный, и что его у нас не используют????

mcureenab RubyИнок вы наш, а писать ТЗ-то умеете? Или как Бог на душу положит? Судя по задаваемым вопросам -- не умеете. Но тем не менее пытаетесь спорить :-). Забавно.

Я ТЗ читаю, и хочу знать, написано оно как положено, или "как Бог на душу".

Что-то я не пойму вашей логики -- то вы говорите о том, что "А пока извиняйте, будем *писать* ТЗ", то теперь утверждаете, что только ЧИТАЕТЕ ТЗ ... энтропия неимоверная :-). Хотите называть ваши документы требований в вольном формате, близко не стоявшем с ГОСТ 34.602 как "ТЗ " -- ради бога -- ваше право. Я высказал точку зрения, что терминологией лучше пользоваться.

?А типы требований к автоматизированным системам с 1989 года не изменились ни капельки - в ГОСТ на ТЗ приведена достаточно удобная их классификация.

ГОСТ 34.602 не выделяет, например, пользовательские требования ... в отличие от той же классификации К. Вигерса. И практически не придает значения такому аспекту в работе с требованиями, как управление требованиями, и в частности явно не указывает на желтельность/необходимость управления таким элементом как связи между требованиям. ГОСТ в отличии от классификации К. Вигерса, имеет достаточно плоскую структуру. Я не могу утверждать что такая класиификация удобна.

А вообще более корректно таки говорит не о классификации требований как таковой, которую приводит ГОСТ, а все-таки о требованиях к содержанию документа ТЗ :-).

Позволю себе а в качестве комментария кое-что добавить.

BoatmanВсе правильно, ГОСТ не указывает на необходимость явной трассировки, однако он не запрещает этого. Добавлю, что структурирование документа с нумерацией каждого абзаца в ГОСТовских документах нужно как раз для того, чтобы можно было ссылаться (трассировать?) на этот абзац из любого другого.
Скажу больше: ссылка на абзац из текста позволяет вам учесть несколько видов связей (причинно-следственные, иерархические и т.д.)


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

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


Трассировка обычно относится к управлению требованиями.
Если у меня в абзаце содержиться 15 требований -- к какому из них адресуется ссылка? ГОСТ не определяет необходимость атомарности требований, в отличие от того же IEEE 830.

Boatman
Кроме этого ,вы абсолютно правы, ГОСТ не фиксирует процедуру анализа требований. Если говорить о пользовательских требованиях, то я не считаю их финальными. Для каждого пользовательского требования надо задать вопросы: для чего и трассировать пользовательское требование в функциональное или другое. В ТЗ нет информации о процедуре анализа - там лежит последний слой требований, которые должны проверяться при сдаче системы.


Финальные требования -- это какие? Весь вопрос в целях создания требований к ПО. Есть целый ряд примеров в тех же agile методологиях, где пользовательские требования (выраженные юзкейсами или user stories) практически не декомпозируются на функциональные, т.е. они центральны. Классический RUP предлагает схему -- Vision - UC Specification -- Supplementary Specification, тоже делая акцент на юзкейсах. Другая сторона вопроса -- это собственно что за ПО мы делаем, и уместны ли там пользовательские требования как таковые, чтобы делать акцент именно на них.

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


Ключевое слово, которое вы произнесли -- что документы ГОСТ "удобны для РАБОТЫ с клиентом", но не факт, что эффективны с т.з. себестоимости работ. Любой документ в котором содержатся грамотно описанные требования к ПО (а это может и не быть ГОСТ, не так ли?) может служить источником для приемки системы.

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