Requirement management (rus)

Один документ или много – комментарии.

 

Получил замечательный ответ от пользователя  uml2.ru, Shur в продолжение к своему посту.

…Изначально при работе с заказчиком мы собираем требования, формируем ТЗ (которые в моей практике зачастую выглядят как требования разработчикам, так что тут ТЗ=постановки на реализацию), а после чего нам необходимо этот документ подписать.

Важно различать проблемы:*декомпозиции системы и декомпозиции документа. *совмещения в одном документе описания требований Заказчика и постановок на их реализацию для разработчика. О декомпозицииНаверное, удобно декомпозировать документ по составляющим элементам (не уточняю пока, что под этим имею в виду) системы: каждому элементу – свой  документ с описанием требований. Тогда выбирая способ декомпозиции системы на элементы, вы выбираете и способ декомпозиции по документам. Возможно, объединяя некоторые (или все) документы в один. Проблема в том, что разные методологии исходят из разных моделей, подразумевающих разные методологии декомпозиции систем.Техническое задание по ГОСТ подразумевают один вид моделей системы, RUP – другую. ГОСТ предполагает декомпозицию системы на подсистемы, которые могут снова декомпозироваться на подсистемы. Предполагается также, что можно сформулировать требования к функциям (результатам работы) системы и описать как функции системы декомпозируются на функции подсистем. Такое верхнеуровневое описание должно объяснять (Заказчику обязательно) каким образом через функциональное взаимодействие подсистем будет получен результат работы (выполняться функции и задачи) системы в целом. Если подсистем нет – то как декомпозиция функций системы на задачи (комплексы задач) обеспечивает достижение необходимого результата. Описание декомпозиции системы на подсистемы и функций на задачи должна давать представление о системе, которое является основой для формулировки требований и составления ТЗ.  Попытка описать в рамках ГОСТ систему, реализуемую в объектной модели,  вынуждает пускаться в достаточно вольные интерпретации требований ГОСТ, “натягивать” объектные представления на IDEF0-образные функциональные модели, изобретать способы отражения различных уровней представления системы в документах, для этого не приспособленных.Касательно совмещения требований и постановок: если Заказчик требует ТЗ по ГОСТ, то стоит ли описывать в ТЗ детали реализации, которые важны разработчикам, но не очень важны Заказчику (полагая, что Заказчику нужен результат – выход функции)? О декомпозиции при объектном подходеИсторически так сложилось, что бизнес, как правило, мыслит в терминах функциональной модели, а разработка ведется в объектных подходах. Ориентированные на RUP и UML методологии (см.например, G.Overgaard, UML blueprints),  предполагают декомпозицию системы, прежде всего по вариантам использования. Декомпозиция по документам для Заказчика, по идее, может идти по вариантам использования. Но опять же, пока мы описываем систему в терминах вариантов использования. Если же мы начинаем рисовать диаграмму классов системы, причем на уровне, необходимом разработчикам системы, то её декомпозиция (особенно по вариантам использования) и поддержание её в консистентом и актуальном виде представляется вообще весьма трудоемкой и даже проблематичной задачей. Опять же касательно совмещения требований и постановок:Стоит ли включать детальные требования в ТЗ для Заказчика? Стоит ли вообще пытаться оформлять детальные требования (постановки) в рамках объектного подхода в виде официального документа – ведь не на зря были предложены Agile-подходы Улыбающийся?

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

А вы пробовали рассылать документ одновременно на согласование разным заказчикам (распараллеливать)? Хотя бы в электронном виде?  Если речь идет о согласовании с Заказчиками – специалистами различных подразделений, то, они же, как правило, смотрят документ под разными углами зрения и “технически” свести их требования в одном документе, как правило, можно очень быстро. Если этапу согласования требований предшествовал этап сбора требований, то чем качественнее удалось выявить требования при обсуждении с заказчиками, тем меньше должно быть проблем при согласовании.
И опять же вопрос – насколько детально нужно описывать реализацию, чтобы её проверял Заказчик?

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

Если система декомпозирована на взаимодействующие элементы и каждый аналитик отвечает за требования к элементу (компоненту, ВИ, фиче) то “взаимодействие” аналитиков (возможно, с перекрытием зон ответственности) неизбежно, хотя описанное Вами полное дублирование функций вряд ли разумно с точки зрения затрат на проект.

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

В описанной ситуации угадывается практика ведения документов по ГОСТ в режиме изменения. Если у Вас поехала нумерация (даже страниц) заменяете весь текст начиная с первого изменения в режиме “Лист 23-54 заменить на прилагаемые листы 23-54” “Добавить новые листы 55-57” если количество листов увеличилось или “Изъять листы 55-57”, если количество листов уменьшилось. Описываете это в извещении на изменении (Excel ГОСТом не предусмотрен:) с общим указанием, что именно изменили в документе (3-5 предложений).

