Требования к автоматизированной системе. Формализм - блажь или осознанная необходимость?

(Часть I) Сергей Длужневский,
Руководитель аналитической службы
компании «Vested Development Inc.»

"Помилуйте, -
уверенно ответил человек, -
как же так, без документа?"

Михаил Булгаков. "Собачье сердце"

Зачем и как нужно разрабатывать требования к автоматизированной системе?

Ответ на этот вопрос, столь очевидный для одних, является совершенно неочевидным для других. Особенно для тех, кто по роду своей деятельности достаточно далек от всего того, что именуется IT-индустрией. А ведь именно таким людям и приходится порой принимать самое активное участие в разработке этих требований - как представителям класса бизнес-пользователей будущей системы.

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

  Я запланировал подготовить несколько статей на тему разработки требований к системе.

Статей, рассчитанных в чем-то на бизнес-пользователей, в чем-то на разрабатывающих эти требования аналитиков. На тех, кто волей случая (или руководства) оказались втянутыми в процесс разработки требований, и на тех, кто над этими требования работает по долгу службы. Я думаю, что и тем и другим будет небезынтересно ознакомиться с моими рассуждениями (по крайней мере, хочу надеяться, что это будет так). Насколько мне удастся воплотить этот маленький проект в жизнь - сама же жизнь и покажет. Надеюсь, что удастся. Потому что в ходе моей работы консультантом, аналитиком, руководителем проектов и прочее, мне (да и не только мне) приходилось столько раз \"наступать на различные грабли\", что если хотя бы одному человеку удастся какие-то из этих \"граблей\" миновать, прочитав этот материал, я буду считать, что поставленной цели достиг.

К сожалению, данная тема весьма и весьма обширна, а пространство, отведенное мне, существенно меньше. Поэтому я постараюсь излагать основные тезисы, а более пространные размышления оставить до какого-нибудь следующего раза. Сразу хочу оговориться. Я не настаиваю на догматичности написанного, а лишь высказываю собственную точку зрения. Правда, подкрепленную определенным опытом работы в этой области. Но не более того. Искренне уважая альтернативные мнения, я всегда готов обсудить с желающими эту тему.

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

Следует отметить, что все приведенные примеры взяты из жизни, несмотря на кажущуюся абсурдность некоторых из них. Работа "по жизни" и работа "как в книжке" отличаются, и порой очень сильно. Написать этот короткий комментарий меня сподвиг недавний разговор с одним специалистом, с которым я проводил собеседование при приеме на работу. Я смоделировал ему очень нехорошую ситуацию, возникшую на проекте, и спросил, как он собирается из нее выкручиваться. В ответ услышал, что таких ситуаций быть не может, потому что это неправильно, противоречит тому, как все должно быть и вообще, таких ситуаций у него еще не было. Тем не менее, ситуация была реальной, и имела место на одном из проектов, в котором мне довелось участвовать. А человек оказался не готов к такому повороту событий.

Кому-то может показаться, что в своих примерах я, как это сейчас говорится, "наезжаю" на заказчика, пытаюсь выставить его неким отрицательным персонажем. Это не так. Я сознательно подобрал примеры, в которых имел место конфликт. Точно так же, я мог привести массу примеров, иллюстрирующих успешные проекты. Но поскольку цель статьи - показать, что произойдет, если пренебречь определенными формальностями и пустить все на самотек, то и примеры были подобраны соответствующие.

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

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

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

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

Пример из практики.

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

Причем, в некоторых случаях, речь шла о действительно принципиальных вещах.

Разработчик, тестировавший совместно с ними функциональность системы, был хорошим, грамотным специалистом. Он провел несколько встреч с представителями бизнеса и в итоге полностью прояснил для себя, что хотят пользователи, и как это можно реализовать в системе. И пообещал, что это будет сделано. Только вот одно \"но\". Их договоренности не были нигде и ни в каком виде зафиксированы.
Разработчик этого не сделал, потому что не привык. А заказчик попросту не подумал об этом, удовлетворившись данным ему обещанием.

