Комментарии 22
Естественно ГОСТ 34 (и 19) уже устарели
Да ладно! Может Вы их просто готовить не умеете?
Никто не мешает Вам на отлично зарекомендовавший себя скелет навешивать столько фарша, сколько Вам нужно, расширяя и дополняя то, что есть, тем, чего не хватает!
Вопрос разработки документации по ГОСТ больше в том — на сколько полной должна быть формализация проекта и хватит ли на это ресурсов?
Никто не мешает Вам на отлично зарекомендовавший себя скелет навешивать столько фарша, сколько Вам нужно
Поддерживаю.
Во-первых никто не запрещает вводить дополнительные пункты или подпункты ТЗ.
Во-вторых я лично для некоторых бессмысленных в рамках разработки ПО разделов типа «Требования к упаковке» пишу что-то вроде «По согласованию с клиентом пункт исключен из ТЗ» или «Специальные требования не предъявляются»
Я то как раз умею их готовить. А вот многие начинающие (и не только) Аналитики с трудом справляются с ГОСТом. Чего только стоит посмотреть выложенные ТЗ для МЭР. Я просто люблю более конкретные (западные) шаблоны, которые ориентированы на коммерческие реалии. Вот дано вы писали требования к метрологическому обеспечению, транспортабельности или защите от влияния внешних воздействий?
И опять же фраза вырванная из контекста не дает полное представление о том, что я хотел донести. Вот например в конце я пишу:
И опять же фраза вырванная из контекста не дает полное представление о том, что я хотел донести. Вот например в конце я пишу:
При правильном использовании любого из вышеперечисленных стандартов можно брать эти шаблоны для написания ТЗ, естественно адаптируя их под себя.
содержание (наполнение) в ТЗ — самое главное!
Добрый вечер!
Спасибо за статью, очень во время. Для диплома осталось оформить правильно ТЗ на ПО, уже начал по крупицам собирать информацию, а тут сборка основных стандартов!
Спасибо за статью, очень во время. Для диплома осталось оформить правильно ТЗ на ПО, уже начал по крупицам собирать информацию, а тут сборка основных стандартов!
В фармацевтике используется руководство GAMP5( http://www.ispe.org/gamp-5), в котором есть много чего и тоже есть требования к написанию ТЗ, которое называется URS. По ссылке http://www.gmpua.com/GAMP/GAMP.htm есть перевод приложения из GAMP, относящегося к URS.
Все проблемы с договорами вытекают из-за непроработанного ТЗ или вообще от его отсутствия.
.
К ГОСТ 34 обязательно добавлять РД50, где приводится содержание документов, указанных в ГОСТ.
Long time ago in far galaxy…
http://gaperton.livejournal.com/49867.html
http://gaperton.livejournal.com/49867.html
На моей практике все ТЗ были по структуре ближе к ГОСТам.
Самая основная проблема это всегда функциональные требования.
В большинстве случаев они меняются очень сильно после появления прототипа.
И это закладывается во все более менее крупные проекты, иначе созданное ПО тупо будет выброшено в помойку.
Самая основная проблема это всегда функциональные требования.
В большинстве случаев они меняются очень сильно после появления прототипа.
И это закладывается во все более менее крупные проекты, иначе созданное ПО тупо будет выброшено в помойку.
А моя задумка формализовать составление ТЗ в виде иерархического списка (ht_tps://androrder.xyz/h4w), похоже, фигня — пользователи регистрируются, пробуют создать тестовый проект, и бросают…
А что вообще происходит с ТЗ за пределами России есть какие-то общепринятые стандарты, может что-то более универсальное? Есть кто сталкивался с этим?
«Данный стандарт содержит два шаблона спецификации требований:
• System requirements specification (SyRS)
• Software requirements specification (SRS)»
Саша, неправда, там ещё 3-й есть:
Stakeholder Requirements Specification
• System requirements specification (SyRS)
• Software requirements specification (SRS)»
Саша, неправда, там ещё 3-й есть:
Stakeholder Requirements Specification
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стандарты и шаблоны для ТЗ на разработку ПО