Бизнес требования это функциональные требования

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

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

Что такое бизнес-требования

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

Что входит в бизнес-требования

Как бизнес-требования влияют на итоговый продукт?

Часто бизнес-требования влияют на способ реализации продукта. Рассмотрим несколько примеров.

Почему нужно конкретно и четко оформить бизнес-требования?

Четкое формулирование бизнес-требований:

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

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

Что такое функциональные требования?

Примеры функциональных требований:

Нефункциональные требования. Важные особенности

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

Нефункциональных требований очень много. Вот некоторые из них.

Кто собирает требования?

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

✔ Стороннее агентство, нанятое заказчиком

✔ Штатный аналитик заказчика

✔ Наша команда в рамках услуги “Проектирование”

Как происходит сбор требований?

Обычно сбор требований происходит через интервью, переписку или в специальных системах типа Notion, Trello и т. д. Приведем алгоритм сбора требований:

Кто участвует в сборе требований?

В зависимости от потребностей проекта, можно и нужно привлекать следующих заинтересованных лиц:

Вспомогательные материалы, предоставляемые заказчиком

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

Какие ошибки допускают заказчики в ходе сбора информации?

Насколько детализированными должны быть требования?

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

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

Как нужно: Скорость загрузки страницы составляет 2 секунды. Магазин остается производительным при нагрузке в 150 тысяч посетителей в день.

Рекомендации заказчику, пишущему требования

Желательно, чтобы заказчик, формирующий требования, писал максимально просто с четким наименование объектов (покупатель, вендор, администратор сайта) и результата. Лучше всего, в формате пользовательских сценариев. При этом, функциональные требования будут выглядеть как совокупность функций, объединенных по смыслу. Например, кейс «Зарегистрировать визит пациента в зубной кабинет» будет состоять из совокупности функций:

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

Выводы

Введение

В рамках предыдущих статей мы описали: область применения, методологические основы, пример архитектуры и структуры. В данной статье, я хотел бы рассказать как описывать процессы, о принципах сбора требований, чем отличаются бизнес требования от функциональных, как перейти от требований — к коду. Рассказать о принципах применения Вариантов Использования (Use Case) и как они нам могут помочь. Разобрать на примерах варианты реализации шаблонов проектирования Interactor и Service Layer.

Примеры приведенные в статье даны с использованием нашего решения LunaPark, оно поможет вам с первыми шагами в описанных подходах.

Отделяем функциональные требования от бизнес требований.

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

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

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

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

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

Тут можно выделить ряд характерных признаков, которые будут указывать, что это требования от бизнеса:

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

Функциональные требования — это Действия, которые система должна выполнить, для реализации бизнес-требований. Таким образом, функциональные требования связаны с разрабатываемым решением или программным обеспечением. Сформулируем функциональные требования для вышеуказанного примера:

• система должна отображать долготу и широту сотрудника через GPS/ГЛОНАСС;
• система должна отображать позиции сотрудников на карте;
• система должна позволять менеджерам отправлять уведомления своим подчиненным на местах.

Выделим следующие особенности:

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

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

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

Варианты использования (Use cases)

Реализация функциональных требований является, зачастую, самой сложной в коммерческих системах. В чистой архитектуре функциональные требования реализуются через слой Use Case.

Но для начала, я хочу обратится к первоисточнику. Ивар Якобсон — автор определения Use Case, один из авторов UML, и методологии RUP, в своей статье Use-Case 2.0 The Hub of Software Development выделяет 6 принципов применения Вариантов использования:

1. сделайте их простыми через повествование;
2. имейте стратегический план, осознайте картину целиком;
3. сфокусируйтесь на значении;
4. выстраивайте систему по слоям;
5. поставляйте систему пошагово;
6. удовлетворяйте потребности команды.

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

Простота через повествование

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

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

Данный принцип коррелирует с партерном Общий язык (Ubiques language) из DDD подхода.

Понимание картины в целом

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

Ивар Якобсон предлагает задействовать диаграмму вариантов использования, что очень удобно для сбора требований. Если требования собраны и ясны, то лучшим вариантом будет Контекстная карта (Context map) Эрика Эванса. Зачастую, Scrum подход интерпретируют так, что люди не тратят время на стратегический план, считая планирование, дальше чем на две недели, пережитком прошлого. Пропаганда Джеффа Сазерленда обрушилась на waterflow, а люди закончившие двухнедельные курсы подготовки скрам-мастеров, допущенные к управлению проектами, сделали свое дело. Но здравый смысл, осознает важность стратегического планирования. Не нужно делать детальный стратегический план, но он должен быть.

Фокус на значении

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

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

Далее автор приводит замечательную схему, на которую следует обратить самое пристальное внимание:

На схеме показан вариант использования, «Снятие наличных в банкомате». Самый простой способ достижения цели описывается в Основном Направлении (Basic flow). Другие случаи описываются как Альтернативные Направления (alternative flow). Эти направления помогают с повествованием, структурируют систему и помогают с написанием тестов.