Вернувшись из командировки, этот разработчик действительно начал воплощать в жизнь данное обещание. Но, как это обычно бывает, постепенно стали наваливаться другие, более приоритетные, задачи, и реализация обещанного стала отходить на второй план. А потом ему предложили более выгодную работу, и он уволился. Через некоторое время подошла пора сдавать проект.

И вот тут-то и всплыли описанные выше, нигде не зафиксированные, договоренности. Заказчик наотрез отказался принимать систему без необходимого ему функционала. А компания, производившая разработку, отказалась этот функционал реализовывать. Поскольку ни сроки, ни стоимость этих работ не были заложены в бюджет проекта. Начались глобальные выяснения отношений, длившиеся несколько месяцев. В итоге, проект все же был сдан. Но со значительными финансовыми и нервными потерями как с одной, так и с другой стороны.

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

Разработка требований является довольно трудоемким процессом, в реализацию которого вовлечены специалисты как со стороны заказчика, так и со стороны исполнителя системы. Это схематично представлено на Рисунке 1.

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

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

Вообще, строго говоря, на этапе разработки требований надо стараться документировать все, что возможно и что имеет отношение к решаемой задаче. Результаты интервью, совещаний, переговоров, промежуточные договоренности - все это может послужить бесценным источником информации, которая при неаккуратном обращении может быть безвозвратно утеряна. К сожалению, зачастую представители бизнеса неверно истолковывают желание аналитиков максимально педантично фиксировать, перепроверять и согласовывать полученную информацию, считают это излишним формализмом.

А между тем, даже словосочетание \"требования к системе\" разные категории приведенных выше участников процесса понимают по-разному. Так, для разработчика это часто скорее технические требования, частично определяющие, как это будет реализовано, тогда как для бизнес-пользователей заказчика это скорее совокупность задач (рассматриваемая в контексте бизнес-процессов деятельности компании), которые система должна выполнять. Поэтому крайне важно перед началом процесса разработки требований договориться о содержании итогового документа (документов), форме представления информации и порядке согласования и утверждения. И не просто договориться, а заключить формальное соглашение на эту тему, которое было бы утверждено и обязательно к исполнению всеми для всех участников проекта.

К структуре и содержанию документа требований я планирую вернуться позже, в отдельной статье, посвященной именно этой теме.

Требования к автоматизированной системе.
Формализм - блажь или осознанная необходимость?
(Часть II)Сергей Длужневский,
Руководитель аналитической службы
компании «Vested Development Inc.»

Пример из практики.

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

При попытке объяснить это заказчику, от него был получен ответ, что состав и количество выходных документов формально оговорены не были, а, следовательно, он может требовать то, что ему нужно. Сроки окончания проекта он также переносить не желает, поскольку они уже были утверждены и подписаны с двух сторон. Имело место непродолжительное выяснение отношений. Не желая портить отношения с заказчиком, руководство исполнителя приняло решение выполнять эту работу сверхурочно. За счет компании-исполнителя и личного времени аналитика, работающего на проекте. Проект был успешно завершен, но и у заказчика и у исполнителя остался легкий осадок от совместной работы. Аналитик, проведший несколько бессонных ночей за клавиатурой, естественно, в восторге также не был…

Помимо непонимания сути происходящего, существуют и другие причины, заставляющие некоторых бизнес-пользователей с опаской относиться к методам работы, используемым аналитиками.

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

Однако зачастую представители заказчика просто отказываются говорить, узнав, что разговор записывается. Или требуют не включать диктофон. Отказываются из-за боязни, что их слова могут прозвучать недостаточно компетентно, что начальство может обвинить их в непрофессионализме, услышав записанное. Или из-за того, что диктофонная запись может быть использована против них самих каким-либо еще образом.

Это заблуждение необходимо развеивать максимально быстро и эффективно. Во избежание возникновения препятствий в работе. Необходимо объяснять людям, с которыми приходится общаться, причины, которыми руководствуется аналитик, ведя аудиозапись разговора или обсуждения. Они должны понять, что никто не собирается компрометировать их этим материалом. Наоборот, что целью является получить как можно больший КПД от одной встречи, тем самым, снижая вероятность проведения повторных обсуждений и, как следствие, уменьшая трудозатраты со стороны заказчика.

