Управление требованиями к IT-проектам

Добрый день, уважаемое хабросообщество!

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

image

Введение


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

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



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

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

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

Управление требованиями, выработка требований и определение требований — краеугольные камни успеха любого IT-проекта.

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

Управление требованиями


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

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

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

В соответствии с Глоссарием терминов программной инженерии IEEE, являющимся общепринятым международным стандартным глоссарием, требование это:
  1. Условия или возможности, необходимые пользователю для решения проблем или достижения целей;
  2. Условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;
  3. Документированное представление условий или возможностей для пунктов 1 и 2.

В соответствии со стандартом разработки требований ISO/IEC 29148, требование — это утверждение, которое идентифицирует эксплуатационные, функциональные параметры, характеристики или ограничения проектирования продукта или процесса, которое однозначно, проверяемо и измеримо. Необходимо для приемки продукта или процесса (потребителем или внутренним руководящим принципом обеспечения качества)
Так же глоссарий ITILv3 определяет такое понятие, как набор требований — документ, содержащий все требования к продукту, а также к новой или измененной ИТ-услуге.

Требование должно обладать следующими характеристиками:
  1. Единичность — требование описывает одну и только одну вещь.
  2. Завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует.
  3. Последовательность — требование не противоречит другим требованиям и полностью соответствует документации.
  4. Атомарность — требование нельзя разделить на более мелкие.
  5. Отслеживаемость — требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и задокументировано.
  6. Актуальность — требование не стало устаревшим с течением времени.
  7. Выполнимость — требование может быть реализовано в рамках проекта.
  8. Недвусмысленность — требование определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объекты и факты, а не субъективные мнения. Возможна одна и только одна его интерпретация. Определение не содержит нечетких фраз, использование отрицательных и составных утверждений запрещено.
  9. Обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятия требования.
  10. Проверяемость — реализованность требования может быть проверена.

В соответствии с ITILv3 все требования в проекте можно разделить на следующие группы:
  1. Функциональные (Functional) — реализуют саму бизнес-функцию.
  2. Управленческие (Manageability) — требования к доступным и безопасным сервисам; относятся к размещению системы, администрированию и безопасности.
  3. Эргономические (Usability) — к удобству работы конечных пользователей.
  4. Архитектурные (Architectural) — требования к архитектуре системы.
  5. Взаимодействия (Interface) — к взаимосвязям между существующими приложениями и программным средствами и новым приложением.
  6. Сервисного уровня (Service Level) — описывают поведение сервиса, качество его выходных данных и другие качественные аспекты, измеряемые заказчиком.

Распространенное программное обеспечение для управления требованиями


В настоящее время широкое распространение получили такие системы управления требованиями как IBM Rational RequisitePro, Telelogic DOORS, Sybase PowerDesigner и Borland Caliber RM.

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

IBM Rational Requisite Pro

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

Rational RequisitePro помогает проектным группам управлять требованиями, создавать качественные сценарии использования, расширять возможности отслеживания, повышать эффективность совместной работы, уменьшать потребность в доработках и повышать качество.
  • Снижает сложность благодаря подробным представлениям с возможностью трассировки, в которых показаны отношения между родительскими и дочерними элементами.
  • Снижает связанные с проектом риски, показывая требования, которые могут быть затронуты изменениями требований более низкого или более высокого уровня.
  • Обеспечивает совместную работу географически распределенных рабочих групп благодаря применению полнофункционального, масштабируемого Web-интерфейса и цепочек обсуждения.
  • Обеспечивает сбор и анализ сведений о требованиях с возможностью точной настройки атрибутов и фильтрации.
  • Повышает производительность труда, позволяя отслеживать изменения путем сравнения версий проекта с начальными характеристиками, описанными с помощью XML.
  • Обеспечивает соответствие результатов проекта поставленным задачам и бизнес-целям благодаря интеграции со средствами IBM Rational для разработки и выпуска ПО.

IBM Rational/Telelogic DOORS

IBM Rational/Telelogic DOORS — семейство решений для управления требованиями и создания сложных наукоемких изделий (авиа, судостроение, поезда, ракеты, автомобили т.п.).

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

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

Borland Caliber RM

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

Borland Caliber RM обладает следующими функциональными возможностями:
  • Централизованное хранилище требований для всех проектов, разрабатываемых IT-компанией.
  • Адаптируемость — Caliber RM можно сконфигурировать для использования в любом проекте, что повышает эффективность процесса управления требованиями.
  • Трассируемость требований — открытая архитектура Caliber RM позволяет связать требования с другими артефактами на всех стадиях жизненного цикла программного продукта.
  • Поддержка большого числа клиентов — Caliber RM прекрасно интегрируется с такими системами разработки, как Microsoft Visual Studio, Eclipse на платформе Windows.
  • Интеграция с другими продуктами Borland для поддержки полного жизненного цикла программного продукта.