Послойное построение

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

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

Эти идеи перекликаются с подходами гибкой разработки и с идеями Доменов (Domain).

Пошаговый вывод продукта на рынок

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

Удовлетворять потребности команды

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

Эрик Эванс в своей книге призывает не тратить много времени на описания всех процессов через UML. Достаточно использовать любые наглядные схемы. Разным командам, разным проектам требуется разная степень детализации, об это говорит и сам автор UML.

Реализация

В чистой архитектуре Робертом Мартином дается следующее определение Вариантов использования :

These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their Critical Business Rules to achieve the goals of the use case.

Попробуем воплотить эти идеи в код. Давайте вспомним схему из третьего принципа применения Вариантов использования и возьмем ее за основу. Рассмотрим действительно сложный бизнес-процесс: «Приготовление пирога с капустой».

Давайте попробуем его декомпозировать:

• проверить наличие продуктов;
• взять их со склада;
• замесить тесто;
• дать тесту подняться;
• подготовить начинку;
• сделать пирог;
• испечь пирог.

Всю эту последовательность мы реализуем через Интерактор (Interactor), а каждый шаг будет реализован через функцию или Функциональный объект (Functional Object) на Сервисном слое (Service Layer).

Последовательность действий (Interactor)

Я очень рекомендую начинать разработку сложного бизнес-процесса именно с Последовательности действий. Точнее не так, вы должны определить Доменную область, к которой относится бизнес-процесс. Уточнить все требования бизнеса. Определить все Сущности, которые задействованы в процессе. Задокументировать требования и определения каждой Сущности в базе знаний.

Расписать все на бумаге по шагам. Иногда потребуется Диаграмма последовательности (sequence diagram). Ее автор тот же, кто придумал Варианты использования (Use Case) — Ивар Якобсон. Диаграмма была придумана им, когда он разрабатывал систему обслуживания телефонных сетей для компании Эриксон, взяв за основу схему реле. Мне очень нравится эта диаграмма, и термин Sequence, на мой взгляд более выразителен, чем термин Interactor. Но ввиду большей распространенности последнего, будем использовать привычный термин — Interactor.

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

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

Шаблон проектирования Последовательности действий отвечает за:

• последовательность выполнения Действий;
• координацию передаваемых данных между Действиями;
• обработку ошибок совершаемых Действиями во время их выполнения;
• возвращение результата совокупности совершенных Действий;
• ВАЖНО: самая главная ответственность этого шаблона проектирования — реализация бизнес логики.

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

Вернемся к пирогу: попробуем описать процесс его приготовления через Interactor.

Реализация

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

module Kitchen
  module Sequences
    class CookingPieWithСabbage < LunaPark::Interactors::Sequence
      TEMPERATURE = Values::Temperature.new(180, unit: :cel)

      def call!
        Services::CheckProductsAvailability.call   list: ingredients
        dough   = Services::BeatDough.call         from: Repository::Products.get(beat_ingredients)
        filler  = Services::MakeСabbageFiller.call from: Repository::Products.get(filler_ingredients)
        pie     = Services::MakePie.call           dough, with: filler
        bake    = Services::BakePie.new            pie,   temp: TEMPERATURE
        sleep 5.min until bake.call
        pie  
      end

      private

      attr_accessor :beat_ingredients, :filler_ingredients
      attr_accessor :pie

      def ingredients_list
        beat_ingredients_list + filler_ingredients_list
      end
    end
  end  
end

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

Также, мы легко можем описать процесс выпечки рыбного пирога, заменив MakeСabbageFiller на MakeFishFiller. Тем самым, мы очень быстро меняем бизнес-процесс, без существенных доработок кода. И также, мы можем оставить обе Последовательности одновременно, масштабируя бизнес-кейсы.

Договоренности

• Метод call! является обязательным методом, он описывает порядок Действий.
• Каждый параметр инициализации может описываться через сеттер или attr_acessor:

class Foo < LunaPark::Interactors::Sequence
  # ...
  private
  attr_accessor :bar 
end

Foo.call(bar: 42)

• Остальные методы должны быть приватными.

Пример использования

beat_ingredients = [
  Entity::Product.new :flour,   500, :gr,
  Entity::Product.new :oil,     50,  :gr,
  Entity::Product.new :salt,    1,   :spoon,
  Entity::Product.new :milk,    150, :ml,
  Entity::Product.new :egg,     1,   :unit,
  Entity::Product.new :yeast,   1,   :spoon
]

filler_ingredients = [
  Entity::Product.new :cabbage, 500, :gr,
  Entity::Product.new :salt,    1,   :spoon,
  Entity::Product.new :pepper,  1,   :spoon
]

cooking = CookingPieWithСabbage.call(
  beat_ingredients:   beat_ingredients, 
  filler_ingredients: filler_ingredients
)

# В случае успеха:
cooking.success?     # => true
cooking.fail         # => false
cooking.fail_message # => ''
cooking.data         # => Entity::Pie

