Управление требованиями – один из основных процессов, от которых зависит эффективность внедрения или разработки любой информационной системы, ведь наибольшие риски проектов связаны с высокой изменчивостью требований и ошибками в их определении. Однако на практике, в большинстве проектов об этой дисциплине многие забывают, что часто приводит к провалу проектов. Организация управления требованиями в первую очередь направлена на снижение рисков несоответствия полученных результатов текущим требованиям, причем основой для этого является множество международных и отечественных стандартов. Чего хочет заказчик часто сложно узнать из-за разницы в терминологии и частых изменений. Кажется, обо всем заранее договорились, но при показе прототипа информационной системы вдруг оказывается, что есть серьезные несовпадения, и в результате, становится понятно, что разработано совсем не то, что было необходимо. Таким образом, обе стороны неудовлетворены друг другом и продолжение работ ставится под угрозу. К сожалению, этот результат можно часто встретить в практике российских специалистов. Чтобы минимизировать такие риски, управление требованиями необходимо начинать уже на этапе выбора информационной системы. И здесь, ключевым является участие в данном процессе специалистов от бизнеса, иначе ИТ- директор может выбрать себе информационную систему, которая будет лучше других работать на его оборудовании и доставлять меньше хлопот его специалистам, в то время как для бизнеса она будет скорее помехой, чем инструментом. Такие случаи на практике встречаются достаточно часто. Например, в компании существует информационная система, которая росла эволюционно, и вдруг на верхнем уровне принимается «стратегическое» решение эту систему заменить. В результате долгого проекта внедрения ,выясняется, что новая система не так хороша, как ее рекламировали, и теперь в компании становится две дублирующих системы. Поэтому после такой автоматизации эффективность деятельности может снизиться, и в этом случае явная ошибка заключается в неправильном сборе требований и их анализе при принятии решения о замене информационной системы. Для того чтобы таких «казусов» не происходило, необходимо отстроить в компании процесс управления требованиями. На практике это сделать достаточно просто, для начала нужно создать процедуру их сбора. В качестве источников требований необходимо определение ключевых пользователей от бизнес- подразделений. В результате этого появится список ответственных от каждого подразделения, которые будут формировать новые требования к автоматизации, при этом процедурно необходимо установить регламентные сроки сбора требований, например один раз в месяц. Формируя перечень требований необходимо сразу задуматься о его ранжировании. И в первую очередь здесь можно отталкиваться от критичности бизнес-процессов, которые будут поддержаны соответствующими требованиями. Выстроив систему приоритетов для процессов можно легко их транслировать на требования, тогда будет намного проще обеспечить их ранжирование с точки зрения критичности выполнения. Имея набор требований с учетом приоритетов можно их классифицировать по различным группам: функциональные, стоимостные, технические, к поставщику и т.д. При этом основное внимание необходимо уделить функциональным требованиям. Выстраивая функциональные требования в разрезе основных модулей информационной системы можно определить основные требования к целевой системе, которая должна быть внедрена в компании. Для понимания существующей ситуации, помимо целевых требований необходимо сделать оценку уровня их достижения существующими инструментами. Ведь может быть все в порядке и автоматизации больше не надо? Однако на практике часто бывает, что новые требования бизнеса невозможно реализовать на используемой платформе или их реализация достаточно дорога, и в результате, компания начинает проект по смене информационной системы. При сборе требований есть несколько тонких моментов, ведь их обоснованность должна быть достаточно серьезна, чтобы компания сделала серьезные инвестиции в новую информационную систему. Поэтому на этапе принятия решения о смене системы необходимо взвесить все плюсы и минусы, а также рассчитать экономический эффект от выполнения поставленных требований. После того, как все требования акцептованы и ранжированы, необходимо проследить, как они будут реализованы в создаваемой информационной системе. Именно поэтому требования детализируются, и становятся основой для создаваемого технического задания. Во время выполнения проекта автоматизации необходимо фиксировать степень удовлетворения требований подрядчиком, и когда все требования выполнены можно считать проект законченным. Однако не все так просто, внешняя среда быстро меняется, и пока идет проект автоматизации в большинстве случаев требования уже успели измениться. Именно поэтому необходимо не просто собрать требования, но и организовать процесс управления их изменениями. Например, раз в месяц требования обновляются, проходя через процедуру согласования новых требований, в результате чего могут возникнуть изменения в проекте. Для подрядчика изменение требований не должно стать неприятным сюрпризом, поэтому он должен быть достаточно гибким с точки зрения изменений в проекте. Практика показывает, что за время внедрения информационной системы бизнес меняется, и эти изменения не должны сдерживаться существующими информационными системами. Таким образом, важной частью процесса управления требованиями является процесс управления изменениями. В процессе управления требованиями возникает несколько сложностей. Первая из их -это число требований. На практике в большинстве случаев, это число превышает тысячу, поэтому необходим инструментарий, который может обеспечить их группировку, поиск и отображение. Второй проблемой в процессе управления требованиями является их трассировка или прослеживаемость, ведь для каждого требования необходимо учесть факт его исполнения, что в свою очередь тоже требует специализированного инструментария. А если добавить сюда управление изменениями, которое в свою очередь вводит понятие версионности требований, то становится понятным, что без специализированного инструментария при управлении требованиями не обойтись. Конечно, в простых случаях это может быть просто Excel, но в больших проектах придется использовать специализированный инструментарий. Часто задача управления требованиями часто пересекается с задачей описания бизнес-процессов. Идея формализовать требования на моделях бизнес-процессов не нова и сейчас реализуется во многих инструментах.