«Доброе утро, Мария. Я — Фил, аналитик требований к новой информационной системе для сотрудников, которую мы собираемся разрабатывать для вас. Спасибо, что согласились стать сторонником продукта этого проекта. Ваша информация нам очень пригодится. А теперь расскажите мне, что же вам все-таки нужно?»
«Гм, что же мне нужно, — размышляет Мария. — Не представляю, с чего и начать. Ну, новая система должна работать намного быстрее предыдущей. Потом, вы же знаете, как старая система зависает, если имя какого-либо сотрудника оказывается слишком длинным — нам приходится обращаться в службу поддержки, чтобы они ввели имя. В новой системе длинные имена должны обрабатываться без сбоев. Да, согласно новому закону, нам нельзя использовать номера социального страхования в качестве идентификаторов сотрудников, и с вводом новой системы в эксплуатацию нам придется заменить все эти данные. Новые идентификаторы предполагается сделать шестизначными числами. Также пригодилась бы функция отчета о времени, затраченном каждым сотрудников в текущем году на обучение. А еще мне хотелось бы получить возможность менять фамилию сотрудников, даже если их семейное положение осталось прежним».
Фил добросовестно записал все пожелания Марии, но его голова пошла кругом. Он не знал, что делать с этой информацией, и не имел ни малейшего представления, что же передать разработчикам. «Ну что ж, — подумал он, — если Мария хочет, чтобы мы это сделали, полагаю, нам придется это сделать».
Сердце процесса формулирования требований — их выявление (elicitation), когда потребности и ограничения высказывают лица, заинтересованные в проекте. Цель — обозначить требования пользователей, которые занимают средний уровень в трехступенчатой модели требований к ПО (подробнее об этом в главе 1, два других уровня — бизнес-требования и функциональные требования). Это задачи, которые пользователям необходимо выполнять средствами системы, а также представления пользователей об эффективности, удобстве и простоте работы с системой и других атрибутах качества системы. В этой главе обсуждаются общие принципы эффективного выявления требований.
Аналитику необходима структура для систематизации массива информации, полученной в процессе выявления требований. Просто задавая пользователям вопрос: «Чего вы хотите?», вы получите массу неупорядоченной информации, в которой легко утонуть. Вопрос: «Что вам требуется делать?» — гораздо лучше. В главе 8 рассказывается как с помощью таких приемов, как варианты использования продукте или построение таблицы откликов на события, создать структуру для упорядочения пользовательских требований.
Результат этапа формулирования требований — согласованное представление о потребностях всех заинтересованных в проекте лиц. Теперь разработчикам гораздо легче предлагать альтернативные способы удовлетворения этих потребностей. Те, кто занимается выявлением требований, не должны поддаваться искушению немедленно приступить к проектированию системы — до того момента, как проблема станет абсолютно ясной. В противном случае готовьтесь к значительной переработке проекта по мере детализации требований, Концентрация на задачах пользователей, а не на интерфейсе, внимание к ключевым потребностям, а не к пожеланиям позволяет команде не отвлекаться на детали архитектуры — сейчас это несколько преждевременно.
Для начала подумайте, как вы собираетесь выявлять требования к проекту. Даже простой план повышает шансы на успех и делает более реалистичными ожидания всех заинтересованных лиц. Только четко сформулировав потребности, касающиеся ресурсов, графика и выпуска, можно избежать того, что лиц, участвующих в выявлении требований, отзовут для исправления ошибок или выполнения другой работы. План должен отражать:
· цели выявления требований (например, проверка рыночных данных, исследование вариантов использования или разработка подробного набора функциональных требований к системе);
· стратегии и способы выявления требований (например, сочетание опросов, семинаров, встреч с клиентами, интервью и других приемов с возможным использованием различных подходов для разных групп заинтересованных лиц);
· результаты выявления требований (например, перечень вариантов использования продукта, подробная спецификация требований к программному обеспечению, анализ результатов опроса или спецификация атрибутов качества и производительности);
· график и смету ресурсов (определите, кто из разработчиков и клиентов будет участвовать в различных операциях по выявлению требований; примерно оцените усилия и время на выявление требований);
· риски, связанные с выявлением требований (укажите факторы, которые могут нарушить график работ по выявлению требований, оцените опасность каждого фактора и решите, как смягчить его или управлять им).
Выявление требований
Возможно, выявление требований — самый трудный, важный, подверженный ошибкам и требующий интенсивного общения этап разработки ПО. Как вы уже знаете из главы 2, эта процедура может оказаться успешной только при условии сотрудничества клиентов и разработчиков. Аналитик должен создать атмосферу, благоприятную для тщательного исследования обусловленного продукта. Чтобы облегчить общение, используйте лексику предметной области, а не прессингуйте клиентов компьютерным жаргоном. Не полагайтесь на то, что все участники одинаково понимают важные термины предметной области, создайте словарь. Однако объясните клиентам, что обсуждение возможной функциональности — это еще не обязательство включить ее в продукт. Этот этап обособлен от анализа приоритетов, осуществимости и ограничений, налагаемых реальностью. Заинтересованным в проекте лицам необходимо расставить приоритеты в списке «голубых грез», чтобы проект не стал рыхлым и бесполезным.
Мастерство управления дискуссией по выявлению требований приходит с опытом, очень помогают в таком деле тренинги, где слушатели учатся брать интервью, общаться в группах, разрешать конфликтные ситуации и т.д. Как аналитику, вам придется «нырнуть» в поток требований клиента и, «опустившись поглубже», разобраться в его истинных потребностях. Просто задав несколько раз вопрос типа «Почему?», вы сможете перейти от обсуждения уже существующего решения к выявлению проблемы. Вопросы, допускающие несколько вариантов ответа, помогут вам разобраться в бизнес-процессах и понять, как новая система повысит их эффективность. Поинтересуйтесь, какие задачи собираются выполнять пользователи, и как они будут работать с системой. Вообразите, что вы обучаетесь служебным обязанностям пользователя или непосредственно выполняете их под его руководством. Какие задачи вам придется решить? Какие вопросы у вас возникают. Другой подход — влезть в «шкуру» новичка, которого обучает опытный пользователь. Вы задаете массу вопросов, а он управляет беседой, выбирая важную, с его/ее точки зрения, тему для обсуждения.
Попробуйте метод исключений. Что мешает пользователю успешно выполнить задачу? Как система должна реагировать на различные ошибочные условия? Задавайте вопросы, начинающиеся со слов: «А что еще могло бы...», «Что произойдет, когда...», «Вам когда-нибудь требовались...», «Где вы получаете...», «Почему вы делаете (или не делаете)...» и «А кто-нибудь когда-либо...». Задокументируйте источник каждого требования, чтобы, если потребуется, понять их причину и проследить, на каких же потребностях клиентов основываются те или иные направления разработки.
Когда вы разрабатываете следующую версию системы, попросите пользователей припомнить три вещи, которые раздражают их сейчас больше всего. Этот вопрос поможет вам понять, почему же систему следует менять. При этом также становится ясно, чего же ждут пользователи от новой системы. Как и при любой модификации, неудовлетворение настоящим дает отличную пищу для принятия нового.
Попытайтесь вытащить на «свет Божий» все предположения клиентов и разрешить конфликты. Читайте между строк, чтобы определить те возможности или характеристики, которые клиенты полагают само собой разумеющимися и даже не считают нужным обрисовать. Gause и Weinberg (1989) предлагают использовать бесконтекстные вопросы (context-freequestions), узкоспециализированные вопросы и вопросы, допускающие разные толкования, чтобы выявить информацию о бизнес-проблемах и их возможных решениях. Реакция клиентов на такие вопросы, как «Какой уровень точности необходим в продукте?» или «Почему вы не согласны с ответом Мигеля?", иногда более действенны, чем вопросы с ответами типа «да/нет» или «А/В/С».
В процессе сбора информации работающий творчески аналитик не только фиксирует слова клиента, но и подкидывает пользователям новые идеи и предлагает альтернативы. Иногда пользователи не представляют, какие возможности готовы предоставить разработчики; они страшно обрадуются, если вы предложите функциональность, которая сделает систему особенно удобной. В тех случаях, когда пользователи не способны ясно выразить свои потребности, аналитику стоит понаблюдать за их работой, чтобы самому разобраться, какие операции следует автоматизировать. Отлично, когда аналитикам удается выйти за рамки, ограничивающие мышление людей слишком тесно связанных с конкретной предметной областью. Ищите удобные случаи повторно использовать функциональность, которая уже реализована в другой системе.
Интервью с отдельными потенциальными пользователями или с группами — традиционный источник информации при сборе требований, касающихся как коммерческих продуктов, так и информационных систем. [О проведении интервью с пользователями см. Beyer и Holtzblatt (1998), Wood и Silver (1995), а также McGraw и Harbison 97).] Вовлечение пользователей в процесс сбора информации — это способ получить поддержку, в том числе и финансовую, проекта. Попытайтесь понять, из чего следуют конкретные требования пользователей. Поэтапно рассмотрите работу пользователей и постарайтесь понять ее логику. Блок-схемы и деревья решений позволяют отобразить логические пути принятия решений. Убедитесь, что все понимают, почему система должна выполнять конкретные функции. Иногда предложенные требования отражают устаревшие или неэффективные бизнес-процессы, которые не следует встраивать в новую систему.
После каждого интервью документируйте элементы, обсуждавшиеся группой, и попросите интервьюируемых просмотреть список и внести исправления. Просмотр на ранних стадиях необходим для успешного сбора требований, поскольку только те люди, которые эти требования предоставили, могут судить, правильно ли они зафиксированы. В дальнейшем также не отказывайтесь от обсуждений — это позволит разрешить все противоречия и заполнить пробелы.
Польза семинаров
Аналитики требований часто проводят совместные семинары, упрощающие сбор информации о требованиях. Это позволяет весьма эффективно наладить связи между пользователями и разработчиками (Keil и Carmel 1995). Основная задача ответственного за мероприятие сотрудника — создать условия для успешного выполнения задачи; именно он планирует семинар, выбирает участников и следит, чтобы обсуждение проводилось продуктивно. Если вы собираетесь применять новые технологии сбора требований, ответственным за первый семинар следует назначить стороннего сотрудника — не из вашей команды. В этом случае аналитик сможет полностью сосредоточиться на обсуждении. Пригласите также секретаря, чтобы он фиксировал все идеи, возникающие в ходе обсуждения.
Согласно одному из источников, «Организация какого-либо мероприятия — искусство управления людьми в ходе этого мероприятия, которое позволяет достичь согласованных решений в атмосфере сотрудничества, высокопроизводительного труда и заинтересованности в результатах своей работы» (Sibbet, 1994). О семинарах, упрощающих сбор требований, подробно рассказано втруде Ellen Gottesdiener (2002) «Requirements by Collaboration» (Выявление требований с помощью сотрудничества). Gottesdiener описывает спектр приемов и средств для облегчения семинаров. Вот некоторые из них.
Определите основные правила. Участники должны договориться об основных правилах проведения семинаров (Gottesdiener, 2002). Например, таких:
· своевременно начинать и заканчивать семинар;
· не опаздывать после перерывов;
· не проводить несколько обсуждений одновременно;
· следить, чтобы каждый принимал участие в работе;
· комментировать и критиковать решение, а не личность.
Придерживайтесь границ проекта. Чтобы удостовериться, что предлагаемые пользовательские требования не выходят за текущие границы проекта, используйте документ об образе и границах проекта.
Следите, чтоб на каждом семинаре уровень обобщения соответствовал выбранным целям. Периодически участники могут углубляться в обсуждения несущественных деталей. На это уходит масса времени, которое на начальном этапе работы следует потратить на прояснение пользовательских требований — время деталей наступит позже. Задача организатора — по мере необходимости возвращать участников к теме обсуждения.
| Ловушка Избегайте преждевременного углубления в детали. Фиксируя мельчайшие подробности того, что люди уже понимают, вы не снизите риски, остающиеся из-за размытости требований. |
Пользователи легко переходят к обсуждению того, где в отчете или диалоговом окне следует разместить элементы, даже еще до того, как разработчики согласятся с поставленными задачами. Если вы включите данные детали в требования, то в некоторой степени ограничите процесс разработки. К разработке пользовательского интерфейса следует приступать позднее, хотя предварительные наброски интерфейса полезны на любом этапе при иллюстрации возможных способов реализации требований. Проверка осуществимости на ранних стадиях, требующая определенной разработки, значительно снижает риски.
Фиксируйте темы для дальнейшего обсуждения. На семинаре всплывает масса случайных, но важных сведений: атрибуты качества, бизнес-правила, идеи по разработке пользовательского интерфейса, ограничения и т.п. Запишите их на плакатах простейшим способом, — так вы не потеряете их и продемонстрируете уважение участнику, высказавшему их. Не отвлекайтесь на обсуждение деталей, не относящихся к теме дискуссии, если только они не окажутся важными, например бизнес-правилом, которое ограничивает варианты использования.
Ограничивайте некоторые дискуссии по времени. Организатор семинара имеет право ограничить время обсуждения каждой темы, скажем, первоначально — 30 минут на каждый вариант использования. Возможно, некоторые дискуссии придется завершить позднее, но жесткие временные рамки помогают не тратить времени больше, чем запланировано на первые обсуждения темы, в результате чего может не хватить времени для обсуждения остальных тем,
Не увеличивайте размер команды и тщательно отбирайте участников. Небольшие группы работают намного быстрее. Семинары, число активных участников которых превышает пять или шесть человек, могут забуксовать, вылиться в отвлеченные разговоры и даже ссоры. Попробуйте одновременного проводить несколько семинаров — это позволит исследовать требования различных классов пользователей. В обсуждении должны участвовать сторонник продукта и другие представители пользователей, возможно, эксперт в данной предметной области, аналитик требований и разработчик. Допуском к участию в семинарах по сбору информации являются знания, опыт и право принимать решения.
| Ловушка Не допускайте в процессе сбора информации обсуждения посторонних тем, например подробностей дизайна. |
Вовлекайте в обсуждение каждого. Иногда участники самоустраняются от обсуждения, например, расстроившись из-за того, что не представляют себе ценность системы. Возможно, их идеи не воспринимают серьезно, поскольку другим участникам их концепции кажутся неинтересными или группа не хочет отвлекаться от текущей дискуссии. Возможно, аутсайдер не уверен в себе и уступил право голоса более активным сотрудникам или главному аналитику. Организатору семинара необходимо следить за языком телодвижений, чтобы разобраться в причинах замкнутости того или иного участника, и попытаться снова вовлечь его в работу. Ведь интуитивное представление каждого может оказаться очень ценным.
| У семи нянек... Работа семинаров по сбору информации о требованиях большим количеством участников может продвигаться слишком медленно. Так, моя коллега Дебби, занимавшаяся организацией семинара, где разбирались варианты использования Web-продукта, была расстроена именно этим. Двенадцать участников длинно обсуждали детали и не могли договориться. Однако темпы значительно выросли, когда Дебби сократила группу до шести человек, в число которых вошли аналитик, клиент, системный архитектор, разработчик и дизайнер. Объем обсуждаемой информации стал меньше, но темпы работы более чем компенсировали эту потерю. Участникам семинара следует по его окончании обменяться информацией с коллегами, не приглашенными на дискуссию, и обсудить высказанные идеи на следующей встрече. Не следует ожидать, что ваши клиенты представят краткий, полный и хорошо организованный список своих потребностей. Аналитикам придется классифицировать мириады бит полученных данных о требованиях, чтобы их удалось задокументировать и использовать соответствующим образом. На рис. 7-1 показано девять таких категорий требований. |
Некоторая информация не попадает ни в одну из этих категорий, в том числе:
· требования, не относящиеся к разработке ПО, например необходимость обучения пользователей работе с новой системой;
· ограничения проекта, например затраты или ограничения, налагаемые графиком (в отличие от ограничений, касающихся дизайна или реализации);
· предположения;
· требования, касающиеся данных, которые зачастую связаны с определенной функциональностью системы (вы сохраняете данные на компьютере только для того, чтобы позднее извлечь их);
· дополнительная информация хронологического или описательного характера, а также относящаяся к управлению контекстом.
Рис. 7-1. Классификация требований клиента
Далее в этом разделе я привожу некоторые типичные для дискуссий фразы, по которым вам будет легче выполнить классификацию данных.
Бизнес-требования. Вся информация, описывающая финансовые, рыночные или другие отношения коммерческого характера, которые клиенты или разработчики собираются получить от использования продукта, относится к бизнес-требованиям. Обращайте внимание в разговоре на такие высказывания о преимуществах, которые покупатели или пользователи ПО хотят получить:
· «Увеличить рыночную долю на Х%»;
· «Сэкономить Y$ в год за счет сокращения использования электроэнергии, которая сейчас расходуется неэффективно»;
· «Сэкономить Z$ за счет сокращения расходов на поддержание устаревшей системы W».
Варианты использования или сценарии. Основные утверждения пользователей о преследуемых ими целях или задачах бизнеса (коммерческих задачах) называются вариантами использования; единственный задокументированный вариант называется сценарием. Работайте с пользователями, чтобы свести сценарии в более общие варианты использования. Часто удается выявить варианты использования, попросив клиентов описать их рабочий процесс. Другой способ — выяснить у заказчиков, какие цели они ставят перед собой, усаживаясь за работу. Сотрудник, который скажет: «Мне нужно сделать то-то и то-то», вероятнее всего опишет конкретный вариант использования, например:
· «Мне нужно напечатать почтовую этикетку для пакета»;
· «Мне нужно управлять очередью образцов химических веществ отобранных для анализа»;
· «Мне необходимо откалибровать контроллер насоса».
Бизнес-правила. Если клиент заявляет, что только определенные классы пользователей могут выполнять определенные действия при определенных условиях, он, возможно, описывает бизнес-правило. В случае с Chemical Tracking System такое бизнес-правило может звучать следующим образом: «Химик может заказать вещество из списка опасных химикатов уровня 1 только при условии, что в настоящее время действует его допуск на работу с опасными соединениями». Вы можете сформулировать некие функциональные требования к ПО, чтобы определить конкретное правило, например запись в БД о допуске сотрудника должна быть доступной Chemical Tracking System. Как уже говорилось, бизнес-правила и бизнес-требования — не одно и то же. Вот несколько фраз, по которым вы можете догадаться, что пользователь описывает именно бизнес-правила:
· «Должны совпадать с таким-то постановлением или корпоративной политикой»;
· «Должны соответствовать некоему стандарту»;
· «Если выполняется такое-то условие, то происходит то-то и то-то»;
· «Расчеты производятся по следующей формуле».
Дополнительная информация
Развернутые примеры бизнес-правил в главе 9.
Функциональные требования. Функциональные требования описывают ожидаемое поведение системы при определенных условиях и действия, которые система позволит выполнять пользователям. Функциональные требования проистекают из системных требований, пользовательских требований, бизнес-правил и других источников, составляющих основу спецификации требований к программному обеспечению. Ниже перечислены примеры функциональных требований, которые вы можете услышать от пользователей:
· «Если давление превышает 40,0 фунтов на квадратный дюйм, должен загореться предупредительный световой сигнал»;
· «У пользователя должна быть возможность сортировать список проекта в прямом и обратном алфавитном порядке»;
· «Когда кто-либо представляет на рассмотрение новую идею, система отправляет сообщение по электронной почте Idea Coordinator».
Эти высказывания демонстрируют, как пользователи обычно представляют функциональные требования, однако их нельзя записать непосредственно в спецификацию требований к программному обеспечению. В первом случае следует заменить «должен загореться» на «загорится», чтобы стало ясно, что включение предупредительного светового сигнала крайне важно. Второй пример показывает требования пользователя, а не требования к системе. Требование к системе — предоставить пользователю возможности выполнить сортировку.
| Дополнительная информация Советы тем, кто хочет написать хорошие функциональные требования — в главе 10. |
Атрибуты качества. Утверждения, насколько хорошо система соответствует определенному режиму работы или позволяет пользователям выполнять конкретные действия, называются атрибутами качества. Обращайте внимание на слова, которыми пользователи описывают желаемые характеристики системы: быстрая, легкая, интуитивно понятная, удобная для пользователя, устойчивая к сбоям, надежная и эффективная. Вам придется поработать с пользователями, чтобы понять, что именно они имеют в виду под этими неясными и субъективными терминами, и зафиксировать четкие, поддающиеся проверке атрибуты качества, как описано в главе 12.
Требования к внешнему интерфейсу. Требования в этом классе описывают связь вашей системы с остальным миром. В спецификацию требований к программному обеспечению необходимо включить разделы, касающиеся взаимодействия с пользователями, оборудованием и другими системами ПО. Вот примеры фраз, указывающих, что клиент описывает внешние требования к интерфейсу:
· «Должны распознавать сигналы от определенного устройства»;
· «Должна отправлять сообщение такой-то системе»;
· «Должны быть в состоянии читать (или записывать) файлы в определенном формате»;
· «Должна контролировать такой-то элемент оборудования»;
· «Пользовательский интерфейс должен соответствовать определенному стандарту».
Ограничения. Ограничения, касающиеся дизайна и реализации, официально ограничивают возможности, доступные разработчику. Для устройств со встроенным ПО часто необходимо учитывать физические ограничения, такие, как размер, вес и сквозные соединения в плате. Записывайте разумное обоснование для каждого ограничения, чтобы все участники проекта знали его источник и понимали его обоснованность. Действительно ли ограничением является требование разместить устройство в определенном пространстве? Или это желание, например, просто получить портативный компьютер с минимальным весом?
Введение излишних ограничений препятствует выработке лучшего решения. Из-за ограничений также не всегда удается использовать стандартные компоненты, доступные в продаже. Требование применять определенную технологию также не всегда достижимо — зачастую технология устарела или недоступна в результате прогресса. Однако некоторые ограничения могут оказаться полезными при достижении целей, связанных с атрибутами качества. Например, удается улучшить переносимость ПО путем использования только стандартных команд языка программирования и запрета на использование расширений, присущих только определенным производителям. Вот какие ограничения может выдвинуть клиент:
· «Размер файлов, представленных в электронном виде, не должен превышать 10 Мб»;
· «В браузере для всех безопасных транзакций следует использовать 128-битную кодировку»;
· «В БД необходимо применять механизм периода выполнения Framalam».
А это примеры других фраз, указывающих на то, что клиент описывает ограничения проектирования или реализации:
· «Должна быть написана на определенном языке программирования»;
· «Не может требовать более такого-то объема памяти»;
· «Должна функционировать согласованно (или быть совместима) с такой-то системой»;
· «Должна использовать определенный элемент управления пользовательского интерфейса».
Как и в случае с функциональными требованиями, задача аналитика шире, чем просто запись высказываний пользователя в спецификацию требований к программному ПО. Неудачные слова, такие, как согласованно и последовательно, необходимо уточнять, а в ограничения следует формулировать достаточно ясно, чтобы разработчики смогли принять их как руководство к действию. Поинтересуйтесь причинами ограничений, проверьте, насколько они аргументированы, и задокументируйте обоснование для включения этого ограничения в качестве требования.
Определения данных. Каждый раз, когда клиенты описывают формат, тип данных, допустимые значения или значение по умолчанию для элемента данных или структуры бизнес-данных, они дают определения данных. Например, «Почтовый индекс в США состоит из пяти цифр, за которым следует дефис и еще четыре цифры — по умолчанию 0000». Составьте словарь данных, своего рода основной справочник, который команда сможет использовать в процессе всей разработки и поддержания продукта.
| Дополнительная информацияПодробнее о словарях данных - в главе 10 |
Определения данных иногда становятся источниками функциональных требований, которые пользователи не запросили напрямую. Что произойдет, когда номер заказа, состоящий из шести цифр, превысит 999999? Разработчикам необходимо знать: как поведет себя система в таких случаях. Откладывая проблемы, касающиеся данных, вы только усложняете их решение в будущем. (Помните проблему 2000 г.)
Идеи, касающиеся решений. Большинство информации, которую пользователи представляют как требования, подпадает под определение идей о решении. Те, кто описывают определенный способ взаимодействия с системой для выполнения определенного действия, представляют допустимое решение. Аналитику необходимо научиться преодолевать поверхностные формулировки и докапываться до сути идеи, которая и представляет собой требование. Например, функциональные требования, касающиеся паролей — лишь одно из возможных решений требования к безопасности,
Предположим, пользователь говорит: «Затем в раскрывающемся списке я выбираю штат, куда я хочу отправить посылку». Фрагмент «в раскрывающемся списке» тянет на решение. В этом случае благоразумный аналитик задаст вопрос: «Почему в раскрывающемся списке? Если пользователь ответит: «Мне просто кажется, так удобно», то непосредственно требование можно сформулировать примерно так: «Система позволит пользователю выбрать штат, куда он хочет отправить посылку». Однако пользователь может сказать: «Я предложил раскрывающийся список, потому что мы применяем этот элемент в других областях, и я хочу согласованности. Кроме того, так пользователь не сможет ввести непроверенные данные, и я думаю, что в этом случае удастся применить уже написанный код». Это отличные причины для выбора определенного решения. Однако следует помнить, что, записывая идею о решении в требование, вы тем самым налагаете ограничение по проектированию на это самое требование. Таким образом, реализация требования становится возможной только в одном варианте. Это не обязательно плохо или неправильно, просто убедитесь, что для ограничения есть убедительная причина.