http://www.trackstudio.ru/sites/default/files/ru/44/TZ_primer.doc

Сейчас довольно много проектов по настройке и такой вариант записи требований вполне приемлем. Сам много лет назад пришел практически к такой нотации.

Сергей,

А какое именно ноу-хау есть в этом формате? Чем отличается это от стандартных требованиях (если заменить решения с нужно разработать на нужно настроить)?

Присоединяюсь к вопросу.

Какая уникальная польза отличает его от остальных?

Не уникальная польза, а область применимости. Просто область применимости.

Т.е. ты хочешь сказать, что стандартный шаблон ТЗ (н-р, по Вигерсу) можно использовать для описания требований к настройке Системы?! Если так, то согласен

Не уникальная польза, а область применимости. Просто область применимости.

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

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

Примеров SRS в рунете маловато. Люди ищут и не могут найти. А так: взял, посмотрел, сделал по образцу.
Хотите берите этот образец, хотите изобретайте свой. В чем проблема?

Примеров SRS в рунете маловато. Люди ищут и не могут найти. А так: взял, посмотрел, сделал по образцу.
Хотите берите этот образец, хотите изобретайте свой. В чем проблема?

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

Всем привет!
Подскажите, в какой нотации сделаны диаграммы?
Не похожи на EPC / BPMN..

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

Меня он привлекает тем, что образцов документации почти нет. Приложите нормальное ТЗ по 34 - всем будет профит. И еще образец по <...> и по <...>. И по RUP. И по MSF. И по Creestal Orange. И по ...

Я с первого взгляда не могу найти в нем каких-либо достоинств по сравнению с подачей по ГОСТ 34 (в отличие от недостатков),

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

А здесь всего навсего SRS. Т.е. следующий за 34.602 документ, раскрывающий лишь малую часть ТЗ.

PS. Может на ЛАФ?

Всем привет!
Подскажите, в какой нотации сделаны диаграммы?
Не похожи на EPC / BPMN..

EPC / BPMN хороши при описании текущего процесса и проектировании будущего. При этом программное обеспечение внедрять совсем необязательно. Вполне можно ограничиться бумажной механизацией. Часто так в разы выгоднее. Не поверите, но даже некоторые программисты это поняли. И используют доску со стикерами вместо трекера задач.

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

Меня он привлекает тем, что образцов документации почти нет. Приложите нормальное ТЗ по 34 - всем будет профит.

Если (если!) интересно и востребовано, могу сделать так:
1) пройти по документу и откомментировать, что мне в этом документе "не нравится" и как, на мой взгляд, было бы лучше.
2) переформатировать его в ГОСТ 34.602.

Единственная засада - время. Его потребуется больше, чем на пару постов в форуме.

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

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

А вот давайте не будем путать теплое с мягким. Это принципиально разные документы.
...
А здесь всего навсего SRS. Т.е. следующий за 34.602 документ, раскрывающий лишь малую часть ТЗ.

Разве?

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

1) Кроме требований по конфигурированию, он содержит функциональные (4.4) и нефункциональные (4.5, 4.6). Последнее, помнится, для SRS вообще чуть ли не табу (ГОСТ по SRS навскидку не помню). Кстати, сами "требования по конфигурированию" я бы без разбора "требованиями" не называл. Часть из них - просто описание работ, которые необходимо провести на объекте автоматизации.
2) "перечень работ, которые могут потребоваться". Или не потребоваться. Это тоже не совсем предмет SRS.

Ну а что касается части малой... Так я видел ГОСТовые ТЗ куда более куцые.

Я к тому, что это SRS в той же степени, что и "каноническое" ТЗ по ГОСТ.

PS. Может на ЛАФ?

Не, я в это время в теплых краях буду.

1) Кроме требований по конфигурированию, он содержит функциональные (4.4) и нефункциональные (4.5, 4.6). Последнее, помнится, для SRS вообще чуть ли не табу (ГОСТ по SRS навскидку не помню).

В ГОСТ 19.201-78 есть требования к надежности, требования к составу и параметрам технических средств, требования к информационной и программной совместимости.

В IEEE SRS 830-1998 есть требования к производительности, интерфейсам, БД, стандартам совместимости, надёжности, доступности, безопасности, сопровождаемости и переносимости.

В IEEE SRS 830-1998 есть требования к производительности, интерфейсам, БД, стандартам совместимости, надёжности, доступности, безопасности, сопровождаемости и переносимости.

Да, вроде бы этот стандарт (но мне казалось, что я видел его в виде переводного ГОСТа). Значит, неправильно помню. Благодарю.