Сделать это можно по-разному. Начиная от личного 5-10-минутного мини-семинара с каждым интервьюируемым сотрудником компании заказчика, и заканчивая изданием распорядительного документа на уровне всей компании, регламентирующего процесс взаимодействия между специалистами заказчика и исполнителя на период разработки требований к системе. Зависит от объема, сложности, политической ситуации и т.д. каждого конкретного проекта. Универсального рецепта здесь нет.

Не стану кривить душой и говорить, что такие аудиозаписи не могут применяться в качестве инструмента давления. Могут. И более того, применяются. Однако этого стараются избегать и прибегают только в самых крайних случаях. Поскольку такое поведение всегда неразрывно связано с осложнением отношений между заказчиком и исполнителем. А осложнение отношений никому не нужно. Но уж если случилось… Если вышло так, что заказчик, как говорится «на голубом глазу», заявляет, что он «такого не говорил, все это выдумки», обвиняет во всем непрофессионализм исполнителя, тогда приходится предъявлять запись разговора, как некое вещественное доказательство.

Хотя не исключены случаи, когда люди действительно забывают, что они говорили несколько месяцев назад. В этом случае, прослушивание аудиозаписи поможет восстановить в памяти старый разговор. Но это, конечно, не имеет к давлению никакого отношения.

Хочется сказать отдельно несколько слов по поводу переписки посредством электронных средств коммуникации - e-mail, MSN , ICQ и им подобных. В настоящее время такой способ общения очень распространен, и не случайно. Удобно, быстро, оперативно. Позволяет исполнителю работать, находясь за тысячи километров от заказчика и не чувствовать этого расстояния. Позволяет обмениваться мгновенными сообщениями, передавать файлы, устраивать целые конференции. В общем, можно было бы сказать, что использование этих программ существенно упростило жизнь при работе над проектами (остальных сфер использования вышеуказанных продуктов я сейчас не касаюсь), если бы не одно «но». А именно, очень часто посредством электронной почты (или других средств электронной коммуникации) решаются вопросы, которые решаться таким способом не должны в принципе. В данном конкретном случае я говорю о ситуации, когда после подписания документа требований заказчик по каким-то причинам принимает решение об изменении (добавлении, удалении) требований. Эта процедура должна оформляться в соответствии с довольно жестко прописанным регламентом управления изменением требований, который учитывает все возможные нюансы влияния этого события на проект в целом. Если же этим пренебречь, то можно получить ситуацию, которая описана в примере.

Пример из практики.

При разработке сложной автоматизированной системы заказчик пожелал определенным образом изменить функциональность одной из подсистем (по сравнению с той, которая была приведена в постановочных документах). Об этом он сообщил разработчикам письмом, направленным по электронной почте. Разработчики задали уточняющие вопросы. Так же, посредством e-mail. Завязалась переписка. В конце концов, все вопросы были улажены, заказчик еще раз прислал письмо, с более четкой постановкой задачи. Началась работа.

Спустя некоторое время, во время опытной эксплуатации системы, заказчик заявил, что функционал, о котором говорилось выше, «не соответствует заявленному». Начали разбираться. Выяснили, что то, что хочет заказчик, соответствует тому, что написано в документе требований. Тогда стали вспоминать, на основании чего реализовали не так. Подняли переписку. Нашли то самое письмо с финальной постановкой задачи. Продемонстрировали заказчику. В ответ получили формулировку: «У нас есть подписанный документ, а рабочая переписка документом не является. Поэтому, вы не должны были на ее основании проводить разработку». Вот так. Некоторое время спустя выяснилось причина такого поведения. Дело в том, что бизнес-процессы заказчика не были до конца отлажены, постоянно проводилось их изменение. На момент постановки задачи было одно видение, потом эта позиция была пересмотрена, так родилось злополучное письмо. А впоследствии, заказчик все-таки решил вернуться к первоначальной схеме работы.

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


Несколько слов по поводу подписи.