Номер страницы такой же важный параметр документа, как и номер формулы. Если у Вас в листе хоть что-то изменилось, да еще если в тексте есть ссылки на номер страницы, рисунка формулы и хоть какой-то номер сместился – заменяйте все страницы (по крайней мере до начала очередного раздела), не мучайтесь Улыбающийся.

 

Advertisements
Standard

One thought on “Один документ или много – комментарии.

  1. А что рассчитывалось по этим формулам? Если, например, доходность компании или чистая приведенная стоимость, рассчитанная методом дисконтированных потоков, то эти показатели характеризуют бизнес Заказчика независимо от программной реализации их расчета и отображения. Тогда важно зафиксировать необходимость расчета этих показателей уже на уровне бизнес требований, при этом формула расчета этих показателей может быть представлена в Приложении к ТЗ (чтобы не загромождать основной текст).

    Нужно ли указывать в требованиях (ТЗ) в каком поле какой интерфейсной формы эти расчетные показатели должны отображаться? И если да, то не должно ли описание интерфейса с приложением интерфейсных форм отнесено в документы технического проекта (если он документируется по ГОСТ)? У Вас тогда будет время продумать дизайн интерфейса и согласовать его с Заказчиком позже, при утверждении (технической) проектной документации.
    Если же Заказчику важен, например, размер полей печатной формы отчета в зависимости от объема и содержания представленной в отчете информации – то это компетенция СА. Но это, наверное, не Ваш случай?

    Цитата: kas от Февраля 18, 2011, 11:10:16 pm
    А вот про разработку систему от функций я наслышан, но практических примеров не видел.. Нет ничего такого, прочитать или хотя бы на пример посмотреть?

    Вы, наверное, знакомы с методологией SADT, IDEF0? Требования к документам ГОСТ очень удобно воспринимать под углом зрения этой методологии и соответствующей нотации. Единственно, что ГОСТ не выделяет явно входы “управление” и “ресурсы”. Принципиально важно исходить из того, что функция задается описанием входов и выходов (с указанием соответствия выходов выходам). “Задача” по ГОСТ – это функция или часть функции. А документ “Описание постановки задачи” как раз предполагает описание этих входов и выходов, его можно использовать для того, чтобы расписать каждую функцию из ТЗ.

    Если Вы имеете в виду под разработкой реализацию системы в коде, то важно учитывать, что методологию SADT изначально не предполагалось использовать для низкоуровневого описания системы. Авторы самой известной книги по SADT “МЕТОДОЛОГИЯ СТРУКТУРНОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ” Дэвид А. Марка и Клемент МакГоуэн писали во введении к книге:

    “Под названием IDEFO SADT применялась тысячами специалистов в военных и промышленных организациях. В коммерческом мире SADT используется для определения требований. В этом качестве она конкурирует с методами, ориентированными на потоки данных, – структурного проектирования Е.Иордана, структурного анализа Т.ДеМарко, структурного системного анализа С. Гейна и Т. Сарсона, а также с методами структуризации данных -методами М.Джексона, Лж.Д. Варнира и К. Орра. В отличие от этих методов структурного анализа, истоки которых нужно искать в проектировании программного обеспечения, SADT создана для описания системы и ее среды до определения требований к программному обеспечению или к чему-либо другому. Иными словами, поставив своей целью описание системы в общем, создатели SADT изобрели графический языки набор процедур анализа для понимания системы прежде, чем можно представить себе ее воплощение. Таким образом, SADT, как правило, применяется на ранних этапах процесса создания системы, который часто называют “жизненным циклом системы”, и иногда за этим следует применение упомянутых выше методов.”

    Поскольку методология SADT создавалась в 60-80-е годы и предназначалась для описания системы на бизнес-уровне, она не учитывает особенности современных средств программной реализации. ГОСТ 34 (да и ГОСТ 19) – стандарты эпохи SADT, в силу этого не очень приспособлены, да, видимо, и не предназначались для описания детальных требований к программной реализации (разработке) системы, что может создавать проблемы при проектировании системы с использованием SADT.

    Например, IDEF0 предполагает, что выход и выход системы – это “данные”, “сигналы”. Причем на выходе и выходе – разные данные. Если же (на бизнес уровне) на входе и выходе одни и те же объекты (системный уровень), но в разных состояниях, то получается скорее диаграмма состояний, которую лучше тогда рисовать с использованием соответствующей нотации (например, в UML).
    Описание с помощью ВИ функциональных требований к системе, разрабатываемой в объектной парадигме, проблемы такого рода снимает, поскольку концепция use cases развивалсь в рамках ООП и акцентирует ИМХО скорее процесс, алгоритм, а не входы и выходы (с оговоркой важности указания предусловия и постусловия ВИ и наличия полезного для пользователя результата ВИ).

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