# Если пирог сгорел:
cooking.success?     # => false
cooking.fail         # => true
cooking.fail_message # => 'The pie burned out'
cooking.data         # => nil

Процесс представлен через объект и мы имеем все необходимые методы для его вызова — прошел ли вызов успешно, возникла ли какая-то ошибка в процессе вызова, и если произошла, то какая?

Обработка ошибок

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

Interactor перехватывает все ошибки унаследованные от класса LunaPark::Errors::Processing.

Как нам уследить за пирогом? Для этого определим ошибку Burned в Действие BakePie.

module Kitchen
  module Errors
    class Burned < LunaPark::Errors::Processing; end
  end
end

И во время выпечки, проверим, что наш пирог не сгорел:

module Kitchen
  module Services 
    class BakePie < LunaPark::Callable   
      def call
          # ...
          rescue Errors::Burned, 'The pie burned out' if pie.burned?
          # ...
      end    
    end
  end
end

В этом случае сработает перехватчик ошибок, и мы сможем разобраться с ними в Эндпоинтах.
Ошибки, не унаследованные от Processing, воспринимаются как системные и будут перехвачены на уровне сервера. Если не обозначенные другие условия, то пользователь получит 500 ServerError.

Практика использования

1. Старайтесь описывать все вызовы в методе call!

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

module Service
  class CookingPieWithСabbage < LunaPark::Interactors::Sequence
    def call!
      check_products_availability
      make_cabbage_filler
      make_pie
      bake
    end

    private  

    def check_products_availability
      Services::CheckProductsAvailability.call list: ingredients  
    end

    # ...
  end
end

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

class DrivingStart < LunaPark::Interactors::Sequence
  def call!
    Service::CheckEngine.call
    Service::StartUpTheIgnition.call car, with: key
    Service::ChangeGear.call         car.gear_box, to: :drive
    Service::StepOnTheGas.call       car.pedals[:right]
  end
end

2. По возможности используйте метод класса call

# good - Обычно, экземпляр класса Действия, редко используется. 
#        Логично использовать сокращенную запись.
Sequence::RingingToPerson.call(params)

# good - Тем не менее, есть возможность создавать экземпляр объекта Действиe,
#        что может быть полезно, когда нам нужно переиспользовать его, 
#        с учетом внутреннего состояния.
ring = Sequence::RingingToPerson.new(person)

unless ring.success?
  ring.call
  sleep 5.min
end

3. Не создавайте Функциональные объекты ради типизации кода, смотрите по ситуации

# bad - мы решили делать всю логику в Функциональных объектах, чтобы 
#       сделать более легкой Последовательность действий.

module Services
  class BuildUser < LunaPark::Callable
    def initialize(first_name:, last_name:, phone:)
      @first_name = first_name
      @last_name = last_name
      @phone = phone
    end

    def call
      Entity::User.new(
        first_name: first_name, 
        last_name: last_name,
        phone: phone 
      )
    end

    private
    attr_reader :first_name, :last_name, :phone
  end
end

module Sequences
  class RegisteringUser < LunaPark::Interactors::Sequence
    attr_accessor :first_name, :last_name, :phone

    def call!
      user = Service::BuildUser.call(first_name: first_name, last_name: last_name, phone: phone)
    end
  end
end

# good - не следует писать отдельный класс, действуем практичнее. 
#        Хотя при такой реализации следует задуматься о  тестировании, 
#        возможно необходимо вынести метод в Сервисный слой.

module Sequences
  class RegisteringUser < LunaPark::Interactors::Sequence
    attr_accessor :first_name, :last_name, :phone

    def call!
      user #...
    end

    private 
    def user
      @user = Entity::User.new(
        first_name: first_name, 
        last_name: last_name,
        phone: phone 
      )
    end
  end
end

Сервисный слой (Service Layer)

Порядок действий (Interactor), как мы говорили, описывает бизнес-логику на самом верхнем уровне. Сервисный слой (Service layer) уже раскрывает детали реализации функциональных требований. Если мы говорим о приготовлении пирога, то на уровне Порядка действий (Interactor) мы говорим просто «замешиваем тесто», не вдаваясь в детали как его замесить. Процесс замеса описывается на Сервисном уровне. Вернемся к первоисточнику, большой синей книге:

В прикладной предметной области бывают такие операции, которым нельзя найти естественное место в объекте типа Сущности (Entity) или Объекта-Значения (Value object). Они по своей сути являются не предметами, а видами деятельности. Но поскольку в основе нашей парадигмы моделирования лежит объектный подход, мы попробуем превратить их в объекты.

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

При выборе места реализации того или иного функционала, всегда пользуйтесь здравым смыслом. Ваша задача — сделать модель более выразительной. Разберем пример, «Нам нужно нарубить дрова» :

module Entities
  class Wood
    def chop
      # ...
    end
  end
end

Такой метод будет являться ошибкой. Дрова сами себя не нарубят, нам потребуется топор:

module Entities
  class Axe
    def chop(sacrifice)
      # ...
    end
  end