Основное назначение подписи на стадии разработки требований - заставить собеседника мобилизоваться. Зная, что ему придется подписываться под своими словами, представитель бизнеса будет более внимателен и собран при проведении совещания или интервью. Также, он будет более внимателен при проверке тех материалов, которые ему предоставляют для согласования. Помимо этого, наличие подписи свидетельствует о том, что информация, под которой эта подпись присутствует, является верной и актуальной на момент подписания. Некий срез на текущий момент времени. Нельзя рассматривать подпись клиента под какими-либо сформулированными требованиями, как нечто незыблемое. Как говорится, «на века». Жизнь меняется, меняется бизнес, меняются и требования. Поэтому заказчик системы имеет законную возможность внесения изменений в эти самые требования тогда, когда у него появится в этом необходимость. Другое дело, что процессом этих изменений надо грамотно и четко управлять. Но это, как я уже говорил, тема отдельной статьи.

  Касательно применения подписи в качестве инструмента давления на заказчика можно сказать ровно то же самое, что говорилось об аудиозаписях.

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

Процесс управления требованиями заслуживает отдельного рассмотрения. Здесь мы коснулись его поверхностно.


Для успешного выполнения работ требуется:
Организация рабочей группы, в которую будут включены эксперты предметной области, обладающие достаточными знаниями и навыками в соответствующих областях описываемой функциональности.
Однозначное понимание всеми членами рабочей группы целей создания информационной системы.
Осознание членами рабочей группы важности проводимых мероприятий и четкое ориентирование на конечный результат.
Рабочая группа должна разработать соглашения, определяющие:
полномочия членов группы;
шаблоны документов, разрабатываемых в ходе проектирования требований;
порядок взаимодействия между заказчиком и исполнителем;
регламент согласования документов, разрабатываемых в ходе проектирования требований (включая состав согласующих и утверждающих лиц, временные ограничения на задержку документа у согласующего лица).


Выделение одного или нескольких ответственных за результаты работы, в функции которых будут входить: координация взаимодействия специалистов Исполнителя с членами рабочей группы; решение потенциально возможных организационных и коммуникационных проблем; визирование промежуточных результатов работы, а также согласование и утверждение конечного документа.

  Своевременное предоставление (в оговоренный срок) ответов на вопросы специалистов Исполнителя. Нарушение этого правила, с большой долей вероятности, приведет к «простаиванию» специалистов Исполнителя, что повлечет, в свою очередь, увеличение сроков и стоимости проекта.

  Все рабочие встречи, обсуждения, совещания, а также телефонные переговоры должны записываться на диктофон.

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

  Любые изменения в части требований к системе, влияющие на сроки и стоимость разработки системы, должны быть в обязательном порядке формализованы и согласованы между Исполнителем и Заказчиком.

Требования к автоматизированной системе.
Структура и содержание документа
(Часть I)Сергей Длужневский,
Руководитель аналитической службы
компании "Vested Development Inc."