Другое ПО


За кадром остались также достаточно известные системы управления требованиями, такие как:
  • Sybase PowerDesigner
  • OpenSource Requirements Management Tool
  • RequirementsWin и другие


Новый подход к управления требованиями


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

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

Предположим, что следующие требования описывают маршруты документов соответственно на предприятиях А и Б:
А — {A, B, C, D, E}
Б — {F, B, C, D, E}

Здесь видно, что под F и А имеются в виду документы, а B, C, D, E — их маршруты.

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

Всем спасибо за внимание, жду комментариев.
Поделиться публикацией
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 84
  • +1
    Мысль, которая выраженна в иллюстрации, в полной мере передает то, с чем обычно я сталкиваюсь по будням, только немного в другом сегменте!)
    • +1
      Иллюстрация напомнила игру «Сломанный телефон».
      • 0
        Нам такую картинку преподаватель по системотехнике рисовал ещё на первом курсе, до сих пор помню :)
        • –2
          За одну только эту иллюстрацию топик можно плюсовать!
        • +21
          В процессе чтения, не уходило ощущение, что это текст из методического пособия или чей-то курсовой работы. Дежурные фразы «сухим» формальным языком
          • –1
            Очень старался написать по-серьезному, поэтому и получилось формально.
            • 0
              Для написания серьезных вещей академический слог не обязателен.
              Особенно на Хабре.
          • +14
            Статья слишком «сухая», что бы быть «научно-популярной», и при этом слишком абстрактная, что бы разработчики почерпнули из неё практическую пользу прямо сейчас.
            • +1
              Зачастую в проектах вообще сложно вытащить из заказчика требования как таковые.
              Буду рад если кто-нибудь поделится опытом именно получения требований, удовлетворяющим всем 10 пунктам.
              • +13
                Зачем Вы все это написали?
                Позволю себе предположить — Вы хотели донести до читателей Хабра то, что знаете сами.
                Но, например, я, как человек, который сам является менеджером проектов, пролистнул это очень быстро — тонны слов и все неинтересно.

                Давайте на примерах — возьмите конкретный кейс, распишите для него эту теорию на практике.
                Если надо помочь — обращайтесь, помогу. Сделаем практическую конфетку из теоретической сухой статьи.
                Ю а велком.
                • +2
                  Присоединюсь, тоже перелистнул очень быстро. Процитирую: «тонны слов и все» это лишнее. Извините, порекомендую к чтению: Купера «Психбольница в руках пациентов». Иллюстрация прям по этой книге. Отличная! Правда, у одного знакомого CIO на стенке висел более пессимистичный вариант.
                  Мне субъективно не понравилось освещение управлением требованиями с использованием тяжеловесных программных продуктов. Возьму на себя смелость заявить, что мало кто из хабросообщества сталкивается с очень крупными проектами, где стадия проектирования, формулирования требований, планирования несколько месяцев и использование таких систем управления требованиями оправданно. В реальности проекты меньше, сроки разработки меньше, на инструментарий не разоряются и один человек выполняет несколько обязанностей. Только по Rational был такой толстенный талмуд. Ни у кого нет времени все это осваивать, плюс не дадут, уволят раньше :-), а менеджеры не захотят осваивать. Из-за этого от статьи ощущение оторванности от реальной практики. Это как после институтов приходят вчерашние студенты и начинают все делать по теории. Успехов Вам! Молодцы, что написали статью.
                  • 0
                    Точно.
                    Время — самый дорогой ресурс в разработке ПО, поэтому тратить его на излишнюю документацию расточительно.
                    Описанное управление требованиями рассчитано на крупные проекты, которых на рынке не очень много.
                    Для средних и мелких проектов, ИМХО, нужно не детально фиксировать требования, а быстро создавать прототип, получать feedback от пользователей и переходить к следующей итерации. Мышлению всегда проще работать, когда есть от чего оттолкнуться. А рассматривать сферического коня в вакууме — это, конечно, полезно для развития фантазии, но совершенно бесполезно для конкретных нужд разработки ПО.
                    • 0
                      А фидбэк разве нельзя рассматривать как требования?
                      • 0
                        Нет, но фидбек можно использовать в процессе выявления требований.
                        • 0
                          Вы имеете ввиду, что фидбек нужно анализировать и на основе имеющегося фидбека и своих соображений надо формулировать новые требования или корректировать старые?
                    • –1
                      Эта иллюстрация — явная же компиляция из того классического варианта.
                  • 0
                    Разработка большой и сложной системы не может быть завершена за один подход — итерацию.
                    Это может быть не верно если вы являетесь и заказчиком проекта и одновременно его разработчиком.
                    Отсутствие барьера объяснить/понять идею — может стать самым главным преимуществом проекта.
                    • +3
                      По-моему это реклама ПО для управления требования к IT-проектам.
                      • +7
                        Boring. Манера изложения напомнила институтские методички.
                        • +1
                          Сухо. Увы.
                          • +2
                            Да. Статья сухая, да и воды полно…

                            А по делу — как раз недавно пытались с менеджером проекта поговорить — чтобы заказчик поточнее давал спецификации того, что он хочет. В итоге после переговоров с заказчиком получили такой ответ — что проект у нас «с хаотической спецификацией». То есть «заказчик сам не знает что ему в конце надо будет. вот соберутся его топ-менеджеры в кафешке или на совещании, выпьют чая/кофе/алкоголя, потрындят и таки что-нибудь в виде какой-то части спецификаций вам выдадут.» А на практике — такие совещания у заказчиков случаются видимо раз в неделю минимум. Ибо часто каждую нгеделю спецификации не только новые приходят, но и полностью противоречащие предыдущим. Очень сложно работать.

                            Правда я был на нескольких проектах — и такое, в большей или меньшей степени есть везде. В меньшей — если заказчик близок к основной тематике вашей компании или заказчик внутренний. Но, увы, мы работаем в аутсорсинге и такое случается крайне редко. Видимо, специфика.
                            • +1
                              Смиритесь или менйте работу.
                              КО как бэ подсказывает «требования» меняются.
                              Это может происходить по разным причинам. Среди них:
                              1)Политические игры в стане заказчиков.
                              2)«Заказчик» — идиот
                              3)PM со стороны заказчика идиот
                              3)Ваш аналитик — идиот
                              4)Ваш PM — идиот
                              5)Вы идиот
                              6)«жизнь» не стоит на месте — и всё меняется.

                              (никогда не задумывались почему PMI приводит такую ужасающую статистику по успешному заверщению проектов? И это учитывая что далеко не всякая организованная активность может называться проектом. А только активность котороая соответсвует вполне конкретным правилам и должным образом оформленная)

                              Вобщем пока заказчик готов оплачивать все свои фантазии — задача «разработки» всяечки способствовать их воплощению в жизнь. ПОменялись фантазии — ок — строим новые. Есессно при условии что всякая работа требует денег и времени — если если нет — смените работу.
                              • 0
                                Требования меняются — это не значит что кто-то идиот. Я бы даже сказал, что идиот тот кто не полагает что изменение требований — это нормально в некоторых проектах. У проектов где полностью пишутся требования свои болезни, в некоторых случях это большой риск того что пользоваться системой будет пользоваться невозможно(ужасно неудобно).
                                • 0
                                  Да даже если и заказчик идиот — это не повод его бросать.
                                  • 0
                                    для таких редких случаев когда в проекте почемуто никто не ведёт себя как идиот — есть пункт 6
                                    Видите, всё предусмотрено)
                                • 0
                                  Заказчик обычно не знает, чего он хочет. И тем более не знает, если это не разработка новой системы, а адаптация какой-либо системы под нужды заказчика.

                                  Заказчик в первую очередь заинтересован в том, чтобы его бизнес шел в гору, а не в том, чтобы у него была система. Если он не может сам адекватно объяснить, что от системы требуется, то задача аналитика (как бизнес-консультанта) ему навязать решение в конце-концов.

                                  Как раз для того, чтобы каждую неделю систему не переделывать и нужно управлять требованиями. Здесь много топиков с текстом а-ла «сначала пишите ТЗ, потом делайте». ТЗ — тоже в определенной степени документ, регламентирующий требования. Согласитесь, когда оно жестко прописано разрабатывать гораздо легче.
                                  • 0
                                    «Согласитесь, когда оно жестко прописано разрабатывать гораздо легче. „
                                    Я бы сказал по другому: хорошо когда есть заинтересованность и диалог. ТЗ как таковое тут не причём)

                                    ТЗ вобще стало одним из buzzword в нашей отрасли. Юмор ситуации в том что, хотя это мало кто осознаёт, ТЗ ничего не гарантирует и ни от чего не защищает. Точней ТЗ “защищает» интересы только юристов.
                                    Дело вот в чём. Представте. Есть заказчик, Есть Подрядчик. Они составили подробнейшее ТЗ («жестко всё прописали»). Начали делать. Закрываются этапы. Заказчик их так или иначе оплачивает. И вот в какой-то момент — толи потому что по статистика все идиоты, толи потому что жизнь так устроена и обстоятелсьтва изменились, заказчик гововрит что ему нужно [не]совсем другое.

                                    Вот ситуация. Да есть ТЗ. В котором всё «жётско» пропсиано. Что делать?

                                    «ТЗ защищает интересы подрядчика» — очевидно что нет. Бекоспромисность под предлгом того что в ТЗ всё жестко пропсиано — прямая дорога к убыткам и длительным судебный разбирательствам с целью получить деньги за выполненный, но непринятый этап и не оплаченный этап(а ведь есть догвоовры в которы есть предоплата, и оплата по завершении) + отрицательная карма.

                                    «ТЗ защищает заказчика» — тоже очевижно что нет. Подрядчик чтото сделал. Может похожее на ТЗ может не похожее. Но в любом случае — не то что нужно заказчику. Требовать по ТЗ? Угрожать не оплатить этап работ? Разорвать договор? Требовать выплат неустоек предусмотренных догвоовром?
                                    Это опять — потеря времени, потеря денег, суды, а главное — если вам разработка для чегото была нужна — у вас её как небыло так и нет и в ближайшее время уже точно не появится.

                                    Перспективы подбного рода судебных разбирательств весьма туманны если честно. Дело в том что судья — он как бэ ничего в этом не понимает. И в своих суждениях он может опираться только на заключения экспертов. Каждая из сторон естесвенно представит своих экспертов.
                                    +Если например у вас приложением к договору идут документы где есть какието «схемки» (типа UML и проч нотаций) и тз писал подрядчик — то заказчик так вобще ничего в этих схемах не понимает — может подрядчик мошенник может нет. новые экспертизы экспертов.
                                    + затягивание процесса.
                                    профит только у юристов и экспертов. у всех остальных участников — убытки.

                                    Так что «жесткое ТЗ» как и любая другая безкомпромиссная позиция чаще всего оказываются ошибочной.

                                    Хотя безусловно — подбробное, полное и непротиврочивое тз оно безусловно хорошо и способствует реализации — но вот от «изменений» никак не страхует.

                                • 0
                                  Мне кажется, что вам нужно определиться для какого типа людей вы пишите:
                                  если это менеджеры — то оформить текст в виде презентации, которая будет нести в себе мысль «как все плохо без профессионального трекинга требований, и как все здорово, когда он есть»
                                  если инженеры — выделить из вашего исследования факты, и разбавить их реальными кейсам.

                                  И я думаю, что практический обзор одной системы имел бы большую ценность, чем поверхностный обзор функционала нескольких
                                  • +1
                                    Теория такая теория)

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

                                    Если любой запрос «представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована» — то тогда любой запрос автоматически проходт это условие. Тогда зачем введено это условие?

                                    А вот ещё интересный вопрос — если «заинтересованное лицо» — заблуждается относительности «неполноценности» и невозможности «проигнорировать». В этой ситуации — запрос уже не явлется требованием? Или всётаки является?

                                    теория такая теория. Она помогает создавать иллюзию контроля и порядка)))

                                    • 0
                                      Недавно читал «Креативное программирование 2.0», приведенные примеры достаточно четко показывают, насколько сильно теория не стыкуется с практикой.
                                      • 0
                                        Это самое то место, где теория расходится с практикой. Согласен, и ITIL не идеален, но дает хорошую почву для начала работы и чем ближе ваши требования будут к описанным в стандарте, тем легче будет описанные там же методики использовать в реальных проектах.

                                        В общем смысле, по всем 10 пунктам можно вообще сказать одно — требование должно быть написано так, чтобы разработчик мог понять, что он должен разработать, а тестировщик протестировать.
                                        • 0
                                          А главное — чтоб аналитик смог его потом найти, регистрируя новое требование про то же самое.
                                      • 0
                                        Для меня было открытием, что требованиями вообще можно управлять отдельно. Иначе говоря, подсистема управления требованиями выделяется настолько явно, что автоматизируется как отдельный продукт.

                                        Я-то считал, что работаю в достаточно серьёзной фирме по производству ПО (250 человек, и это только российский «филиал» транснациональной корпорации, наибольшая доля заказов которой идёт непосредственно от IBM). И здесь за глаза всем хватает Jira (с кучей собственных модификаций, но суть та же). Требования оформляются тут ровно также, как задачи и баги, скажем.

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

                                        Впрочем, интерес достаточно отвлечённый. Я не думаю, что мне придётся когда-нибудь работать в организации достаточно монструозной, чтобы она нуждалась в таком комплексе ПО, где одними только требованиями управляет отдельный продукт.
                                        • 0
                                          Требованиями нужно управлять.

                                          IBM предлагает линейку продуктов, которая замечательно интегрируется между собой. И да, мы ее используем — IBM ClearQuest для багов, IBM RequisitePro для требований и IBM Rational Rose для моделирования. Проекты, в которых это гораздо более управляемы чем те, в которых требования документируются просто в ворде и через него же согласовываются.
                                          • 0
                                            Разумеется, нужно управлять. Вопрос в том, каким инструментарием.

                                            Нам вот Jira хватает. Именно там идёт обсуждение, а в ворде (.pdf) уже только фиксация достигнутых договорённостей происходит. Текущая статическая версия подписывается сторонами, имхо вполне логично.

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

                                            Так что для продвижения подобных решений надо бы ещё указывать, с какого именно момента внедрение этого ПО целесообразно.
                                            • 0
                                              Баг-трекеры отчасти управление требованиями и реализуют… Как правило в степени, достаточной большинству.
                                        • 0
                                          Интересный пост, только хочу внести коррективу. Во- первых для того что бы эффективно работали госты и стандарты требуется определенная зрелость бизнеса как у заказчика так и у интегратора, иначе простая трата времени и денег, со зрелостью у нас вообще проблемы. Ваша ситуация изображенная на картинка абсолютна типична на сегодняшний день. Решаться она должна комплексно, процесса управления требованиями недостаточно, Важно уметь применять лучшие практики различных стандартов ситуационно. Так же если вводится в проект понятие управление требованиями, необходимо одновременно вводить управление качеством продукта и управление конфигурациями, иначе требования сведут проект на НЕТ! оч. распространенная ошибка, присутствует в большинстве не успешных проектов.
                                          • 0
                                            Добавлю что большинство изменений требований на лету связаны с неопределенностями в проекте, которые необходимо устранять в самом начале.
                                            • 0
                                              Проклассифицируйте неопределённости-то
                                              • 0
                                                неуверен что существуют какие то единственно верные классификаторы, но от себя добавлю:

                                                неопределенности

                                                1. Неопределенные качественно цели
                                                2. непродуманные, неэффективные правила и процедуры согласования и управления
                                                3. Заниженные бюджеты, вход в проект слоном
                                                4. Завышенные ожидания
                                                5. Борьба за статусность
                                                6. плохо определенные проблемы бизнеса
                                                7. Неадыкватное описание бизнеса
                                                8.… и т.д.

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

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

                                          • +1
                                            За список софта спасибо. Учту.

                                            В остальном статья тему сисек управления требованиями совсем никак, ни в малейшей степени не раскрывает.

                                            Основные грабли, из виденных мной, это:

                                            1) прочувствовать разницу между ожиданиями и требованиями. Если требования будут исполнены, а ожидания не удовлетворены, то обязательно настанет негативный результат проекта. Какие методики на этом поприще?

                                            2) ограничить «хотелки» заказчика рамками бюджета/проекта. А это фактически половина так называемых «управлений требованиями». Есть хинты?

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

                                            4) проекция требований. Система может быть построена почти всегда с точки зрения одного человека: либо директора, либо оператора, либо финансиста, либо аналитика, либо ещё кого-то. Одновременно всем она оптимально отвечать не сможет (чисса математически), максимум двоим-троим из десяти. Как выбрать ключевых и как заставить остальных подвинуться, не обижаясь? Иначе визы от остальных невозможно будет получить.

                                            5) актуализация требований. Даже не считая решения №3 прототипированием надо учитывать, что согласно «требованию момента» набор изменится просто в течение проекта или сразу после него — указ новый выйдет, новый номер вестника бухгалтера подоспеет. Что делать?
                                            • 0
                                              Пункт 4 требует доказательств. Не верю, даже не смотря на упоминание математики. Почему не может-то?
                                              • 0
                                                Простой пример: OLAP vs OLTP — для OLAP операторам нужна хорошая нормализация, для OLTP аналитикам нужна хорошая денормализация.
                                                Из OLTP быстро глубокого отчёта не построишь, с OLAP бизнес-процесс почти невозможен.
                                                В одной базе это не уместить.
                                                Первичное построение куба на данных OLTP долгий процесс, а кубы аналитику нужны постоянно разные.
                                                • 0
                                                  Итого: в системе должно быть и то и другое, с постоянно-периодическим доливом данных из подсистемы OLTP в подсистему OLAP. И такая система одновременно удовлетворит обе подгруппы пользователей. Все так и делают, где на OLAP-аналитиков начальство выделяет деньги. Где я не прав?
                                                  • 0
                                                    во-1 это две системы (не подсистемы одного контракта). Вы выходите за рамки обсуждения одной системы. Сам заказчик сразу два параллельных контракта делать вряд ли будет — риск учетверяется.

                                                    во-2 это опять гемор с портированием данных, регулярно еженедельным. Какие-то кубы стареют, какие-то заново проектировать. Но это я ниже описал как №2. И опять это другой контракт — на оперирование OLAP.
                                                    • 0
                                                      с какого бодуна это другой контракт?
                                                      • 0
                                                        То есть вы уже согласны, что системы-подсистемы весьма разные, что пункт 4 о проекции справедлив, и дискутируем дальше?
                                                        • 0
                                                          Наоборот, не согласен. Контракт может быть всего один: первичный договор на создание системы, удовлетворяющей всех сразу.

                                                          Я по-прежнему считаю, что систему всегда можно сделать такой, чтоб она удовлетворяла требованиям всех групп её пользователей. В крайнем случае, за счёт включения в себя дополнительных подсистем. И никаких вынужденных «ущемлений» одних групп за счёт других со стороны системы быть не может. Ущемления отдельных групп пользователей могут быть лишь со стороны их начальства — заказчика системы, если это начальство будет не готово заплатить за те возможности системы, которые нужны только для этих групп.

                                                          Так, например, считать что OLAP-аналитики должны «подвинуться», чтоб система могла удовлетворить требованиям OLTP-сотрудников — в принципе некорректно, ибо без OLTP у OLAP вообще данных не будет.
                                                          • 0
                                                            «удовлетворяющей всех сразу»
                                                            Вы реально проекты внедряли? Реверс-инжиниринг делали, требования документировали?
                                                            • 0
                                                              Давайте лучше, не переходя на обсуждение моего опыта, Вы продемонстрируете доказательство или хотя бы пример, подтверждающий это Ваше утверждение: «Система может быть построена почти всегда с точки зрения одного человека. Одновременно всем она оптимально отвечать не сможет (чисто математически)»
                                                              • 0
                                                                Если возможно — тогда то самое, математическое.
                                                                • 0
                                                                  так я уже и сказал: OLAP vs OLTP, и это разные системы.

                                                                  Пример два: главбух говорит, что кнопка должна быть слева, а бух говорит, что справа.

                                                                  Пример три: директор говорит, что надо регистрировать начало рабочего дня по активности в системе, а оператор говорит, что до включения компа он перебирает стопки договоров.

                                                                  Пример четыре: начальник отдела считает, что клиента надо заводить визардом, а оператор знает, что удобнее одной длинной формой.

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

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

                                                                  «тысячи их»
                                                                  • 0
                                                                    1 — OLAP и OLTP — это разные ПОДсистемы. И к тому же первая без второй не бывает. То, что OLAP зачастую делается и продаётся отдельно — не означает, что она не является подсистемой, ибо продаётся она всегда для интеграции в общую систему учёта.

                                                                    2 — кто её будет нажимать, того и слушать. Игнорирование мнения по подсистеме от человека, не работающего с этой конкретной подсистемой — не является ущемлением его возможностей. Однако, если он дело говорит, а непосредственный пользователь упирается — это проблема непосредственного пользователя и его начальства. Но не заказываемой системы.

                                                                    3 — и как с точки зрения этих двух человек — директора и оператора — может быть по-разному построена система? Почему Вы считаете, что директор с оператором не смогут и, главное, не должны в любом случае, найти общее определение понятию «начало рабочего дня» и способ его учёта?

                                                                    4 — см. отзыв 2

                                                                    5 — см. отзыв 3. Кроме того, я не очень понял чем «снимать проблемы» противоречит выбору момента «закрытия опердня»?..

                                                                    6 — что может помешать общие модули нанизать на две цепочки сразу? что может помешать сделать модули контекстно-зависимыми, знающими о текущей цепочке?

                                                                    ни один не доказателен…
                                                                    • 0
                                                                      Дык это живая практика, чего доказывать. Можно было бы и переписку по этому поводу приподнять, где-то на тех предприятиях она могла сохраниться. Но вам придётся поверить, что она была такая, эта переписка.

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

                                                                      А вы рисуете какого-то сфероконического заказчика, который во всех головах имеет единое мнение и гладких контрагентов.
                                                                      • 0
                                                                        Кто директору пообещал решение проблем, которые не могут быть решены — тот идиот или подлец. Сам директор видимо тоже не далёк от него…

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

                                                                        И акционеры вполне могут понять, если это представить в доступной форме, почему в отчёте нет той части, которую в принципе невозможно получить к заданному сроку.
                                                                        • 0
                                                                          Вы зайдите к директору и попросите его убедить акционеров изменить формат отчётности.
                                                                    • 0
                                                                      Примеры 2 и 4 решаются индивидуальными и/или кастомизируемыми интерфейсами. Тут, правда, встаёт вопрос бюджета, но если заказчик хочет удовлетворить все такие требования своих пользователей, то проблем быть не должно.
                                                                      • 0
                                                                        «Ну, вы поняли...»
                                                                        Заказчик не будет удваивать бюджет потому, что два человека видят систему по разному.
                                                                        Он просто скажет, что старший прав не особо вникая.
                                                                        И так по каждому вопросу. В результате получится система для директора, и не очень-то для оператора.
                                                                        • 0
                                                                          Если директор идиот, а подрядчик бесхребетен — да, так и получается.
                                                                          • 0
                                                                            Люди не идиоты, не льстите себе. Они некомпетентны в программировании и организации программистских проектов.

                                                                            Кроме того они заняты своими делами, чтобы дополнительно заниматься решением программистских проблем.
                                                                            • +1
                                                                              «Програмисстские проекты» тут как правило вообще не причём.

                                                                              Согласитесь, что чтобы понять в какой последовательности должны быть расположены поля формы какогото доумента — не надо быть «крутым компьютерщиком» или чтото понимать в новомодных ныне «usability» и «UX» — для ответа на этот вопрос достаточно понаблюдать как люди заполняют соответсвующи бумажный бланк. в какой последовательности, куда подглядывают, с чем сверяются. И из этого этого вырастает пусть, возможно, не самый лучший вариант, но уже достаточно хороший и обоснованный.
                                                                              И если в данной ситуации начальник этих операторов упорствует и требует всё неприменно сделать по «евойному» — то он просто «идиот».

                                                                              А по поводу вашего тезиса о «невозможности удовлетворить всех» — в целом согласен. Но «математика» тут не причём) Причины этих проблем всёже — человеческий фактор, а не фундаментальное противоречие OLTP и OLAP)

                                                                              Кстати — может быть кто-то может порекомендовать какую-нибудь толковую книгу по работе с людьми которые настроены неконструктивно?
                                                                              • 0
                                                                                Человеческий фактор — это да…

                                                                                Книжки — про НЛП, может быть уместны окажутся?..
                                                • 0
                                                  По пункту 5 — у требования же требуется наличие такой характеристики, как «Актуальность» — вот её подправляют с течением времени и получают новую картину, исходя из которой можно принимать очередные решения…
                                                  • 0
                                                    Неверно. Дополнительные требования увеличивают ожидания.
                                                    Если их реализовать, то упираемся в №2
                                                    Если их не реализовать, то сразу после внедрения ожидания не оправдываются — предприятие испытывало стресс реинжинринга, платило «огромные бабки», терпело часовые интервью, шло на всякие прочие жертвы, а система не удовлетворяет. По букве контракта да (и то если ТЗ однозначное), а по духу контракта (удалить проблемы заказчика) — нет. В лучшем случае будет плохая репутация. В худшем суд.
                                                    • 0
                                                      Нужно изначально не забывать одним из требований к системе указывать (учитывать) возможность развития и изменения требований, и исходя из этого сразу предусматривать достаточный уровень гибкости системы… Грамотный разработчик это знает, как минимум из негативного опыта, как максимум — из книжек и подобных бесед.
                                                      • 0
                                                        «Преждевременный рефакторинг — основа всех зол»/перефразированный Дейкстра/

                                                        Если вы в ТЗ таки акуратно учли главу «Перспективы развития, модернизации Системы», то это автоматически означает, что ТЗ написано почти окончательно, и вы натыкаетесь на грабли №3 «заказчик не может уточнить требования, пока не увидит реализацию».
                                                        • 0
                                                          Про грабли №3 — вполне реально заранее оговорить в договоре неизбежность итеративного подхода. Тут, правда, придётся подумать над условием выхода из цикла, и как заказчика с этим смирить…

                                                          И действительно проще бывает обмануть, пообщещать золотые горы в первой же итерации — но на такой хитрый подход обычно накладывают ограничения субъективная совесть и объективные перспективы судебного разбирательства и выплаты неустойки… И приходится стараться быть реалистом и добиваться от заказчика того же.
                                                          • 0
                                                            «придётся подумать над условием выхода из цикла, и как заказчика с этим смирить…»
                                                            Во-1 это = грабли№2

                                                            Во-2 писать главу «Перспективы развития и модернизации Системы» вы уже слишком поспешили. В итеративном подходе стороны сами не знает куда повернёт проект, хотя грабли №3 и №5 вроде решаются почти мягко. С другой стороны если исполнитель не знает куда заведёт проект, он просто прекращает им управлять. То есть вряд ли уложится в сроки&бюджет&качество (тут контроллируется только качество).
                                                            • 0
                                                              С граблями №2 я и не думал спорить :)

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

                                                              Другое дело, что НИОКР планировать по строкам и бюджету всегда сложно…
                                                              • 0
                                                                Это пошаговые контракты одного проекта (включающего несколько систем-подсистем). Вы пытаетесь разрезать систему по контрактам не на подсистемы уже, а на шаги квартальные шаги.

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

                                                                В общем, аффтар скрылся, предпочитая на вопросы не отвечать.
                                                • +1
                                                  > В условиях современной экономики выигрывает тот, кто производит больше с меньшими затратами.

                                                  Это очень и очень спорный вопрос. Можно доказывать вплоть до обратного.
                                                  В современной экономике IT-компании переходят от понятий продукта к понятию сервиса, который не размывает грань между разработкой и поддержкой. 95% проектов достается крупным компаниям, которые имеют постоянных клиентов. Цены на рынке более-менее устоявшиеся. Причем, основные затраты уходят отнюдь не на разработку, а на т.н. огранизацию «сервиса» (на зарплату менеджерам, инфраструктура, etc...).

                                                  Скажу курьезную фразу, но для такого вида бизнеса (сервис) делать качественные и законченные продукты невыгодно. Вы поставляете решение, и заинтересованы в постоянном спросе на него (а не разовом заказе!). А для этого Вы должны поставлять всегда наполовину сделанное решение.

                                                  > По данным исследования, проведенного IBM в области IT, 60% затрат времени организации-разработчики
                                                  Классический пример неэффективно работающей компании. Огромные обороты при плачевном качестве продуктов, разрабатываемом на аутсорсинге (в Индии). Оборот, получаемый от продаж не идет ни в какое сравнение с затратами на разработку. Активно пытается пропехнуть свои Rational, крича о том, что все работают неэффективно. ))
                                                  • 0
                                                    Если не считать db/2, то остальные продукты IBM вполне культурные :-)

                                                    Что касается некачественной работы, то тут есть три ситуации:
                                                    1) если вам разработка выгоднее, то выгоднее предыдущий проект завершить как можно полнее
                                                    2) если область постоянно меняется, как бухгалтерия, то в каждый конкретный момент у вас полностью завершённый продукт, но через месяц-два добавляются новые требования.
                                                    3) если вы не намерены делать проект в один год, то он вполне разумно бьётся на несколько лет поэтапно, так что в каждом конкретном этапе продукт завершён, а на следующем этапе развивается.

                                                    Но если вы пропагандируете что-то свыше трёх названных схем, то я бы с вами не работал — не хочется сидеть на игле халтуры.
                                                    • 0
                                                      Продуктами Rational пользоваться невозможно. Когда то казалось что это был cutting edge, однако похоже что IBM Rational просрали таки все полимеры.
                                                    • 0
                                                      Для любого бизнеса делать качественные и законченные долгоживущие продукты не выгодно — рынок насытится и очередные экземпляры продавать будет некому. Продукт должен быть либо одноразовым (типа пирожка), либо сподвигающим к совершенствованию, ремонту или замене. :(
                                                      • 0
                                                        Да? У вас случайно нет цифр доходов Toyota от продаж и сервиса? Я слышал краем уха, что объём сервиса настолько низок, что его выгодно сворачивать — надёжность продукции достаточно высока. Но Toyota не намерена снижать качество.
                                                        • 0
                                                          Ну, возможно их маркетологи просчитали, что побуждений к замене на новые модели машин у их клиентов достаточные, чтоб можно было не огорчать их качеством, а привлекать…
                                                          • 0
                                                            В математике и логике достаточно одного контрпримера, чтобы опрокинуть заявление. ;-)
                                                    • 0
                                                      Со слов «Глоссарием терминов программной инженерии IEEE», «стандартом разработки требований ISO/IEC 29148», «глоссарий ITILv3» и т.п. в интернет-статье ДОЛЖНЫ быть ссылки! Ну просто таки ОБЯЗАНЫ!!!

                                                      Но даже так статья весьма хороша.
                                                      • 0
                                                        По ITILv3 получается бывают «Эргономические требования», что в виду их же определения обязательности для требования вводит меня в когнитивный диссонанс. Ибо обосновать обязательность ЛЮБОГО эргономического требования — совершенно нереально.
                                                        • 0
                                                          По-моему, они бывают даже на законодательном уровне прописаны, то есть их обязательность априори известна.
                                                        • 0
                                                          Так кто-нибудь какую то систему из перечисленных в статье использует? Или не из перечисленных
                                                          • +1
                                                            Указанные системы вроде достаточно старые, сейчас популярна идея реализовывать тоже самое на основе issue tracker-а (как плюс — не надо заниматься интеграцией 2-х систем).

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

                                                              Принципов «несколько» больше, можно посмотреть хотя бы четыре отсюда Системы управления требованиями: что и зачем?
                                                              • 0
                                                                На днях вышла книжка по разработке и управлению требованиями на базе Cradle. Альфа-версия доступна бесплатно, включает учебный проект, выполненный по книжке. Посмотреть содержание и скачать можно отсюда saturs.ru/index.php?r=block/plain&label=cradle-book

                                                                Прямая ссылка для скачивания пакета с книжкой saturs.ru/elfiles/requirements_management_Cradle.zip

                                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                              Самое читаемое