end

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

module Entities
  class Human
    def chop_firewood(wood, axe, chock)
      # ...
    end
  end
end

Как вы уже наверное догадались, это не самая удачная идея. Не все из нас занимаются рубкой дров, это не прямая обязанность человека. Мы часто видим насколько перегружены модели в Ruby on Rails, хранящие в себе подобную логику: получение скидки, добавление товара в корзину, снятие денег к балансу. Эта логика относится не к сущности, а к процессу в котором задействована эта сущность.

module Services
  class ChopFirewood
    # ...
  end
end

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

Функциональные объекты

Функциональный объект выполняет одно функциональное требование. В самом примитивном виде функциональный объект имеет один единственный публичный метод — call.

module Serivices
  class Sum
    def initialize(x, y)
      @x = x
      @y = y
    end

    def call
      x + y
    end  

    def self.call(x,y)
      new(x,y).call
    end

    private
    attr_reader :x, :y
  end
end

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

• Сервисный объект (Service) — объект, создает новый объект;
• Команда (Command) — изменяет текущий объект;
• Вахтер (Guard) — возвращает ошибку если, что-то пошло не так.

Сервисный Объект (Service)

В нашей реализации Service — реализует функциональное требование и всегда возвращает значение.

module KorovaMilkBar
  module Services
    class FindMilk < LunaPark::Callable
      GLASS_SIZE = Values::Unit.wrap '200g'

      def initialize(fridge:)
        @fridge = fridge
        end

      def call
          fridge.shelfs.find { |shelf| shelf.has?(GLASS_SIZE, of: :milk) }
        end

        private
        attr_reader :fridge
    end
  end
end 

FindMilk.call(fridge: the_red_one) # => #<Glass: ... >

Команда (Command)

В нашей реализации Command — выполняет одно Действие, изменяет объект, в случае успеха возвращает true. По факту, Команда не создает объект, а изменяет существующий.

module KorovaMilkBar
  module Commands
    class FillGlass < LunaPark::Callable    
      def initialize(glass, with:)
        @glass   = glass
        @content = with
      end

      def call
        glass << content
        true
      end

      private
      attr_reader :fridge
    end
  end
end 

glass  = Glass.empty
milk   = Milk.new(200, :gr)
glass.empty?                     # => true
FillGlass.call glass, with: milk # => true
glass.empty?                     # => false

Вахтер (Guard)

Вахтер, выполняет логическую проверку и в случае провала выдает ошибку обработки. Такой тип объекта никак не влияет на Основное направление, но переключает нас на Альтернативное направление, если что-то пошло не так.

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

module KorovaMilkBar
  module Guards
    class IsFresh < LunaPark::Callable  
      def initialize(product)
        @products = products
      end

      def call
        products.each do |product|
          raise Errors::Rotten, "#{product.title} is not fresh" if product.expiration_date > Date.today
        end

        nil
      end

      private
      attr_reader :products
    end
  end
end 

Возможно вам покажется удобным разделять функциональные объекты по типу. Вы можете добавить свои, например, Builder — создает объект на основе параметров.

Договоренности

• Метод call является единственным обязательным публичным методом.
• Метод initialize является единственным опциональным публичным методом.
• Остальные методы должны быть приватными.
• Логические ошибки должны наследоваться от класса LunaPark::Errors::Processing .

Обработка ошибок

Следует разделить 2 типа ошибок, которые могут произойти во время работы того или иного Действия.

Ошибки процесса выполнения

Такие ошибки могут возникать в результате нарушения логики обработки.

Например:

• при создании пользователя email зарезервирован;
• при попытке выпить молоко, оно закончилось;
• другой микросервис отклонил действие (по логической причине, а не потому, что сервис недоступен).

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

Такие ошибки должны наследоваться от LunaPark::Errors::Processing

Системный ошибки

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

Например:

• не работает БД;
• что-то поделилось на ноль.

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

Есть еще, ошибки валидации, которые мы рассмотрим подробнее в следующей статье.

Практика использования

1. Используйте переменные, чтобы повысить читаемость

module Fishing
  # bad - не информативно
  Serivices::Catch.call(fish, rod)

  # bad - избыточно
  Serivices::Catch.call(fish: fish, rod: rod)

  # good - более  выразительно
  Serivices::Catch.call(fish, with: rod)

  module Serivices
        class Catch
      def initialize(fish, with:)
        @fish = fish
        @rod  = with # внутри класса мы используем переменную
                     # указывающую на объект.
      end
      # ...
      private
      attr_reader :fish, :rod
    end
  end 
end   

2. Передавайте объекты, а не параметры

Старайтесь делать инициализатор простым, если обработка параметров не является его целью.
Передавайте объекты, а не параметры.

