Pull to refresh

Comments 30

Хорошая статья. Думаю только ссылку на IEEE нужно привести.
рад бы — нету ссылки :(( если поделитесь — прикреплю.
спасибо, поставил
Спасибо, мне было бы интересно посмотреть на примеры готовых SRS (FDS), шаблоны оформления, а также ту спецификацию, которую можно считать идеальной. Причем будь-то CMS, Ecommerce или Social Network, в этих проектах, я уверен, есть свои шаблоны и идеалы ;-) Если автор найдет такое и добавит в статью, будет просто замечательно
Поддерживаю, статья сыровата без примера. Можно даже шуточного, но излагающего основную суть каждого раздела.
пример планирую сделать, на это сейчас немножко нет времени
>> Вы используете ТЗ (велосипед), я использую SRS (машину)

Вот здесь не понял :) На работе пользуемся SRS («specs», «спеки» на жаргоне), но ваша аналогия «велосипед» — «автомобиль» как-то неочевидна :/ Слово «велосипед» заставляет думать о ТЗ как о чем-то ненужном, лишнем, бесполезной трате ресурсов на поиск уже известного решения. Давайте назовем его «самокат»

Статья полезная, спасибо.
надо написать не один srs чтобы рассказывать остальным что это такое. беглое чтение дефолтных описаний из шаблона не поможет. судя по описанию functional/nonfunctional reqs автор так и сделал.
Поддерживаю. В реальности получается так, что какие-то разделы можно опустить, каким-то, напротив, уделить больше внимания, какие-то просто не стоят того, чтобы быть в SRS, так как у компании в проектном документообороте уже есть аналоги и внесение тех или иных пунктов будет дублированием, стоящим компании (а в итоге — заказчикам) дополнительных денег.

Однако, с другой стороны, шаблон — он и есть шаблон.
UFO just landed and posted this here
Полезный материал. А если перевести названия разделов для русских заказчиков прокатит? Или в России свои автомобили?
Если что, то вот русский перевод самих пунктов:

Введение
  • — Цели
  • — Соглашения о терминах
  • — Предполагаемая аудитория и «Reading Suggestions» (не знаю как перевести)
  • — Масштаб проекта
  • — Ссылки на источники


Общее описание
  • — Видение продукта
  • — Функциональность продукта
  • — Классы и характеристики пользователей
  • — Среда функционирования продукта (операционная среда)
  • — Рамки, ограничения, правила и стандарты
  • — Документация для пользователей
  • — Допущения и зависимости


Функциональность системы
Функциональный блок X (таких блоков может быть несколько)
  • — Описание и приоритет
  • — Причинно-следственные связи, алгоритмы (движение процессов, workflows)
  • — Функциональные требования


Требования к внешним интерфейсам
  • — Интерфейсы пользователя (UX)
  • — Программные интерфейсы
  • — Интерфейсы оборудования
  • — Интерфейсы связи и коммуникации


Нефункциональные требования
  • — Требования к производительности
  • — Требования к сохранности (данных)
  • — Критерии качества программного обеспечения
  • — Требования к безопасности системы


Прочие требования
Приложение А: Глоссарий
Приложение Б: Модели процессов и предметной области и другие диаграммы
Приложение В: Список ключевых задач
«Reading Suggestions» — тут либо порядок прочтения, либо «рекомендуемая литература». Наверное так.
«Reading Suggestions» — использующиеся соглашения?
А смысл? В России используется своя система гостов, на программное обеспечение и автоматизированные системы, в частности, ГОСТ 19 и 34. Они не такие плохие, как принято считать. А если вы планируете участвовать в серьезных тендерах на автоматизацию задач для государства и бизнеса (того, что покрупнее), SRS там в комиссии никто не примет. Это я так, к слову — приходилось иметь дело с написанием ТЗ по массе спецификаций, включая и SRS и наши ГОСТы…
«Закон Мерфи: Если Вас могут понять неправильно, Вас поймут неправильно.»

Практика показывает, что зачастую творение одного лица очень понятно самому этому лицу, но вот остальным… что делать ???
Почитайте ГОСТы — разницы ноль целых ноль десятых.

Ибо они тупо… зжены с буржуинских :)
про идентификаторы фич отдельно сказать хочется, лучше избегать осмысленных слов, а использовать номера, ибо на практике фичи имеют свойство трансформироваться, что приводит к обрастанию названия всякими суффиксами и префиксами, поэтому остановились на нумерации фич (и других компонентов, требующих идентификаторов) в виде F0001, F0045 и т.п. Самому документу тоже можно назначить идентификатор, который будет выполнять роль неймспейса: SRS0067.F0065
Тогда теряется упомянутая в статье возможность использовать названия фич в тикетах. Понятно, что можно использовать и номера, но тогда постоянно придётся копаться в списке фич, чтобы вспомнить, какому номеру какая фича соответствует.
Копаться придётся в любом случае, проверено на практике.
Но в случае со значащими именами можно хоть пробежаться глазами по списку тикетов и примерно понять, о чём речь. А с номерами этого не получится. Впрочем, каждый оптимизирует свою работу по своему :-)
Не вполне понял, в чем коренное отличие от ТЗ. Разъясните, ежли не трудно
Определиться бы с терминами…
А то так:
Сравниваем «SRS» и «ТЗ»

«ТЗ»
ТЗ — Техническое задание

«SRS»
SRS — Software requirements specification
Software — (англ.) Программное обеспечение
Requirements specification — (англ.) Техническое задание (перев. Lingvo Online:
www.abbyyonline.com/translate.aspx?CardId=72;65;71;75;69;72;65;6d;65;6e;74;73;20;73;70;65;63;69;66;69;63;61;74;69;6f;6e;0;4c;69;6e;67;76;6f;45;63;6f;6e;6f;6d;69;63;73;20;28;45;6e;2d;52;75;29)
Итого: SRS — ТЗ на ПО

Вот и получается, что сравниваем бегемота с гиппопотамом
Sign up to leave a comment.

Articles