Всегда задачался вопросом, работая на стыке БА и СА - писать требования одним документом, или же отдельными постановками, подумал над этим вопросом, мысли записал...
Надеюсь на конструктивную критику
ВведениеНа моей практике я успел поработать в компаниях, которые писали требования как в рамках одного документа, так и в рамках отдельного документа на каждый объект создаваемой системы. В данном случае, под объектом я буду рассматривать один или несколько элементов доменной модели (а это ещё могут быть нефункциональные требования и тп), которые являются в системе либо справочником, либо документом (карточкой, страницей, кто как называет), но не на каждое или группу ФТ (функциональное требование). На основании этого документа ведется разработка и тестирование (в частности), его же подписывает и заказчик.
Один большой документ на всем протяжении проектаИзначально при работе с заказчиком мы собираем требования, формируем ТЗ (которые в моей практике зачастую выглядят как требования разработчикам, так что тут ТЗ=постановки на реализацию), а после чего нам необходимо этот документ подписать.
В каком случае мы можем работать с одним документом? Такая ситуация может возникнуть, если над проектом работает один аналитик, а так же один или множество заказчиков. При работе с множеством заказчиков в одном документе потребуется хорошо планировать работу, чтобы проверку требований и реализации заказчики осуществляли поочередно. Это очень тяжело, так что я всегда вел требования каждого заказчика в отдельном документе, а после согласований их объединял. В данном случае, если заказчиков множество, то придётся распараллелить их работу по согласованию документа, что скажется на сроках проекта.
В написании требований одним документом есть следующие преимущества:
Сквозная нумерация разделов (которая, правда, может поехать при обновлении формул, но ведь гораздо удобнее написать - делай ФТ12.1.13, чем делать ФТ*************** ******* ******** ****** (****** ******)
- Сквозная нумерация полей (и формул), требований в системе.
- Описание формул при помощи ссылок на их уникальные номера. Согласимся, что написать в формуле расчета: 546/32, если 96>12 будет гораздо быстрее, чем писать, что итог =поле *** справочника ***, деленное на поле *** справочника ***, вкладки ***, при условии, что поле *** документа *** больше поля *** справочника ***. И это ещё не самая изощрённая формула...
- Удобство поиска (ищем в одном документе, а не перебираем множество существующих)
Соответственно, при работе с одним заказчиком одного аналитика эффективнее работать в рамках одного документа. Но тут можно заметить, что эти плюсы более существенны при передаче проекта - в одном документе проще ориентироваться при погружении в проект, в то время, как автор, обычно, помнит, где и что написано.
Проблем с обновлением быть не должно - новые поля нужно вносить с уникальным номером (добавлять список ниже), а вообще, лучше вести их в отдельном ексель-файле, а в ТЗ давать только ссылки на номер поля в ексельнике.
Много документов и мы можем эти документы по отдельности подписатьЕсли проект автоматизирует какую-либо большую область, то тут уже требуется работа нескольких аналитиков, особенно, если объемный проект следует выполнить за более короткий срок, чем если его будет вести один аналитик.
Мне, например, гораздо эффективнее и комфортнее работать как минимум в паре, постоянно критикуя каждое требование и идею друг друга, а потом фиксируя решение. При такой организации работы можно осуществлять тестирование требований, обсуждать их и спокойно уходить в отпуск, не боясь звонков и вопросов. Однако работа в команде сразу говорит о том, что у вас не получится писать ТЗ в одном документе.
Значит, такое случается, если аналитиков много, а каждый из них пишет свою часть (либо аналитик не сумел распараллелить заказчиков). Либо одна часть будет равна тому объему работы, который взял на себя аналитик, либо, документ будет реализован на каждую фичу (я так никогда не работал, рассмотрю это в следующий раз), либо на каждый объект в системе. В итоге все это нам подписывает один человек и он согласен на кучу документов.
Подход
Кучу мелких доков писать несколько дольше с той точки зрения, что мы не можем использовать нумерацию полей, либо же потребуется использовать префикс в каждом документе (кстати, читай - интерфейсе), а формула будет выглядеть например так “=БС13/(ПС42 - КОП56)”. Можно писать все текстом, здесь есть плюсы и минусы - с одной стороны, при переименовании поля - не надо его же переименовывать во всех документах, с другой, без открытия дополнительных файлов можно узнать что считает формула, а так же нет трудностей при изменении местоположения поля, если их номера соответствуют порядку отображения (что логично).
Большим минусом могу выделить поиск по документам и необходимость держать в голове все формулы, где используется данное поле, чтобы апдейтить другие документы. Возможно, проблему решит матрица трассировки, но в ней будет мало конкретики, если привязывать документ к документу.
Опять же можно выделить отдельно ексельник с формулами (можно вообще пойти по пути создания прототипов в каком-нибудь Axure и екселе с формулами на него).
Либо мы можем объединить все мелкие доки в один большой, а писать его в 3 руки в гугл доках (пока всемирное торможение гугл дока не поглотит проект странице к 30-й).
Мы можем подписать только один документ, а у нас их множествоЕсли руководитель заказчика крайне занятой и высокопоставленный, то однозначно придётся готовить один документ. Тогда, очевидно, это опять ексельник для хранения полей, либо же все формулы и тп будут описаны текстом. При обновлении я бы рекомендовал забыть про слитый док, оставить его заказчику, а сами апдейтить изначальные поделенные документы... Мусолить частями старый документ я не вижу смысла. Есть некоторая проблема - если требуется показать какие именно поля и описания были изменены..
Если заказчик настаивает, что это новый проект и он не хочет подписывать новое ТЗ (постановки на реализацию), а вести только изменения на каждый элемент интерфейса, то тогда, при написании новых документов или правке каждый аналитик будет готовить список новых полей и измененных, а так же новые документы. Потом переносить это в один сводный документ и опять подписывать. Лишняя работа у нас будет по переносу новой информации. Как входной материал можно использовать не весь документ, а сразу браться за доки, которые мы мержили для подписи. Очевидная проблема - как писать формулы, если часть нумерации в старом ТЗ, а часть в новом (лазить туда-сюда и давать ссылки на старый док, чтобы показать заказчику, а потом сносить в общий ексельник, актуальный по системе).
В любом случае, самый лучший вариант - все поля вывести в отдельный Excel-файл, соблюдать там единую нумерацию (с этим не должно быть трудностей), апдейтить маленькие доки, а новые объекты вносить под новыми последующими номерами.
Просмотр сообщений