module Service
  # bad - на сервисном уровне мы работаем только с бизнес-логикой. Преобразование 
  #       типов следует вынести на уровень выше, например в форму.
  class Foo 
    def initialize(foo_params:, bar_params:)
      @foo = Values::Foo.new(*foo_params)
      @bar = Values::Bar.new(*bar_params)
    end
    # ...
  end
  Services::Foo.call(foo: {a: 1, b: 2}, bar: 34)

  # good - реализуем только бизнес-логику.
  class Bar 
    def initialize(foo:, bar:)
      @foo = foo
      @bar = bar  
      # ...
    end
  end

  foo = Values::Foo.new(a: 1, b: 2)
  bar = Values::Bar.new(34)
  Services::Bar.call(foo: foo, bar: bar)

  # good - логичным исключением является реализация шаблона проектирования - Builder.
  class BuildFoo 
    def initialize(param_1:, param_2:)
      @param_1 = param_1
      @param_1 = param_1
    end

    def call
      Foo.new(
        param_1: param_1.foo,
        param_2: param_2.bar,
        param_3: some_magick
      ) 
    end

    # ...
  end
end

3. Используйте в название Действия — глагол действия и объект воздействия.

# bad
module Services
  class Milk; end 
  class Work; end 
  class FooBuild; end
  class PasswordGenerator; end
end

# good
module Services
  class GetMilk; end 
  class WorkOnTable; end 
  class BuildFoo; end
  class GeneratePassword; end
end

4. По возможности используйте метод класса call

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

# good - Логично использовать сокращенную запись.
Services::BuildFoo.call(params)

# good - Или еще более сокращенную
Services::BuildFoo.(params)

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

ring = Services::RingToPhone.new(phone: neighbour)
10.times do
  ring.call
end

5. Обработка ошибок не является задачей сервиса

# bad - оставьте обработку ошибку интеракторам, а сервис легким.
def call

  #...
rescue SystemError => e
  return false
end

Модули

До этого момента мы рассматривали имплементацию Сервисного слоя как набора функциональных объектов. Но мы легко можем разместить на этом слое методы:

module Services
  def sum(a, b)
    a + b
  end
end

Другая проблема, которая встает перед нами — большое количество сервисных объектов. Вместо, набивших оскомину «rails fat model», мы получим «services fat folder». Есть несколько способов организовать структуру, чтобы уменьшить масштаб трагедии. Эрик Эванс решает это за счет того, что объединяет ряд функций в один класс. Представим, что нам нужно смоделировать бизнес-процессы няни, Арины Родионовны, она может кормить Пушкина и укладывать его спать:

class NoonService
  def initialize(arina_radionovna, pushkin)
    # ...
  end

  def to_feed
    # ...
  end

  def to_sleep
    # ...
  end
end

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

module Services
  module Noon
    class ToFeed
      def call!
        # ...
      end
    end

    class << self
      # При этом сложные процессы, можно вынести 
      # в функциональные объекты
      def to_feed(arina_radionovna, pushkin)
        ToFeed.new(arina_radionovna, pushkin).call
      end

      # А простые оставить методами, реализованными в модуле
      def to_sleep(arina_radionovna, pushkin)
        arina_radionovna.tell_story pushkin
        pushkin.state = :sleep
      end
    end
  end
end

При делении на модули должна соблюдаться низкая внешняя зависимость (low coupling) при высокой внутренней связности (high cohesion), мы же используем такие модули как Services, или Interactors, это также идет в разрез с идеями чистой архитектуры. Это осознанный выбор, который облегчает восприятие. По имени файла мы понимаем какой шаблон проектирования реализует тот или иной класс, если для опытного программиста это очевидно, то для новичка это не всегда так. После того как ваша команда будет готова, откажитесь от этого излишества.

Процитирую еще небольшой отрывок из большой синей книги:

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

Дайте модулям такие имена, которые войдут в ЕДИНЫЙ ЯЗЫК. Как сами МОДУЛИ, так и их имена должны отражать знание и понимание предметной области.

Тема модулей большая и интересная, но в полном объеме явно выходит за тему данной статьи. В следующий раз мы поговорим с вами о Репозиториях и Адаптерах. Мы открыли уютный телеграмм канал, где хотелось бы делиться материалами на тему DDD. Будем рады вашим вопросам и обратной связи.

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

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

Что такое функциональные требования

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

Само слово «функционал» подводит к тому, что мы задаем вопрос: как работает этот сайт, какие у него будут функции. Сюда относится все, что касается логики работы.

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

Пример того, как выглядят функциональные требования в техзадании

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

Нефункциональных требований очень много. Вот основные:

• Производительность. Например, скорость загрузки страницы или время реакции на определенные действия.
• Удобство для пользователя. Насколько интуитивное меню, сколько времени уходит у пользователя на поиск нужной информации.
• Безопасность. Персональные данные должны быть защищены от взломов, хакерских атак, вирусов.
• Совместимость. Как сайт смотрится на различных браузерах и устройствах. Возможно, с экрана телефона часть картинки не видно.
• Локализация. Если компания сотрудничает с иностранными клиентами, нужно адаптировать сайт под их запросы. Например, перевести контент на английский язык, добавить другую валюту или часовые пояса.

