Пример требований к настройке системы(Прочитано 6032 раз)
http://www.trackstudio.ru/sites/default/files/ru/44/TZ_primer.doc

Сейчас довольно много проектов по настройке и такой вариант записи требований вполне приемлем. Сам много лет назад пришел практически к такой нотации.
Сергей Мартыненко
http://martyinenko-sergey1.moikrug.ru/



Сергей,

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



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

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



Не уникальная польза, а область применимости. Просто область применимости.
Сергей Мартыненко
http://martyinenko-sergey1.moikrug.ru/



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



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

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



Принято. Какова сравнительная (от отношению к остальным) польза этого формата в области его применимости?
Удобнее он, компактнее, проще для понимания, просто прикольный - должны же быть основания для применения именно его, а не аналогов?
Примеров SRS в рунете маловато. Люди ищут и не могут найти. А так: взял, посмотрел, сделал по образцу.
Хотите берите этот образец, хотите изобретайте свой. В чем проблема?
Сергей Мартыненко
http://martyinenko-sergey1.moikrug.ru/



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

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



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



Да нет никаких проблем. Вы поделились примером, а мне интересно, чем именно он Вас привлекает.
Я с первого взгляда не могу найти в нем каких-либо достоинств по сравнению с подачей по ГОСТ 34 (в отличие от недостатков), поэтому и спрашиваю. Не хотелось бы упустить что-нибудь интересное и потенциально полезное.
Меня он привлекает тем, что образцов документации почти нет. Приложите нормальное ТЗ по 34 - всем будет профит. И еще образец по <...> и по <...>. И по RUP. И по MSF. И по Creestal Orange. И по ...

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

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

PS. Может на ЛАФ?
Сергей Мартыненко
http://martyinenko-sergey1.moikrug.ru/



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

А вот для описания спецификации требований к ПО часто удобнее использовать другие диаграммы. В документе один из вариантов диаграммы состояний (из UML).
Сергей Мартыненко
http://martyinenko-sergey1.moikrug.ru/



Меня он привлекает тем, что образцов документации почти нет. Приложите нормальное ТЗ по 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 есть требования к производительности, интерфейсам, БД, стандартам совместимости, надёжности, доступности, безопасности, сопровождаемости и переносимости.

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




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19