Глава 7 как услышать голос клиента

«Хорошее утро, Мария. Я — Фил, аналитик требований к новой информационной совокупности для сотрудников, которую мы планируем разрабатывать для вас. Благодарю, что дали согласие стать приверженцем продукта этого проекта. Ваша информация нам весьма понадобится. А сейчас поведайте мне, что же вам все-таки необходимо?»

«Гм, что же мне необходимо, — думает Мария. — Не воображаю, с чего и начать. Ну, новая совокупность обязана трудиться намного стремительнее прошлее. Позже, вы же понимаете, как ветхая совокупность зависает, в случае, если имя какого-либо сотрудника оказывается через чур долгим — нам приходится обращаться в работу помощи, дабы они ввели имя. В новой совокупности долгие имена должны обрабатываться без сбоев. Да, в соответствии с новому закону, нам нельзя использовать номера социального страхования в качестве идентификаторов сотрудников, и с вводом новой совокупности в эксплуатацию нам нужно будет заменить все эти сведенья. Новые идентификаторы предполагается сделать шестизначными числами. Кроме этого понадобилась бы функция отчета о времени, затраченном каждым сотрудников в этом году на обучение. И вдобавок мне хотелось бы получить возможность поменять фамилию сотрудников, даже в том случае, если их домашнее положение осталось прошлым».

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

Сердце процесса формулирования требований — их обнаружение (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 мин. на любой вариант применения. Быть может, кое-какие дискуссии нужно будет завершить позднее, но твёрдые временные рамки оказывают помощь не тратить времени больше, чем запланировано на первые дискуссии темы, в следствии чего может не хватить времени для дискуссии остальных тем,

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

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

Некая информация не попадает ни в одну из этих категорий, а также:

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

Рис. 7-1. Классификация требований клиента

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

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

• «Расширить рыночную долю на Х%»;
• «Сэкономить Y$ в год за счет сокращения применения электричества, которая на данный момент расходуется неэффективно»;
• «Сэкономить Z$ за счет сокращения затрат на поддержание устаревшей совокупности W».

Варианты применения либо сценарии.Главные утверждения пользователей о преследуемых ими целях либо задачах бизнеса (коммерческих задачах) именуются вариантами применения; единственный задокументированный вариант именуется сценарием. Трудитесь с пользователями, дабы свести сценарии в более неспециализированные варианты применения. Довольно часто удается распознать варианты применения, попросив клиентов обрисовать их рабочий процесс. Второй метод — узнать у клиентов, какие конкретно цели они ставят перед собой, усаживаясь за работу. Сотрудник, что сообщит: «Мне необходимо сделать то-то и то-то», наверное обрисует конкретный вариант применения, к примеру:

• «Мне необходимо напечатать почтовую этикетку для пакета»;
• «Мне необходимо руководить очередью образцов веществ отобранных для анализа»;
• «Мне нужно откалибровать контроллер насоса».

Бизнес-правила.В случае, если клиент заявляет, что лишь определенные классы пользователей смогут делать определенные действия при определенных условиях, он, быть может, обрисовывает бизнес-правило. При с Chemical Tracking System такое бизнес-правило может звучать следующим образом: «Химик может заказать вещество из перечня страшных химикатов уровня 1 лишь при условии, что на данный момент действует его допуск на работу с страшными соединениями». Вы имеете возможность сформулировать некие функциональные требования к ПО, дабы выяснить конкретное правило, к примеру запись в БД о допуске сотрудника должна быть дешёвой Chemical Tracking System. Как уже говорилось, бизнес-требования и бизнес-правила — не одно да и то же. Вот пара фраз, по которым вы имеете возможность додуматься, что пользователь обрисовывает конкретно бизнес-правила:

• «Должны совпадать с таким-то распоряжением либо корпоративной политикой»;
• «Должны соответствовать некоему стандарту»;
• «В случае, если выполняется такое-то условие, то происходит то-то и то-то»;
• «Расчеты производятся по следующей формуле».

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

• «В случае, если давление превышает 40,0 фунтов на квадратный дюйм, обязан загореться предупредительный световой сигнал»;
• «У пользователя должна быть возможность сортировать перечень проекта в прямом и обратном алфавитном порядке»;
• «В то время, когда кто-либо воображает на рассмотрение новую идею, совокупность отправляет сообщение по email Idea Coordinator».

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

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

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

• «Должны распознавать сигналы от определенного устройства»;
• «Обязана отправлять сообщение такой-то совокупности»;
• «Должны быть в состоянии просматривать (либо записывать) файлы в определенном формате»;
• «Обязана осуществлять контроль такой-то элемент оборудования»;
• «Интерфейс пользователя обязан соответствовать определенному стандарту».

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

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

• «Размер файлов, представленных в электронном виде, не должен быть больше 10 Мб»;
• «В браузере для всех надёжных транзакций направляться применять 128-битную кодировку»;
• «В БД нужно использовать механизм периода исполнения Framalam».

А это примеры вторых фраз, показывающих на то, что клиент обрисовывает ограничения проектирования либо реализации:

• «Должна быть написана на определенном языке программирования»;
• «Не имеет возможности потребовать более такого-то количества памяти»;
• «Обязана функционировать согласованно (либо быть совместима) с такой-то совокупностью»;
• «Обязана применять определенный элемент управления интерфейса пользователя».

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

Определения данных.Любой раз, в то время, когда клиенты обрисовывают формат, тип данных, допустимые значения либо значение по умолчанию для элемента данных либо структуры бизнес-данных, они дают определения данных. К примеру, «Почтовый индекс в Соединенных Штатах складывается из пяти цифр, за которым направляться дефис и еще четыре цифры — по умолчанию 0000». Составьте словарь данных, собственного рода главной справочник, что команда сможет применять в ходе всей поддержания и разработки продукта.

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

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

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

Как слышать голос Бога. №1 «Расцвет пробуждения» (7)

Интересные записи:

• Глава 9. близкий человек. 2 глава
• Глава 9. близкий человек. 5 глава
• Глава 9. близкий человек. 6 глава
• Глава 9. ряд практических вопросов 3 глава