Нефункциональные требования могут касаться, например, визуальной части – красивых картинок, эффектов, шрифтов. Другими словами, всего того, что мы называем user interface (UI) – внешнего вида сайта. Также сюда относится user experience (UX) – удобство пользователя.

Чтобы объяснить отличие функциональных требований от нефункциональных, приведу такое сравнение. Функциональные требования – это авто или телега, у которых есть 4 колеса, место, где сидеть, и тягловая сила (двигатель или лошадь). А нефункциональные – это кузов мерседеса, с красивыми лампочками и шильдиками. Большинство людей покупают этот значок мерседеса на капоте, но это не отменяет и того, что под капотом все должно хорошо работать.

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

Что такое бизнес-требования

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

Бизнес-требования включают:

• Информацию о компании: название, год основания, сфера деятельности, товарный знак, список клиентов, преимущества перед конкурентами.
• Данные о целевой аудитории. Нужно примерно представлять, кто будет посетителем сайта: его пол, возраст, регион проживания, привычки и увлечения. Еще нужно понимать, зачем людям вообще приходить к вам на сайт. Например, купить товары, узнать стоимость дизайн-проекта или почитать новости.
• Цель создания сайта: что вы хотите получить в итоге. Например, увеличить количество продаж или повысить узнаваемость бренда.

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

Бизнес-требования от заказчика сайта

Зачем нужны функциональные и бизнес-требования

Функциональные и бизнес-требования решают такие задачи:

1. Упрощают взаимодействие между заказчиком и разработчиком. Они помогают избежать недопонимания, определяют общие термины и роли.
2. Сокращают срок реализации проекта. Благодаря четким требованиям разработка сайта займет меньше времени.
3. Экономят бюджет. Когда заказчик понимает что ему нужно, он может более точно спланировать бюджет. Размытые требования приводят к неопределенной стоимости разработки, которая впоследствии может вырасти.
4. Выявляют возможные ошибки. Выявление ошибок на начальном этапе поможет сократить время и деньги на их исправление.
5. Помогают предвидеть итоговый результат. С помощью требований разработчик понимает, что двигается в правильном направлении. Они не дают увлечься и отойти от первоначальной идеи, выступая некими границами проекта.

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

Техзадание на разработку сайта: запрещенные слова и выражения

Кто занимается сбором требований

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

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

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

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

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

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

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

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

Как проходит сбор требований

Методы сбора функциональных и бизнес-требований:

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

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

Для удобства документ обычно разбит на несколько разделов:

• Бизнес-требования. Это самые приоритетные требования, которые определяют цель создания сайта и задачи.
• Дизайнерские требования. Здесь описаны цвета, шрифты, стилистика будущего сайта. Они должны совпадать с идеей или фирменным стилем заказчика.
• Требования пользователей сайта. В данном блоке прописано, какую информацию может просматривать/добавлять/редактировать пользователи сайта. Например, менеджеру по продажам в интернет-магазине нужен только доступ к заказам, а бухгалтеру – к счетам и отчетам.
• Требования посетителей сайта. Здесь описан путь посетителя на сайте. Если проект очень крупный, составляется полноценная концепция поведения аудитории – Customer Journey Map.

Функциональные требования чаще всего формулируются в процессе работы над проектом. Иногда заказчик приходит с примером «хочу как у них», иногда – рассказывает, как он хочет, чтобы сайт работал. Бывает, что заказчик не знает всех возможностей и просто описывает их своими словами.

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

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

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

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

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

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

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

Как правило, делают наоборот: сначала запускают сайт, затем начинают заниматься продвижением. Также сайт должен соответствовать техническим требованиям поисковиков, и эти моменты нужно прописать в ТЗ. Еще нужно учесть поведенческие факторы, например, включить элементы для удержания посетителей, чтобы увеличить время нахождения на сайте.

Пример брифа компании. Из него станет понятно, чем занимается предприниматель и в чем ключевые преимущества его продукта

Ошибки при сборе функциональных и бизнес-требований

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

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

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

Какие ошибки чаще всего допускают при сборе ФТ и БТ?

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

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

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

Макет будущего сайта на основе функциональных и бизнес-требований заказчика

Выводы

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

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

Шаблон или уникальный дизайн: что выбрать для сайта

Бизнес-анализ — это структурированное изучение проблемы, имеющей отношение к бизнесу. Бизнес-анализ проводится, чтобы лучше понять проблему, а затем оценить, что требуется для ее устранения.
Бизнес-кейс/коммерческое предложение. Коммерческая цель или выгода является причиной выполнения проекта и может официально фиксироваться в документе, называющемся бизнес-кейсом, или коммерческим предложением. Этот документ обычно включает финансовые показатели (например, прирост выручки, снижение издержек и т.п.) или другие параметры (например, повышение уровня обслуживания потребителей, повышение мотивированности персонала и т.д.).

Сбор требований

