Requirement management (rus)

Требования. Один документ или много?

Введение

На моей практике я успел поработать в компаниях, которые писали требования как в рамках одного документа, так и в рамках отдельного документа на каждый объект создаваемой системы. В данном случае, под объектом я буду рассматривать один или несколько элементов доменной модели (а это ещё могут быть нефункциональные требования и тп), которые являются в системе либо справочником, либо документом (карточкой, страницей, кто как называет), но не на каждое или группу ФТ (функциональное требование). На основании этого документа ведется разработка и тестирование (в частности), его же подписывает и заказчик.

Один большой документ на всем протяжении проекта

Изначально при работе с заказчиком мы собираем требования, формируем ТЗ (которые в моей практике зачастую выглядят как требования разработчикам, так что тут ТЗ=постановки на реализацию), а после чего нам необходимо этот документ подписать.
В каком случае мы можем работать с одним документом? Такая ситуация может возникнуть, если над проектом работает один аналитик, а так же один или множество заказчиков. При работе с множеством заказчиков в одном документе потребуется хорошо планировать работу, чтобы проверку требований и реализации заказчики осуществляли поочередно. Это очень тяжело, так что я всегда вел требования каждого заказчика в отдельном документе, а после согласований их объединял. В данном случае, если заказчиков множество, то придётся распараллелить их работу по согласованию документа, что скажется на сроках проекта.
В написании требований одним документом есть следующие преимущества:

  • Сквозная нумерация разделов (которая, правда, может поехать при обновлении формул, но ведь гораздо удобнее написать – делай ФТ12.1.13, чем делать ФТ*************** ******* ******** ****** (****** ******)
  • Сквозная нумерация полей (и формул), требований в системе.
  • Описание формул при помощи ссылок на их уникальные номера. Согласимся, что написать в формуле расчета: 546/32, если 96>12 будет гораздо быстрее, чем писать, что итог  =поле  *** справочника ***, деленное на поле *** справочника ***, вкладки ***, при условии, что поле *** документа *** больше поля *** справочника ***. И это ещё не самая изощрённая формула…
  • Удобство поиска (ищем в одном документе, а не перебираем множество существующих)

Соответственно, при работе с одним заказчиком одного аналитика эффективнее работать в рамках одного документа. Но тут можно заметить, что эти плюсы более существенны при передаче проекта – в одном документе проще ориентироваться при погружении в проект, в то время, как автор, обычно, помнит, где и что написано.

Проблем с обновлением быть не должно – новые поля нужно вносить с уникальным номером (добавлять список ниже), а вообще, лучше вести их в отдельном ексель-файле, а в ТЗ давать только ссылки на номер поля в ексельнике.

Много документов и мы можем эти документы по отдельности подписать

Если проект автоматизирует какую-либо большую область, то тут уже требуется работа нескольких аналитиков, особенно, если объемный проект следует выполнить за более короткий срок, чем если его будет вести один аналитик.
Мне, например, гораздо эффективнее и комфортнее работать как минимум в паре, постоянно критикуя каждое требование и идею друг друга, а потом фиксируя решение. При такой организации работы можно осуществлять тестирование требований, обсуждать их и спокойно уходить в отпуск, не боясь звонков и вопросов. Однако работа в команде сразу говорит о том, что у вас не получится писать ТЗ в одном документе.
Значит, такое случается, если аналитиков много, а каждый из них пишет свою часть (либо аналитик не сумел распараллелить заказчиков). Либо одна часть будет равна тому объему работы, который взял на себя аналитик, либо, документ будет реализован на каждую фичу (я так никогда не работал, рассмотрю это в следующий раз), либо на каждый объект в системе. В итоге все это нам подписывает один человек и он согласен на кучу документов.
Подход
Кучу мелких доков писать несколько дольше с той точки зрения, что мы не можем использовать нумерацию полей, либо же потребуется использовать префикс в каждом документе (кстати, читай – интерфейсе), а формула будет выглядеть например так “=БС13/(ПС42 – КОП56)”. Можно писать все текстом, здесь есть плюсы и минусы – с одной стороны, при переименовании поля – не надо его же переименовывать во всех документах, с другой, без открытия дополнительных файлов можно узнать что считает формула, а так же нет трудностей при изменении местоположения поля, если их номера соответствуют порядку отображения (что логично).
Большим минусом могу выделить поиск по документам и необходимость держать в голове все формулы, где используется данное поле, чтобы апдейтить другие документы. Возможно, проблему решит матрица трассировки, но в ней будет мало конкретики, если привязывать документ к документу.
Опять же можно выделить отдельно ексельник с формулами (можно вообще пойти по пути создания прототипов в каком-нибудь Axure и екселе с формулами на него).
Либо мы можем объединить все мелкие доки в один большой, а писать его в  3 руки в гугл доках (пока всемирное торможение гугл дока не поглотит проект странице к 30-й).

Мы можем подписать только один документ, а у нас их множество
Если руководитель заказчика крайне занятой и высокопоставленный, то однозначно придётся готовить один документ. Тогда, очевидно, это опять ексельник для хранения полей, либо же все формулы и тп будут описаны текстом. При обновлении я бы рекомендовал забыть про слитый док, оставить его заказчику, а сами апдейтить изначальные поделенные документы… Мусолить частями старый документ я не вижу смысла. Есть некоторая проблема – если требуется показать какие именно поля и описания были изменены..
Если заказчик настаивает, что это новый проект и он не хочет подписывать новое ТЗ (постановки на реализацию), а вести только изменения на каждый элемент интерфейса, то тогда, при написании новых документов или правке каждый аналитик будет готовить список новых полей и измененных, а так же новые документы. Потом переносить это в один сводный документ и опять подписывать. Лишняя работа у нас будет по переносу новой информации. Как входной материал можно использовать не весь документ, а сразу браться за доки, которые мы мержили для подписи. Очевидная проблема – как писать формулы, если часть нумерации в старом ТЗ, а часть в новом (лазить туда-сюда и давать ссылки на старый док, чтобы показать заказчику, а потом сносить в общий ексельник, актуальный по системе).
В любом случае, самый лучший вариант – все поля вывести в отдельный Excel-файл, соблюдать там единую нумерацию (с этим не должно быть трудностей), апдейтить маленькие доки, а новые объекты вносить под новыми последующими номерами.

Как ставить
задачи разработчикам

Проще всего указывать один документ (его название) или номер требования в задаче. Эффективно иметь одно файловое хранилище, к которому у разработчиков и тестировщиков будет доступ на чтение, что не потребует каждый раз прикладывать документы к каждой задаче (ещё более неудачно, если один документ имеет ссылки на множество других).
Гораздо хуже, если мы дорабатываем систему – тут либо требуется хранить документы в режиме правки по версиям, либо писать отдельную постановку на изменение. Соображения какие-то такие, если кто-то сможет добавить – буду только рад.

Как преобразовать множество документов в один

Ответ прост – копипастом. Требуется лишь обновить ссылки и нумерацию полей системы протянуть по всему документу (функция “продолжить нумерацию”). Заголовки лучше всего так же делать в форме списка и его так же протянуть по всему документу. Для типов требований удобнее использовать префиксы. Но по данной тематике есть много “классической” литературы.

Автоматизированное решение

Если вы вели требования в Rational RequisitePro (в этом есть ограничения при работе с заказчиком, я это описывал в одном из первых постов своего блога), то есть продукт Rational SoDa, который позволяет “слить” все требования в один документ в автоматическом режиме. При этом у всех требований гарантированно будет уникальный номер. О других решениях я не в курсе.

Вывод
При работе с документом мы можем все вести в одном файле, если над ним работает один аналитик и один заказчик.
Если в проекте множество аналитиков (или несколько заказчиков), то требуется вести множество документов, – тут удобнее выносить все поля в отдельный файл, либо же придётся описывать всю логику и формулы текстом.
Если же требуется демонстрировать ТЗ одним документом, при работе множества аналитиков, то это лучше делать во множестве документов, а потом объединить в один документ.

Advertisements
Standard

2 thoughts on “Требования. Один документ или много?

  1. Pingback: Один документ или много – комментарии. « Блог Алексея Киселева

  2. Alexander Belin says:

    Требования имеют свой жизненный цикл (сорри за банальность), и мне кажется, что для каждого этапа этого жизненного цикла лучше использовать разные документы. Например, на этапе разработки требования, обсуждения и согласования его деталей с заказчиком, представления и обсуждения с разработчиками, лучше работать с каждым требованием отдельно. Формы представления могут быть самые разные: UML диаграммы, Use Cases, просто текстовое описание (User Stories, как частный случай для Agile проектов), документы, содержащие совокупность всего вышеперечисленного: графическое представление и текстовое описание . Но когда наступает момент согласования scope предстоящего релиза (версии), то правильней (с юридической точки зрения) иметь единый документ, содержащий все требования, вошедшие в данный релиз (версию), так называемы baseline, для того, что бы заказчик утвердил все эти требования разом. Этот документ широко известен как Software Requirements Specification (SRS). Вариантов шаблона данного документа существует достаточно большое количество. Классический пример можно посмотреть у Вигерса.
    Очень хороший вариант – это использование автоматизированной системы управления требованиями, например Caliber RM (вы упоминаете Rational RequisitePro), в котором все требования хранятся в едином репозитории, к которому, в свою очередь, допущены как все аналитики, так заказчики, имеющие право обсуждать требования, и выдавать свои замечания, так и разработчики. В этом случае область применении я бумажных документов сильно сужается – вся работа по разработке, согласованию с заказчиками, доведению до разработчиков выполняется в рамках системы управления требованиями. Собственно документ выгружается из такой системы только для выполнения юридического акта «согласования с заказчиком полного набора требований для данного этапа разработки»
    Вообще, вопрос «один документ VS много документов» – это вопрос стандартов, используемых в проекте, пожеланий заказчика, и, если всего этого не заявлено, то вопрос собственного удобства.
    Я вижу, у вас описана достаточно сложная проблема – нумерация полей, формул, перекрестные ссылки между ними и т.д. Я наверное повторюсь, но мое твердое убеждение, что в такой ситуации вам необходимо серьезно задуматься о едином репозитории для требований – системе управления требованиями. Только такая система максимально полно поможет вам решить все эти проблемы: общий доступ для всех заинтересованных лиц, сквозная нумерация, трассировка, хранение истории изменений, обсуждений, возможность формирования Baseline и, наконец, возможность выгрузить любой набор требований в *.doc документ заданного шаблона. Таких систем управления требованиями много, выше я упоминал Caliber RM, с которым мне приходилось работать в одной из компаний.

    Есть опыт работы с документами требований + система ведения проекта (в частности Luxproject) + система BagTracking.

    Если будет интересно обсудить, пишите

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s