Вступление

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

  В существующем многообразии различных методов, стандартов и шаблонов (федеральных, корпоративных и частных) аналитик, работающий над документом требований, зачастую не видит глубинной сути того, на какие вопросы должен отвечать этот документ, а лишь слепо следует предложенной схеме. Говоря другими словами, если есть определенный раздел в предложенном шаблоне, то его надо заполнить соответствующей информацией. А каково предназначение этой информации, и как она будет использоваться в дальнейшем (и будет ли использоваться вообще, или это пишется, потому что \"так надо\"; потому что кто-то когда-то так решил), лучше не задумываться. При этом аналитик, как правило забывает, что шаблон документа, предлагаемый конкретными стандартами и методологиями, является рекомендацией, построенной на основе положительного опыта определенной группы людей. В чем-то я, конечно, утрирую, но, к сожалению, часто мне приходилось сталкиваться именно с таким подходом.

Я не ставлю цели подвергнуть критике какие-то конкретные форматы представления требований к автоматизированной системе. Тем более, что, в большинстве своем, эти форматы были неоднократно опробованы, что называется, \"в бою\", и в случае получения отрицательного результата, как правило, корректировались.

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

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

При написании данной статьи я сознательно "забыл" все известные мне шаблоны и структуры представления требований. Возможно, кто-то, прочитав этот материал, скажет: да вот же, структура точь-в-точь такая, как описано в стандарте "ХХ". Ну и хорошо. Зато теперь этот человек будет не слепо следовать стандарту "ХХ", а понимать, что стоит за каждой строчкой требований этого стандарта. Ведь применение стандартов, как и любой рекомендации, дает положительный эффект только при определенной адаптации к условиям своего применения.

Кому-то материал, изложенный здесь, может показаться неинтересным, кому-то – настолько очевидным, что он пожалеет о потраченном на прочтение статьи времени. Так бывает всегда. Я, в первую очередь, ориентировался на тех, кто только делает первые шаги в области постановки задачи на автоматизацию. Тех, кто работает давно, но волею обстоятельств не имел возможности задуматься над вопросами, рассматриваемыми здесь. А также тех, кто не разрабатывает требования к автоматизированной системе, а читает, согласовывает и утверждает их, т.е., людей, заинтересованных в успешной реализации продукта (руководителей проекта, представителей заказчика).

Теперь, после такой, не очень короткой, вступительной части, перейдем непосредственно к рассмотрению вопроса.
Несколько слов о терминах

Обилие существующих методик разработки документа требований порождает обилие терминов, в них использующееся. И, как следствие, часто возникают ситуации, когда люди, говоря об одном и том же, используют разные названия. И, естественно, плохо понимают друг друга.

Самый, пожалуй, классический пример на сегодняшний день, это термин "Техническое задание".

Чего только под этим не подразумевается на разных проектах. Начиная от простейшего верхнеуровнего описания функциональности системы (что-то, вроде требований пользователя) и заканчивая мощнейшим документом, описывающим не только все возможные требования к системе, но также и аппаратно-программную среду реализации, подробное описание архитектуры, проработанную схему БД, полностью расписанный UI (интерфейс пользователя), и еще много чего. Несомненно, что любой из этих вариантов (равно, как и все промежуточные) имеют право на существование. Я лишь хочу подчеркнуть, что, разговаривая о разработке документа требований (или технического задания) необходимо, чтобы все стороны, принимающие участие в разговоре, понимали предмет разговора одинаково. Это позволит в дальнейшем избежать разочарований при получении результата.

Дело в том, что понятие "Техническое задание" подразумевает вполне конкретный документ со структурой, определенной действующими стандартами. Причем, как показывает мой опыт (и опыт моих коллег), использование этого документа в большинстве случаев не позволяет добиться одной из основных целей, ради которой разрабатываются требования – сформировать единое представление системы и разработчиками, и заказчиком.

Поэтому так сложилось, что в своей работе я использую термины "требования к системе", "документ требований", "спецификация требований". В этой статье я употребляю именно эти термины.

Есть еще примеры использования различных терминов при подготовке документа требований. О них мы поговорим немного позже.
Место и роль документа требований в общем процессе разработки автоматизированной системы

Прежде, чем разбирать подробно непосредственно сам документ требований я хочу коротко рассмотреть место и роль этого документа во всем процессе разработки программного обеспечения (ПО).

Жизненный цикл разработки ПО в упрощенном виде выглядит так, как это представлено на Рисунке 1.

Рисунок 1. Упрощенное представление жизненного цикла разработки ПО

  Жизненный цикл (ЖЦ) включает в себя фазы создания программного обеспечения, каждая из которых может выполняться итерационно. Кроме того, сам жизненный цикл не является строго линейным, поскольку существует довольно большое количество обратных связей, влияющих на весь ход проекта.

Кроме основных процессов ЖЦ, представленных на рисунке, существуют так называемые процессы управления, поддерживающие и сопровождающие весь цикл разработки ПО: управление требованиями, управления проектом в целом, конфигурационное управление, управление рисками и т.д. Однако эти процессы находятся за пределами рассматриваемой нами темы, поэтому их мы сознательно игнорируем.
  Из Рисунка 1 явно видно, что разработка требований является отправной точкой всего процесса создания программного обеспечения. Действительно, имея на входе концептуальное представление о продукте, на выходе аналитической фазы проектная команда получает документ требований, описывающий продукт настолько детально, как это необходимо для дальнейшего проектирования ПО.

Таким образом, документ требований представляется своеобразным "корнем" и порождает целое дерево других проектных документов (Рисунок 2). Рисунок 2. Дерево проектных документов Исходя из этого можно утверждать, что качественно разработанный документ требований позволит избежать ненужных переделок уже готовой системы, снизить стоимость и скорость непосредственно разработки и тестирования, не допустить расползания границ проекта и, наконец, добиться большей удовлетворенности заказчиков. Верхнеуровневая структура документа требований Верхнеуровневая структура документа требований (Рисунок 3). определяется структурой требований, выявление которых является необходимым условием успешного проектирования автоматизированной системы. Рисунок 3.

Верхнеуровневая структура документа требований к АС Основой для начала определения требований являются цели проекта. Однозначная трактовка целей позволяет сформировать однозначное видение Заказчиком и Разработчиком того эффекта, который будет получен бизнесом Заказчика в результате создания и внедрения проектируемого ПО. Цели проекта служат своего рода точкой зрения заинтересованных сторон на достигнутые в ходе реализации проекта результаты.
Цели не должны восприниматься как банальная отписка, служащая введением в документ.

Цели создания продукта являются основой для определения бизнес-требований к системе ( Business requirements ). Это самый первый, самый верхний уровень документа требований. Бизнес-требования описывают, КАКИМ ОБРАЗОМ разрабатываемая система связана с достижением бизнес-целей организации и ЧТО она должна для этого делать.

Можно сказать, что бизнес-требования являются своего рода задачами, которые должна решать автоматизируемая система для достижения целей своего создания. Как видно из схемы, представленной на Рисунке 1, бизнес-требования определяют функциональные и нефункциональные требования.

На практике может получиться так, что функциональные и нефункциональные требования могут "заходить" за границы бизнес-требований, однако они никогда не должны им противоречить. К функциональным требованиям относится все то, что описывает функциональность системы. Т.е., ЧТО, КАК и КОГДА делает система. А также, КТО принимает в этом участие.

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

Функциональные требования включают в себя, так называемые, требования пользователей и системные требования. Требования пользователей ( Customer requirements ) - это те требования верхнего уровня, которые предъявляют к системе будущие бизнес-пользователи системы. Другими словами, те задачи, которые система должна решать с точки зрения бизнеса Заказчика.

В качестве примера можно привести такие требования, как "Система должна позволять создавать новые договоры", "Система должна позволять менять статус существующего договора", "Система должна позволять создавать новое дополнительное соглашение к существующему договору" и т.д. Еще раз необходимо подчеркнуть, что требования пользователей описывают верхнеуровневую функциональность системы, не вдаваясь в подробности ее технической реализации. Системные требования ( System requirements ) имеют ровно такой же смысл, что и пользовательские требования, с той разницей, что в большей степени продиктованы не потребностями бизнеса, а особенностями IT -инфраструктуры Заказчика. Т.е., это требования, которые определяют регламент взаимодействия создаваемого ПО с внешними системами, регламентируют программно-аппаратные платформы функционирования продукта и т.п.
Например, "Система должна иметь возможность осуществлять автоматический обмен данными с системой учета персонала".

В то время как требования пользователей и системные требования, как правило, отвечают на вопрос: ЧТО должна делать система, то детализированные функциональные требования ( Functional requirements ) отвечают на вопросы: КТО, КАК и КОГДА. Требования этого типа определяются на основе анализа и детального описания процессов, озвученных в требованиях верхнего уровня – пользовательских и системных. Со всеми соответствующими атрибутами – функциями, условиями, событиями, исполнителями, входами и выходами. Т.е., фактически, представляют собой детальное описание реализуемых системой потоков задач и данных. Более подробно обо всех видах требований рассказывается далее.

Требования к автоматизированной системе.

Структура и содержание документа (Часть II)Сергей Длужневский, Руководитель аналитической службы компании \"Vested Development Inc.\" Распределяем ответственность Как уже говорилось в предыдущей статье, разработка требований является процессом, в реализацию которого вовлечены специалисты, как со стороны заказчика, так и со стороны исполнителя системы. Это схематично представлено на Рисунке 4. Рисунок 4.

Основные участники процесса разработки требований Теперь попробуем спроецировать участников процесса разработки требований на приведенную выше верхнеуровневую структуру и, тем самым, получив матрицу соответствия, понять зоны ответственности каждого из участников

№ Тип требований Ответственные Возможные участники 1 Бизнес-требования Менеджмент заказчика Эксперты предметной области Аналитик исполнителя Прочие специалисты исполнителя 2 Требования пользователей Бизнес-пользователи системы со стороны заказчика IT-подразделение заказчика Аналитик исполнителя Менеджмент заказчика Эксперты предметной области Прочие специалисты исполнителя 3 Системные требования IT-подразделение заказчика. Аналитик исполнителя Бизнес-пользователи системы со стороны заказчика. Прочие специалисты исполнителя 4

Функциональные требования Бизнес-пользователи системы со стороны заказчика.

Аналитик исполнителя Менеджмент заказчика. IT-подразделение заказчика. Прочие специалисты исполнителя 5 Нефункциональные требования IT-подразделение заказчика. Аналитик исполнителя. Разработчик исполнителя Бизнес-пользователи системы со стороны заказчика Эта матрица нам понадобится, когда мы будем подробно рассматривать соответствующие разделы документа требований к системе.

Подробная структура документа требований Раздел 1. Назначение документа Раздел "Назначение документа", как правило, включает в себя сведения общего характера, касающиеся разработки системы и, в частности, документа требований. Здесь описывается, что представляет собой данный документ, в связи с чем он разработан и для кого предназначен. Раздел 2.

Цели создания (использования) системы и решаемые задачи (назначение системы) В этот раздел входят сведения, которые описывают существующую технологию, цели и назначение создания системы, а также эффекты от ее внедрения.

По своей сути данный подраздел является бизнес-требованиями ( Business requirements ) к разрабатываемой системе.
2.1. Краткое описание деятельности заказчика и существующей технологии
2.2. Цели создания системы. Эффекты от ее внедрения
2.3. Назначение системы Краткое описание деятельности заказчика и существующей технологии (Описание объекта автоматизации). Деятельность заказчика и существующая технология обычно описываются "естественным" языком. Однако, в случае, когда этого требует специфика проекта (например, была проведена предварительная работа по описанию процессов заказчика AS IS ) можно, и даже нужно дополнять текстовое описание графическими моделями. Это поможет команде разработчиков более грамотно ориентироваться в существующем бизнесе заказчика и глубже понять его потребности.

Вообще, традиционно считается, что связующим мостом между заказчиком и разработчиками при разработке автоматизированной системы является аналитик, и именно он, и только он, должен вникать в тонкости деятельности заказчика. И зачастую разработчики не удосуживаются разобраться в области, которую они автоматизируют.

Однако практика показывает, что на тех проектах, где разработчики не ограничиваются только непосредственно требованиями, а пытаются разобраться, а как, собственно, устроен сам бизнес, вероятность успеха более высокая.
В некоторых случаях данный подраздел стоит вынести отдельным разделом и вставить туда оценку текущего состояния автоматизации, если на ее средства необходимо будет опираться. В этом разделе может также приводиться описание оргструктуры и процессов заказчика. Описывается контекст применения системы.
Цели создания системы. Эффекты от ее внедрения. Цели создания системы показывают, каким именно образом внедрение системы повлияет положительно на бизнес заказчика. Любая работа начинается с того, что формулируется цель выполнения этой самой работы.

Далее, согласно цели, разрабатывается последовательность шагов (задач), которая должна привести к достижению этой самой цели. При определении формулировок целей желательно, чтобы цель отвечала критериям SMART. Т.е., была конкретной (S), измеримой (M), достижимой (A), релевантной (R) и имела сроки исполнения (T). Иначе говоря, для того, чтобы определить, достиг ли проект своей цели, необходимо формулировать конкретные и измеримые цели, имеющие непосредственное отношение к решаемой проблеме и достижимые в определенные отрезки времени.

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

Например, "уменьшить расходы на обслуживание бизнес-процесса на 10% после внедрения системы по сравнению с текущими показателями (данные берутся из квартальных отчетов)", "увеличить количество обрабатываемых документов с 20 до 50 в день в течение первых 6 месяцев эксплуатации системы" и т.д. Приведенные расчеты должны быть выполнены еще на этапе подготовки к проекту, и являться основанием для принятия решения об автоматизации.
Наличие подобных расчетов показывает серьезность подхода заказчика к разработке АС и позволяет избежать многих рисков, свойственных проектам подобного рода. Может так случиться, что разработка системы обойдется дороже, чем ожидаемый эффект от ее внедрения. Не все изменения после внедрения системы можно описать "числовым" языком.

Но все же к этому надо стремиться. Цели системы имеет смысл описывать как "естественным" языком, так и представлять в виде графической модели (например, Дерева целей ( Objective diagram ) программы ARIS Toolset ( IDS Scheer AG)). Такое представление упрощает восприятие текстовой информации (пример такого дерева приведен на Рисунке 5). Рисунок 5.

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

При этом должны быть определены как автоматизируемые бизнес-процессы, так и задачи, выполнение которых должна обеспечивать проектируемая система для автоматизации перечисленных процессов. Таким образом, назначение системы довольно точно определяет границы проекта. Представленная в данном разделе функциональность АС является верхнеуровневой. Например: Система предназначена для автоматизации процессов планирования и исполнения бюджета, мониторинга и анализа финансовых показателей.

Система обеспечивает автоматизацию сбора, обработки, хранения и формирования данных, а также обеспечивает информационную поддержку следующих процессов: ... ... ... Объектами автоматизации являются: ... ... Подробный перечень автоматизируемых функций системы, обеспечивающих реализацию ее назначения, приводится в разделе "Функциональность системы".

Хочется отметить, что те позиции, которые относятся к категории бизнес-требований, должны быть сформулированы со стороны менеджмента компании-заказчика. Говоря другими словами, заказчик должен четко понимать, для чего ему нужна система, как он собирается ей пользоваться, и какие положительные результаты он от этого получит.
Данное понимание совершенно не зависит от личности компании-исполнителя. Поэтому, когда процесс разработки требований начнется, ответы на все эти вопросы уже должны присутствовать.

В матрице соответствия, приведенной выше, как раз менеджмент заказчика выделен ответственным за формулирование бизнес-требований. Раздел 3. Используемые документы В данном разделе перечисляются все документы, которые должны использоваться для создания системы.
Используемые документы могут быть разделены на две категории: основание для разработки – документы, являющиеся основанием для разработки системы; нормативные документы.

В качестве основания для разработки указываются контрактные документы, документы, описывающие концепцию реализации системы, высокоуровневые документы требований (если разрабатывается подсистема) и прочие документы, являющиеся основанием для создания системы.

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

Раздел 4. Термины, определения и сокращения Термины, определения и сокращения. Любая предметная область имеет свои специфические термины.
Данный подраздел предназначен для того, чтобы люди, которые не знакомы с предметной областью, смогли прочитать документ и понять, о чем в нем говорится. Сюда относят все термины (определения, сокращения), свойственные только рассматриваемой предметной области или общеупотребительные термины, которые в данном документе имеют иной смысл, нежели обычно.

В качестве примера можно привести аббревиатуру "ЦБ", которую можно трактовать, как \"Центральный банк\" или как \"ценные бумаги\". Практика показывает, что, как правило, к этому разделу подходят, что называется, "спустя рукава".
Раздел есть, значит надо его наполнить контентом.

Каким, и какого качества – неважно.

Тем не менее, мне неоднократно приходилось сталкиваться, что такой подход к описанию используемой терминологии приводил к значительной потере времени, когда разработчики или тестировщики не могли понять, о чем идет речь в документе.

Другой пример – это когда в середине проекта меняется аналитик, работающий над документом. И чтобы разобраться в том, что написал его предшественник (если данная предметная область совершенно незнакома), новичку требуются значительные усилия.

Как известно, многие термины порой трактуются по-разному.

Поэтому желательно при введении терминов и определений указывать, из каких нормативных документов они взяты (т.е. ссылаться на документы, перечисленные в разделе 3 документа требований).

дата: 00.00.0000 00:00:00 просмотров: 4530

рейтинг:

(Голосов: 2, Рейтинг: 3)