Прежде чем начинать проект, обязательно нужно знать, какой результат (продукт) вы хотите получить. И порой этот продукт необходимо описать самым тщательным образом. Иными словами, нужно знать, какие требования заказчик предъявляет к продукту. Полный набор этих требований называют каталогом требований, или спецификацией.
Крупные и сложные проекты обычно насчитывают тысячи требований. Бизнес-анализ как раз и позволяет выявлять проблемы и определять, что требуется для их преодоления. В крупных проектах, таких, как разработка программного обеспечения, сбор требований является одним из важнейших этапов жизненного цикла проекта, котоорыый может занять несколько недель/месяцев.
Для выявления требований проводится серия структурированных интервью с заказчиками, которые позволяют точно определить их пожелания к готовому продукту. Попытка напрямую узнать у заказчика, какие результаты ему нужны, может закончится крахом: заказчик станет выдвигать все новые и новые требования, так что вы просто будете не в силах их удовлетворить. Помните, любое требование влияет на продолжительность и стоимость проекта. Соответственно, получая подробный список требований, вам нужно знать, являются ли они:

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

Выжимка по процессу формирования требований

Функциональные требования — это требования к системе.
Бизнес-требования — эквивалентно бизнес-целям.
Между ними — Пользовательские требования, User Requirements.
Пользовательские требования формулируются в терминах предметной области, а функциональные требования — в терминах системы.

Бизнес-процессы — самое начало работы.
Например, можно рассмотреть процессы RUP/MSF (упрощенная последовательность):
1. Бизнес-моделирование
2. Выявление требований
3. RUP: Анализ и проектирование, MSF: концептуальный, логический и физический дизайн
4. Реализация
5. Тестирование
6. Опытно-промышленная эксплуатация
7. Support и развитие системы

Совсем упрощенно:
1. От заказчика поступает начальная концепция системы (в нескольких предложениях что они хотят, что это позволит достигнуть и т.д.) — по сути это и есть бизнес-требования.
2. Приступаем к моделированию бизнес-процессов, которые хотим автоматизировать (тут в помощь нам ARIS, IDEF0/IDEF3, UML), возможно, строим дополнительную модель (оптимизированную), в которой будут прописаны бизнес-процессы после автоматизации.
3. Вытрясаем из заказчика требования к разрабатываемой системе (это будут пользовательские требования).
4. На основе пользовательских требований формулируем функциональные требования к системе (пользовательские требования — не единственный источник функциональных требований).

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

Например:
«Система должна вести журнал всех действий пользователя» или «Система должна позволять создавать новые Проекты».

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

Пользовательские и функциональные требования как правило связаны между собой. Это необходимо для отслеживания зависимостей требований друг от друга. В системах управления требованиями (например, Borland CaliberRM, TelelogicDoors, Rational RequisitePro) для этого есть так называемые «матрицы трассировки», на которых графически стрелками показываются зависимости между требованиями.

Важно сохранять пользовательские требования для хранения их в первоначальном виде, отслеживания источника их возникновения (вплоть до конкретного лица), расстановки их приоритетов (с точки зрения пользователя) и т.д.

Схема процесса разработки с уровнями требований

Формирование и анализ требований

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

Аттестация требований

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

Подготовка к интервью по сбору требований у заказчика

Классификация и описание требований на пути от бизнеса к технической реализации

Компания — Бизнес-требования

Источники: Топ-менеджмент компании
Документ: Бизнес-требования (обоснование потребностей инициативы)
Ответственный: Менеджер проекта

Состав бизнес-требований может отличаться на практике. Обычно включаются следующие пункты:

1. Описание контекста и списка ключевых заинтересованных лиц
2. Описание целей создания системы и критериев достижения
3. Ключевые бизнес-требования к решению и их приоритеты
4. Существующие и возможные ограничения на решение

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

Заказчик — Документ требований заинтересованных лиц

Этот документ описывает рекомендуемое содержание документа требований заинтересованных лиц:

• Бизнес-назначение
• Бизнес-рамки
• Обзор бизнеса
• Заинтересованные лица
• Организационная среда
• Цели и результаты
• Бизнес-модель
• Информационная среда
• Бизнес-процессы
• Политики и правила
• Ограничения деятельности
• Организационная структура
• Концепция использования системы
• Сценарии эксплуатации
• Проектные ограничения

Пользователь — Требования пользователя

Пользовательские требования — описание на естественном языке (плюс поясняющие диаграммы) функций, выполняемых системой, и ограничений, накладываемых на неё.
Источники: Пользователь
Документ: Пользовательские требования/Требования к ПО
Ответственный: Системный аналитик

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

Проблемы при формировании пользовательских требований

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

Системные требования

