Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => Тема начата: SALar от 06 Мая 2014, 16:10:52
-
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 есть требования к производительности, интерфейсам, БД, стандартам совместимости, надёжности, доступности, безопасности, сопровождаемости и переносимости.
Да, вроде бы этот стандарт (но мне казалось, что я видел его в виде переводного ГОСТа). Значит, неправильно помню. Благодарю.