Что такое управление требованиями
Что такое управление требованиями
Управление требованиями представляет собой систематизированный подход к обнаружению, документированию, организации и отслеживанию требований на изменение системы.
Условие или возможность, которым должна соответствовать система.
Сбор требований может представляться достаточно простой задачей. Однако в реальности по ряду причин возникают сложности:
Что нужно для того, чтобы справиться с этими сложностями? По нашему опыту, важны следующие навыки:
Анализ сложностей
Анализ сложностей необходим для того, чтобы обеспечить понимание сложностей и начальных потребностей заинтересованных лиц и предложить общее решение. Это когнитивный процесс, направленный на понимание «первопричин» сложностей. В ходе анализа достигается согласие в отношении постановки задачи и круга заинтересованных лиц. Кроме того, на этом этапе определяются рамки и ограничения проекта с точки зрения бизнеса. Необходимо проанализировать экономическое обоснование проекта и достигнуть понимания ожидаемой окупаемости инвестиций от реализации системы.
Понимание потребностей заинтересованных лиц
Требования могут происходить из самых различных источников, включая клиентов, партнеров, пользователей и специалистов по предметной области. Нужно тщательно отобрать источники, получить доступ к ним и получить у них максимально подробную информацию. Лиц, выступающих в роли основных источников такой информации, называют заинтересованными лицами. Если вы разрабатываете внутреннюю информационную систему для компании, в группу разработчиков можно включить ее будущих пользователей и специалистов по предметной области. Довольно часто обсуждение начинается с точки зрения бизнеса, а не с точки зрения системы. При разработке продуктов на продажу в группу разработчиков целесообразно включить специалистов по маркетингу, хорошо понимающих потребности клиентов.
Для получения информации можно проводить интервью, предпринимать мозговые штурмы, создавать прототипы, проводить опросы и анализировать конкурирующие системы. В результате создается список запросов, которые могут быть описаны в текстовом и графическом виде, с информацией об их относительных приоритетах.
Определение системы
Определением системы называется преобразование информации о потребностях заинтересованных лиц в осмысленное описание системы, которую требуется создать. На ранних этапах определения системы принимаются решения о составе требований, формате документации, степени формальности языка, подробности требований (сколько формулируется требований и насколько подробно они формулируются), приоритете запросов, объеме работ по созданию системы (обычно используются две разные оценки, полученные разными людьми разными способами), управленческие риски и начальное содержание проекта. В ходе этой процедуры могут создаваться первые прототипы и модели, напрямую связанные с важнейшими запросами заинтересованных лиц. Результатом процесса определения системы служат графическое описание системы и описание системы на естественном языке.
Управление содержанием проекта
Для эффективного выполнения проекта нужно продуманно установить приоритеты требований с учетом информации, полученной от всех заинтересованных лиц, и определить охват системы. Многие проекты страдают из-за того, что разработчики занимаются «пасхальными яйцами» (функциями, интересными разработчикам) вместо того, чтобы с самого начала сконцентрироваться на задачах, представляющих максимальный риск для проекта или необходимых для стабилизации архитектуры приложения. Для максимально быстрого устранения или нейтрализации рисков нужно организовать поэтапную разработку системы, тщательно отбирать требования для реализации на каждом этапе, руководствуясь при отборе принципом минимизации рисков. Подобная организация процесса требует согласования содержания всех итераций с заинтересованными лицами. Для этого нужны хорошие навыки по управлению ожиданиями от различных этапов проекта. Кроме того, нужно поддерживать контроль над источниками требований, состоянием рабочих продуктов и собственно процессом разработки.
Уточнение определения системы
Подробное определение системы должно быть сформулировано так, чтобы заинтересованные лица поняли его, согласились с ним и подписали его. Определение должно охватывать не только набор функций системы, но также ее соответствие требованиям законодательства и нормативных актов, удобство, надежность, производительность, простоту поддержки и обслуживания. Одна из распространенных ошибок заключается в том, что люди думают, что то, что сложно создать, должно сопровождаться сложным описанием. Это приводит к возникновению сложностей при описании назначения проекта и системы. Описание может быть впечатляющим, но если оно при этом будет непонятным, заинтересованным лицам будет сложно предоставить вам необходимую информацию. Необходимо приложить максимальные усилия к обеспечению того, чтобы описание системы было понятно его читателям. Зачастую требуется создавать разные описания для разных аудиторий.
Мы убедились в том, что методология вариантов использования в сочетании с визуальными прототипами очень эффективна при описании назначения системы и создании ее подробного описания. Варианты использования позволяют сформулировать контекст для реализации требований, они рассказывают о том, как будет использоваться система.
Управление изменением требований
Независимо от тщательности проработки требований, всегда что-нибудь меняется. Сложность управления изменением требований заключается не только в том, что при изменении требования необходимо затратить время на реализацию определенной новой функциональной возможности, но также и в том, что изменение одного требования может повлиять на другие требования. Необходимо убедиться в том, что структура требований устойчива к их изменению и что обеспечена прослеживаемость между требованиями и другими рабочими продуктами в цикле разработки. Управление изменениями включает установление базовой линии, определение того, какие зависимости следует проследить, установление возможности трассировки между связанными элементами и реализацию контроля за изменениями.
Дополнительная информация
Дополнительные сведения по данному вопросу можно найти в следующих источниках:
© Copyright IBM Corp. 1987, 2006. Все права защищены..
Управление требованиями
Что такое управление требованиями, как оно устроено, и почему приходится им заниматься? Уже давно стало ясно, что для преуспевания компании недостаточно просто иметь товар и продавать его. Продукт должен быть востребованным и удобным для потребителя. А позже появилось понимание, что продукт требует каких-то сервисов, что необходим переход к сервисной модели. Более того, потребитель хочет не владеть товаром, а пользоваться им. Отсюда — арендные или подписочные модели.
Что же дальше? А дальше нас ждет «экономика впечатлений»: потребитель будет покупать не товар и даже не сервис, а некое «послевкусие» после его пользования. И об этом надо позаботиться, это важно уже сейчас. Поэтому требования относятся и к товарам, и к сервису, и к тем впечатлениям, которые мы хотим сформировать от этих товаров у потребителя.
Всем этим надо управлять. Как показывает статистика, в технологически сложных отраслях до 45% попыток вывода на рынок новых продуктов, новых изделий кончаются неудачей. Анализ причин этих неудач говорит о том, что на самом деле большинство из них были заложены еще в начале программы разработки изделия, на стадии формирования требований.
Что такое требования и в чем суть проблемы?
Для начала определимся с понятием требований. Требование – оправданный, утверждённый и документально изложенный критерий, которому должно быть обеспечено соответствие.
Требования могут исходить как из внешней среды (от заказчика, регулирующих органов и пр.), так и из внутренней среды организации (технологические ограничения, требования маркетологов и т.д.). Распространяются такие требования, прежде всего, на функции изделия, на используемые в нём материалы, на применяемые интерфейсы, протоколы и прочие свойства изделия. Кроме того, требования могут накладываться и на процессы разработки изделия, и на производственные процессы, и на последующую эксплуатацию изделия.
В чем же проблема с требованиями? Прежде всего, это неспособность понять требования заказчиков. Кроме того, количество требований к концу разработки может на порядки превышать их количество в исходном ТЗ. Т.е. на входе в разработку изделия просто невозможно определить сразу все требования к нему. Серьезное изделие масштаба самолета – это более миллиона требований.
В какой-то момент пришло осознание факта, что описать в виде требований инновационное изделие до начала его разработки просто невозможно, а все попытки ограничиться единожды составленным набором требований сводят «на нет» те самые инновационные свойства изделия. И, начиная, прежде всего, с разработки программного обеспечения, а сегодня всё шире и шире стали применяться принципы «аджайл» (Agile). Такие принципы принимают факт ущербности начальных требований и необходимости работы с ними на всем цикле разработки.
При ближайшем рассмотрении оказывается, что проблемы, связанные с ошибками разработки или производства, как правило, весьма несущественны по сравнению с тем, что заложено в требованиях. Прежде всего, это неполнота требований по составу и проработке. Не менее важно и то, в каком виде требования представляются заинтересованным лицам, которые, собственно говоря, и должны воплотить такие требования в разрабатываемом изделии. Да и заказчик далеко не всегда знает, что он «хочет», не всегда готов выразить свои требования в пригодном для дальнейшего использования виде.
В результате требования могут совершенно не совпадать с ожиданиями, а участвующие стороны часто понимают их по-своему. В довершение всего, как мы уже знаем, требования будут по ходу разработки изделия меняться и дополняться. Если этим не заниматься системно, то есть не управлять требованиями, то и результат будет соответствующим.
Многообразие требований (физические, логические, функциональные и пр.) ведет к необходимости скрупулёзного администрирования и управления. Исследователи области управления требованиями сходятся в одном – две трети ошибок, нестыковок и переделок связано либо с неполнотой требований, либо с ненадлежащим их представлением.
Соответственно, необходимо с самых ранних стадий до конца жизненного цикла изделия выявлять и анализировать требования, управлять изменениями, привязывать требования к элементам конструкции, процессам, отдельным заданиям и работам в составе проекта разработки и программы испытаний, составлять отчётные формы. Причём, чем дальше мы будем продвигаться по стадиям жизненного цикла, тем больше требований будет выявлено, потребует анализа и администрирования.
Иерархия требований
Существуют требования к материалам, интерфейсам и ко всему, из чего состоит изделие. Есть ещё требования к процессам производства, проектирования и пр. Они будут иметь десятки противоречий, разный «вес» и приоритеты. Так что картина получается довольно сложной. В процессе разработки количество и сложность требований увеличивается в разы. Причём надо следить за их изменениями. А потом нужно ещё доказать, что все требования реализованы — встает вопрос об испытаниях.
Как правило, сначала рассматривают требования ко всему изделию, потом – к отдельным его подсистемам и элементам. Когда требования уже достаточно проработаны, приступают к разработке изделия в целом и отдельных его элементов. И чем дальше вырисовывается поэлементная структура изделия, тем глубже должна быть декомпозиция требований: от уровня целого изделия до уровня требований к отдельным элементам. Нижележащие требования должны соответствовать и не противоречить вышестоящим – сопоставление и проверка требований на такое соответствие называется «валидацией» требований.
Для организации процессов разработки сложных изделий Независимая Ассоциация системных инженеров рекомендует использование метода RFLP (Requirements — Functional — Logical – Physical). В таком методе, опираясь на управление требованиями, в первую очередь определяют функциональный состав изделия, т.е. какие функции должно выполнять разрабатываемое изделие.
Следующим шагом продумывают реализацию таких функций элементами, узлами и системами в составе конструктива изделия, тем самым, определяют логическую архитектуру разрабатываемого изделия. Лишь с полным пониманием функционального состава и логики конструктива изделия переходят к проектированию отдельных элементов, систем и составлению цифрового макета изделия.
Имитационное моделирование
Чтобы понимать, каким будет поведение системы в реальной среде, какие необходимые изменения нужно внести до перехода к дорогостоящим натурным испытаниям и изготовления для них дорогостоящих натурным прототипам, уже достаточно широко используется имитационное моделирование. Имитационное моделирование сегодня позволяет не просто «посмотреть» на виртуальный прототип системы, но и выполнить необходимый цикл испытаний и выявить несоответствия требованиям ещё в виртуальной среде, пока изменения, необходимые для достижения соответствия требованиям, носят «цифровой» характер, а значит, обходятся разработчикам системы на порядки дешевле. Связанным продуктом имитационного моделирования является возможность анализа отказоустойчивости и безопасности системы.
Часто под управлением требованиями понимают составление спецификации требований. Не умаляя значимости этого процесса на протяжении всего цикла разработки, следует отметить, что согласно статистике, рассмотренной выше, не менее важным оказывается представление требований. Объём требований, с которым приходится иметь дело разработчикам, не оставляет шанса традиционным методам. Лучше всего в современных условиях зарекомендовала себя практика привязки требований к тем элементам изделия или системы, к которым они относятся. Таким образом, на всём цикле разработки и испытаний заинтересованные лица могут не перерабатывать весь состав требований, а работать лишь с относящейся к их участку выборкой.
Неотъемлемой частью требований ещё на стадии определения должны становиться методы определения соответствия, т.е. методики испытаний, по которым будет подтверждаться соответствие требованию. Последнее время процесс подтверждения соответствия требованиям всё чаще стали называть верификацией требований. По результатам испытаний подтверждают соответствие требованиям или инициируют внесение изменений в изделие. Понятие «валидация» изделия, в свою очередь, появилось, исходя из возможного несовершенства самих требований или методов их верификации. Другими словами, валидация изделия носит более высокоуровневый характер и направлена на исключение ситуаций, когда на испытаниях подтверждено соответствие всем требованиям, но пользоваться изделием невозможно.
В результате, состав требований вкупе с методиками определения соответствия определяет программу испытаний. В современных условиях программа испытаний следует всем изменениям в составе требований и может меняться по ходу разработки. В такой программе важно не только сбалансировать необходимые доли натурных и виртуальных испытаний, но и «комплексировать» испытания, т.е. сгруппировать необходимые тесты и замеры таким образом, чтобы их можно было проводить за одну установку на стенд, на одном прототипе, за один вылет/выезд/запуск… Подобная проработка программы испытаний позволяет вдвое сократить количество испытаний и необходимых прототипов, значительно уменьшить сроки реализации программы испытаний. Однако, в условиях огромного числа требований и постоянных изменений в их составе управлять программой испытаний без применения современных цифровых инструментов становится невозможно.
Для чего нужны инструменты работы с требованиями?
Перед компаниями, разрабатывающими технически сложные изделия, стоит непростая задача. Изделия стали настолько сложными, что «на входе» проработать все требования к многокомпонентному изделию невозможно. Компании же подчас работают по старинке, начинают проект с ТЗ, где просто перечисляются основные технические характеристики изделия, а уже по ходу разработки, руководствуясь этим техническим заданием, какими-то нормами и правилами, собственными представлениями, ищут инженерное решение, отвечающее техническому заданию. Такое решение будет гораздо более сложным, чем можно было бы описать на входе. Кроме того в процессе поиска этих решений возникает множество других вопросов, которые также выражаются в требованиях — к производственным процессам, к материалам, к самому изделию, его функциям. Удерживать всё это в голове невозможно.
Между тем в современном мире нужно быстро разрабатывать изделия и быстро выводить их на рынок. В противном случае к моменту выпуска техническое задание может устареть и станет неактуальным. Поэтому процессом необходимо управлять с самого начала. Иначе неудачи закладываются на старте разработки новых изделий. Ненадлежащее управление требованиями — причина большинства ошибок, переделок, несоответствий, которые приводят к необходимости выпускать новые прототипы. При этом увеличиваются издержки, приходится тратить время и деньги на новые циклы разработки и испытаний. В результате откладывается выпуск изделия.
Кроме того, необходимо обеспечить сквозные процессы разработки изделия в многодисциплинарной среде, позволив специалистам из разных областей слаженно действовать в поисках инженерных решений.
Растущая сложность изделий приводит к тому, что сегодня традиционная роль главных/генеральных конструкторов как «отцов» изделия уходит в прошлое. Человеку не под силу держать в голове всю картину изделия, обеспечить его целостность. Как уже отмечалось, требования могут быть внутренними и внешними, касаться не только самого изделия, но и материалов, из которых оно изготавливается, процесса его изготовления. Отдельно взятому человеку очень трудно разобраться во всём этом разнообразии. Требования наследуются в ходе разработки, они могут быть связаны друг с другом. Каждое требование необходимо выявить, сопоставить с другими и так далее. Нужны автоматизированные системы, которые помогают работать над таким сложным проектом.
Платформа 3DEXPERIENCE и другие средства
Платформа 3DEXPERIENCE позволяет совместно работать с требованиями и включает в себя инструменты их формализации, привязки требований к элементам состава изделия, состава проекта разработки и испытательных работ. Всё это дает возможность не просто вести учёт требований, а с целью принятия осознанных решений анализировать требования по затратам и результатам от их реализации.
Решение CATIA Magic позволяет выявить и проанализировать потребности заинтересованных сторон, участвующих в производстве, вводе в эксплуатацию, в самой эксплуатации изделия, и выводе из нее. Все это обеспечивает полноту и правильное представление требований с самого начала жизненного цикла изделия, а именно недостаточная полнота и представление требований, как мы уже знаем, являются источником 2/3 ошибок в проектировании изделия.
Решение Stimulus ещё на ранних стадиях разработки еще на уровне определения требований моделирует поведение системы и анализирует взаимозависимость и реализуемость требований. Однако для такого моделирования необходимо должным образом сформулировать требования.
Самый современный подход к разработке сложных изделий — это основанный на моделировании моделей системный инжиниринг (MBSE, Model-based System Engineering). Требования – один из «трех китов», на которых базируется MBSЕ, без реализации которого невозможен системный инжиниринг.
Платформа 3DEXPERIENCE обеспечивает прозрачность требований в связке с методиками определения соответствия, прозрачность хода испытаний и их результатов. Система построена на рекомендуемом в системном инжиниринге подходе RFLP, что дает возможность на ранних стадиях провести имитационное моделирование и расчёты, выполнить анализ систем и внести необходимые изменения ещё в цифровой среде. А цифровые изменения, как известно, на порядок-другой дешевле натурных.
Функционал платформы 3DEXPERIENCE выходит далеко за рамки учёта требований, а именно:
Следует отметить, что платформа 3DEXPERIENCE одинаково хорошо справляется с управлением и виртуальными, и натурными испытаниями. Именно комплексный подход позволяет оптимизировать расходы и сроки реализации программы испытаний. В конечном счете, это позволяет убедиться, что изделие соответствует выявленным требованиям. При этом спецификаций требований бывает очень много – техническое задание, сертификационные требования, выявленные требования заинтересованных лиц, требования к поставляемым системам и подсистемам… и они между собой должны быть связаны и непротиворечивы.
Инструменты Dassault Systemes позволяют в условиях междисциплинарной разработки и широкой производственной кооперации обеспечить слаженное взаимодействие и сквозные процессы разработки изделия на основе требований. При этом управление требованиями строится на уровне жизненного цикла каждого отдельного требования, на уровне методик подтверждения соответствия, на уровне отдельных параметров в требованиях, что позволяет проводить моделирование и инженерный анализ.
Таким образом, платформа 3DEXPERIENCE комплексно управляет процессами жизненного цикла требований — от их выявления до верификации и валидации — и позволяет большим коллективам слаженно работать над моделированием, испытаниями и выводом в серию технически сложных инновационных изделий.
Подписывайтесь на новости Dassault Systèmes и всегда будьте в курсе инноваций и современных технологий.
Управление требованиями к IT-проектам
Добрый день, уважаемое хабросообщество!
Я уже давно являюсь читателем этого замечательного ресурса и вот, наконец, решил попробовать и свои силы. Я заметил, что тема управления проектами на Хабре освещена довольно широко в соответствующем блоге, а вот об управлении требований ничего найди не удалось. Что ж, пришло время восполнить этот пробел!
Введение
В условиях современной экономики выигрывает тот, кто производит больше с меньшими затратами. Сокращение затрат возможно как с использованием более дешевого сырья и материалов, дешевой рабочей силы, оптимизации процессов, так и их автоматизации. Автоматизация не ведет к стопроцентному сокращению затрат, но позволяет обрабатывать большее количество информации с меньшими затратами.
Основным инструментом автоматизации деятельности являются информационные системы. Информационная система — это совокупность информационного, математического, лингвистического, технического программного и другого обеспечения, а также персонала для оперативной подготовки информации для лиц, принимающих решения.
КИС поставляются как в коробочном варианте, который предлагает стандартные решения для автоматизации задач, так и позволяют создать необходимый набор функций самостоятельно в режиме конструктора. Кроме того, многие разработчики корпоративных систем предлагают услуги по адаптации коробочных решений к нуждам конкретного предприятия — услуги кастомизации.
Корпоративные системы являются продуктом интеллектуального труда, что позволяет им без больших материальных затрат легко тиражироваться и передаваться по каналам связи, в отличие от продуктов материального производства. Информационные продукты имеют гораздо большую возможность адаптации под нужные конкретного производства, в связи с чем встает задача получения исходной информации для разработки или адаптации информационной системы.
Разработка большой и сложной системы не может быть завершена за один подход — итерацию. Это может быть связано как с большой сложностью самой системы, так и со сложностью ее адаптации. Тем не менее, возможно уменьшить объем работы для разработчиков за счет повторного использования кода из одного проекта в другом. Для того, чтобы выявить возможность повторного использования кода необходимо найти требования, которые данный код реализуют. Такие требования очень часто встречаются в продуктах, автоматизирующих одну и ту же предметную область на разных организациях, например, бухгалтерский учет или документооборот. Задача повторного использования требований является одной из задач решаемых управлением требований.
Управление требованиями, выработка требований и определение требований — краеугольные камни успеха любого IT-проекта.
По данным исследования, проведенного IBM в области IT, 60% затрат времени организации-разработчики программного обеспечения несут в результате неэффективного подхода к управлению требованиями. В организациях, не располагающих достаточными возможностями бизнес-анализа, проекты в три раза чаще заканчиваются неудачей, чем успехом. При правильном определении требований и управлении ими перерасходы по проекту можно снизить на 20% благодаря сокращению числа неточных, неполных и упущенных требований.
Управление требованиями
Перед тем, как управлять требованиями разберемся, что такое требование и что такое управление требованиями и зачем это нужно.
Управление требованиями — процесс, включающий идентификацию, выявление, документацию, анализ, отслеживание, приоретизацию требований, достижение соглашений по требованиям и затем управление изменениями и уведомление заинтересованных лиц. Управление требованиями — непрерывный процесс на протяжении всего жизненного цикла продукта.
Требование — это любое условие, которому должна соответствовать разрабатываемая система или программное средство. Требованием может быть возможность, которой система должна обладать и ограничение, которому система должна удовлетворять.
Распространенное программное обеспечение для управления требованиями
В настоящее время широкое распространение получили такие системы управления требованиями как IBM Rational RequisitePro, Telelogic DOORS, Sybase PowerDesigner и Borland Caliber RM.
Приведу краткие переводы основных функциональных возможностей приведенных систем, взятые с сайтов производителей.
IBM Rational Requisite Pro
IBM Rational/Telelogic DOORS
IBM Rational/Telelogic DOORS — семейство решений для управления требованиями и создания сложных наукоемких изделий (авиа, судостроение, поезда, ракеты, автомобили т.п.).
Первоначально DOORS разрабатывался только как средство управления требованиями в процессе разработки программного обеспечения. Однако идеи, заложенные в DOORS, оказались успешными и в настоящий момент система используется даже в кампаниях, которые не имеют отношения к разработке программного обеспечения, но вынуждены контролировать большой объем взаимосвязанной информации, например, при разработке инженерных систем.
Borland Caliber RM
Borland Caliber RM – это корпоративная система управления требованиями, которая облегчает совместную работу, что позволяет группам разработчикам подходить к вехам проекта вовремя и с запланированными затратами. Borland Caliber RM также помогает командам разработчиков удостовериться, что разрабатываемое приложение удовлетворяет пожеланиям конечных пользователей за счет непрерывного сбора пожеланий на всех этапах жизненного цикла от аналитиков, разработчиков, тестировщиков и других заинтересованных в проекте лиц.
Другое ПО
Новый подход к управления требованиями
Как можно понять из приведенного выше обзора программного обеспечения для управления требованиям все оно базируется на одном принципе — человек, а в данном случае, аналитик, вводит требование в систему, смотрит, нет ли такого требования в системе уже. Если требование в той или иной формулировке уже присутствует в системе, то заново его не заносит, а отмечает, как дублирующее. В связи с тем, что поиск схожих требований вручную является сложной и трудозатратной задачей, которая требует постоянного участия аналитика, то в процессе управления требованиями именно ее стоит автоматизировать в первую очередь.
Чтобы реализовать возможность поиска и повторного использования требований необходима методика идентификации требований, представленных текстом на естественном языке. Тогда, представив требование не только как текст, но и совокупность некоторых концептов или лингвистических переменных станет возможным не только выполнять поиск сходных требований, но и использовать повторно созданные в процессе реализации требования артефакты. Под артефактами в данном случае не стоит понимать только исходный код, который реализует требование, но и жизненный цикл, которое оно прошло, т.е. код не всегда можно использовать повторно из-за специфики задач, но можно получить консультацию у его разработчиков. При разработке нескольких продуктов для одной предметной области это становится актуальной задачей. Например, при адаптации системы электронного документооборота на нескольких предприятиях часто возникает ситуация, что на разных предприятиях разные документы проходят одни и те же маршруты в процессе жизненного цикла и функциональность, которая реализует эти маршрутры может быть использована повторно, пусть и без полного копирования.
Предположим, что следующие требования описывают маршруты документов соответственно на предприятиях А и Б:
А —
Б —
Здесь видно, что под F и А имеются в виду документы, а B, C, D, E — их маршруты.
Рассчитав расстояние Хэмминга между этими двумя требованиями мы получим единицу, так как они различны только в одной позиции и, следовательно, при реализации требования Б стоит обратить внимание на требование А и его реализацию. Естественно, решение о повторном использовании принимает уже разработчик или другое лицо, принимающее решение, но уже хорошо, когда есть варианты, где можно подсмотреть реализацию.
Всем спасибо за внимание, жду комментариев.