Системные требования описывают свойства и методы всех объектов системы. Программирование – это разработка и реализация структур данных и алгоритмов. Для разработки системы программисту необходимо знать структуры данных, необходимые для реализации системы, и алгоритмы (бизнес-правила/процедуры/пакеты обработки данных), которые ими манипулируют. Системные требования — детализированное описание системных функций и ограничений, которое иногда называют функциональной спецификацией. Она служит основой для заключения контракта между покупателем системы и разработчиками ПО.
Системные требования — это более детализированное описание пользовательских требований.
Они обычно служат основой для заключения контракта на разработку программной системы и поэтому должны представлять максимально полную спецификацию системы в целом. Системные требования также используются в качестве отправной точки на этапе проектирования системы. Спецификация требований может строиться на основе различных системных моделей, таких, как объектная модель или модель потоков данных.

Функциональные требования

Функциональные требования — это перечень сервисов, которые должна выполнять система, причём должно быть указано, как система реагирует на те или иные входные данные, как она ведёт себя в определённых ситуациях и т.д. В некоторых случаях указывается, что система не должна делать.

Стандартные формы для специфицирования функциональных требований:

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

Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».

Нефункциональных требований

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

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

Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:

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

Требования предметной области

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

Требования к продукту

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

Организационные требования

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

Требования к интеграции

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

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

Интеграция через ESB

Интеграция через ESB (Enterprise Service Bus, «Сервисная шина предприятия») применяется для обеспечения информационных систем возможностями для взаимодействия с сервисами. Использование этого метода интеграции приложений обеспечивает слабую связанность между информационными системами, так как системы взаимодействуют не напрямую, а через сервисы, размещенные на сервисной шине предприятия.
Основными функциями ESB являются:

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

Интеграция точка-точка

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

Интеграция данных

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

Задачи интеграции данных:

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

Интеграция ETL
Интеграция ETL характеризуется следующим сценарием:
На платформе ETL пишется процесс, который
1) С помощью средств доступа к БД 1ой системы забирает из таблиц 1ой системы данные
2) С помощью средств и ресурсов БД 1ой или 2й системы или своих собственных механизмов осуществляет преобразование к структурам таблиц 2й системы
3) Загружает данные в таблицы БД 2й системы.

Файловый обмен
Файловый обмен характеризуется следующим сценарием:
1) Приложение, которому требуется передать данные другому приложению, сохра¬няет их в файле.
2) Разрабатывается интеграционное решение, которое преобразует формат файла в формат, требуемый другим приложением. (В частном случае для этого дорабатывается одна из интегрируемых систем)
3) Приложение которому нужны данные, загружает подготовленный файл.

Требования к пользовательскому интерфейсу

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

• требования к внешнему виду пользовательского интерфейса и формам взаимодействия с пользователем;
• требования по доступу к внутренней функциональности системы при помощи пользовательского интерфейса.

К первой группе можно отнести следующие типы требований:

• Требования к размещению элементов управления на экранных формах
• Требования к содержанию и оформлению выводимых сообщений
• Требования к форматам ввода

Ко второй группе относятся следующие типы требований:

• Требования к реакции системы на ввод пользователя
• Требования к времени отклика на команды пользователя

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

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

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

Классификация изменяемых требований

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

Процесс управления изменениями

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

Кто читает документацию

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

Как правильно сформулировать и контролировать цель проекта?

Как и у всех путешествий, у проекта улучшения процессов должна быть цель. Если не определить конкретных целей по улучшению, люди не смогут работать согласованней, а вы не сможете сказать, есть ли движение вперед, не сможете определять приоритеты задач и сказать, когда цель достигнута.
Метрика — измеримая характеристика проекта, продукта или процесса.
Ключевые показатели производительности (KPI) — это метрики, привязанные цели и служащие мерилом продвижения проекта к достижению определенной цели или результата. Набор KPI-показателей может отображаться на контрольной панели, показывая приближение к целям.

При определении целей по совершенствованию процессов нужно иметь в виду два обстоятельства.

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

Если вы выбрали реалистичные KPI для своих целей, но не видите признаков прогресса по истечении разумного времени, нужно провести расследование:

• Правильно ли были проанализированы проблемы и выявлены их первопричины?
• Выбрали ли вы действия по улучшению, непосредственно направленные на эти первопричины?
• Был ли реалистичным план реализации этих действий по улучшению? Был ли план реализован, как планировалось?
• Изменилось ли что-то со времени исходного анализа, что должно было заставить переориентировать действия команды по улучшению?
• Действительно ли члены команды приняли новые приемы работы и прошли период обучения, чтобы начать активно применять их на практике?
• Были ли поставлены реалистичные цели, которые команда была в состоянии достичь?

Документы процесса разработки и управления требованиями (по Вигерсу)

Высокопроизводительные проекты отличаются эффективными процессами на всех этапах создания требований: выявления, анализа, спецификации, проверки и управления. Для облегчения выполнения этих процессов каждой организации необходим набор документов процесса (process assets).
Любой процесс определяют выполняемые действия и получаемые результаты; документы процесса помогают команде выполнять процессы последовательно и эффективно. Эти документы позволяют участникам проекта понять, какие шаги им следует предпринять и каких результатов от них ждут.

Документы процесса разработки требований

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

Документы процесса управления требованиями

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

Пример дорожной карты совершенствования процессов работы с требованиями

Документ по управлению требованиями