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

Дополнительный номер! Прямая трансляция «Программисты Goose Factory лицом к лицу» продолжится в этот четверг вечером. Запишитесь на просмотр, и у вас будет возможность получить периферийные подарки Goose Factory!

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

1.1 Видение

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

Первым шагом в бизнес-моделировании является разъяснение нашего видения.

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

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

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

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

Как же прийти к ясному видению?

1. Целевые организации и их“босс”（То естьсистемачеловек, чьи интересы являются наивысшим приоритетом）
   1. Ориентация на толпу: атрибуты толпы необходимо еще раз уточнять, и для исследования необходимо найти наиболее репрезентативного босса, а не просто искать случайного человека на улице. Поскольку развитие Интернета становится все более и более полным. , если вы хотите получить долю рынка, вы можете только углубиться в отрасль. Глубокое развитие означает усовершенствование толпы, например, создание текстового редактора Word, WPS. Как только потребности подавляющего большинства людей будут полностью удовлетворены, будет сложно продать стандартный редактор. Лучшим вариантом будет выбрать нишевую область, например редактор медицинских записей врача, а затем поместить результаты исследований в The The. население позиционируется в группе врачей;
   2. Позиционирование организации: сначала определите сферу деятельности организации и существующую систему (человеческий мозг или компьютер), которую необходимо заменить.,Начальник должен быть директором или лицом, ответственным за целевую организацию.,И является бизнес-лидером,вместо IT Ответственный человек не является крупнейшим лидером компании. Сотрудничая с традиционными предприятиями или учреждениями, мы часто связываемся с директором информационного центра, но мы должны дать понять, что начальником должен быть человек, который лучше всех знает бизнес, а не человек, отвечающий за информационные технологии. Только так можно. мы приближаемся к самым реальным потребностям.
2. Уточнение целей улучшения. Обратите внимание, что целью должно быть улучшение некоторых показателей организационного поведения, например. IoT Скорость подачи материалов для оборудования, этапы утверждения и т. д.,Вместо функции системы,И дело не в масштабе и качестве самой системы.,Это потребности и результаты, анализируемые на основе показателей.

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

Бизнес-пример:

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

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

1.2 Диаграмма вариантов использования в бизнесе

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

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

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

Анализ текущей бизнес-ситуации здесь осуществляется в виде диаграмм бизнес-прецедентов.

Диаграмма вариантов использования в бизнесе представляет ценность организации со стороны.

Диаграмма бизнес-прецедентов состоит из нескольких компонентов:

• Исполнители бизнеса: относятся к тем, кто находится за пределами организации.,Другие организации, с которыми организация взаимодействует（группа людей или организация）；
  • Исполнителем дела должна быть организация,а не отдельные лица или система (поскольку они оба могут быть заменены),Только организация отражает деловые взаимодействия;
  • Время должно использоваться не как исполнитель, а как соответствующая деловая организация.
• Вариант использования в бизнесе: ценность, которую субъекты бизнеса надеются получить от взаимодействия с изучаемой организацией (например, снятие средств, депозиты и т. д.). Он представляет собой основную ценность организации, и его трудно изменить. Меняется только реализация вариантов использования - бизнес-процессов (таких как процессы снятия средств с банкоматов, процессы онлайн-банковских переводов и т. д.).

В рамках бизнес-процесса ему соответствуют конкретные бизнес-объекты:

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

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

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

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

Бизнес-пример:

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

1.3 Диаграмма последовательности операций

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

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

а не изображать то, что задумано или задумано (это приведет к улучшениям, которые могут быть вообще неуместны или уже реализованы);

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

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

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

Мельчайшие частицы бизнес-объектов на диаграмме последовательности — это человеческие и нечеловеческие системы. Сообщения относятся к бизнес-объекту A, запрашивающему бизнес-объект B, чтобы он что-то сделал, или A, призывающему B сделать что-то, это обязанность B.

Рисуя диаграмму последовательности операций, обратите внимание на следующие антипаттерны (плохие практики):

• Бизнес-объект внезапно уточняется до определенного носителя информации,Например, «таблица реляционных данных».,Это не забота об улучшении бизнес-процессов (если только улучшение не касается системы базы данных или чего-то подобного);
• Бизнес-объект расширяется до организации,не делая различий между людьми внутри и системой,Это приводит к возможным упущенным улучшениям;
• Забота о различных процессах, которые не влияют на основной доменсистема（такие как средства связи、word Документация и т. д.), это тоже не то, что заботит бизнес-процессы (если только вы просто не хотите это улучшить);
• Рассматривайте таймер как исполнителя (бизнес-объект),Исполнитель – время,Таймеры — это всего лишь граничные классы, работающие со временем;
• Возложение на бизнес-объект обязанностей, выходящих за рамки его возможностей.,Например, отправить сообщение о написании патента в word,word Я не знаю как написать патент, патент пишет патентообладатель, слово Используется только для «Редактирования патентного документа»;
• Содержит множество подробных процессов взаимодействия внутри системы.,Слишком громоздко,Нет точки улучшения;
• Считайте неинтеллектуальный параметр обмена сообщениями (например, элемент) бизнес-объектом;
• В содержимом сообщения присутствует слово «запрос», а сама стрелка содержит значение запроса.

Бизнес-пример:

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

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

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

Бизнес-пример:

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

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

В этот бизнес-процесс мы внедряем систему обслуживания клиентов.

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

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

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

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

02. От проектирования требований к диаграмме вариантов использования системы

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

Фактически, если мы хотим разработать систему, нам нужно составить список требований.

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

2.1 Выявление требований

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

При выявлении спроса существует несколько методов и мер предосторожности:

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

Путем выявления спроса мы надеемся создать максимально ценную систему.

2.2 Схема вариантов использования системы

После определения требований можно нарисовать диаграмму вариантов использования системы.

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

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

Прежде всего, нам необходимо уточнить слово «система».

Что такое система? Система инкапсулирует свои собственные данные и поведение и может независимо предоставлять внешние услуги.

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

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

Диаграммы вариантов использования системы по-прежнему имеют системных исполнителей.

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

Исполнителями системы на диаграмме вариантов использования системы являются люди (не организации) или другие системы, которые функционально взаимодействуют с системой вне исследуемой системы.

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

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

Здесь упоминаются две категории исполнителей:

• Главный исполнитель: активно инициирует взаимодействие варианта использования, стрелка указывает от исполнителя к варианту использования.
• Вспомогательный исполнитель: пассивно участвует в процессе взаимодействия, и стрелка направлена ​​от варианта использования к исполнителю.

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

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

Давайте еще раз посмотрим на варианты использования. Варианты использования на диаграмме вариантов использования системы также имеют следующие требования:

• существоватьдиаграмма последовательности В операциях сообщения, указывающие на систему извне, могут быть сопоставлены со случаями использования системы, поэтому нарисуйте диаграмму. последовательности операций, вы также можете получить точные варианты использования системы;
• Вариант использования должен приносить пользу исполнителю, а не какое-либо обременительное взаимодействие;
• Вариант использования должен четко определять своих основных целевых клиентов, а не тех, кто может это сделать. Вариант использования соответствует ожиданиям целевых пользователей.
• Варианты использования не могут быть описаны как добавление, удаление, изменение и запрос определенной таблицы в базе данных, но должны начинаться с бизнес-потребностей заинтересованных сторон и описывать реальные сценарии использования;
• Не объединяйте варианты использования от разных заинтересованных сторон, которые реализуют схожие реализации.,Например, объединение поведения разных пользователей при просмотре в одном варианте использования (например, когда сотрудники просматривают информацию).,Руководитель группы проверяет информацию),Фактически, их заинтересованные стороны、Применение у всех разное：
  • Здесь нужно быть бдительными: не допускайте в своих требованиях идеи «повторного использования».,Если рассматривается «повторное использование»,Вы должны быть осторожны с тем, переключились ли вы на перспективу дизайна, чтобы подумать о проблеме;
  • Несколько исполнителей не могут указывать на один и тот же вариант использования. Если разницы действительно нет, то следует обобщить более абстрактные исполнители. Если разница есть, их следует разделить на разные варианты использования.
• сценарии использования системы не обязательно должны быть иерархическими,Если разделить,Возможно, объект исследования четко не определен; диаграмму вариантов использования не следует разделять на модули и подкатегории.,Это идея дизайна;
• Используйте именование падежей, используя структуру глагол-объект: (наречие) + глагол + (атрибут) + существительное.

Бизнес-пример:

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

Тогда все сообщения, направленные извне в систему послепродажного обслуживания IoT, можно сопоставить с вариантами использования нашей системы, поэтому диаграмма вариантов использования системы будет относительно простой:

2.3 Спецификация варианта использования

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

Однако этого далеко недостаточно для его реализации с точки зрения спроса и его необходимо детализировать.

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

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

Спецификации вариантов использования могут быть в виде документов, но могут быть и непосредственно нарисованы на UML-диаграммах. Главное — понятно объяснять детали.

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

1. префикс、постусловие：
   • префикс Условия — это ограничения, которые необходимо выполнить, прежде чем вариант использования сможет начаться.：должно бытьсистемаобнаруживаемый！
   • Постусловие — это ограничение после успешного варианта использования. Это определенное состояние, а не действие.
2. Интересы заинтересованных сторон: рассмотрите процесс варианта использования,интересы заинтересованных сторон,Заинтересованные стороны — это люди-исполнители из системы.,Все внимание должно быть уделено заинтересованным сторонам верхнего и нижнего уровня, а также источникам информации.,Всесторонне учитывать их интересы.
3. базовый путь：записатьсистема Шаги варианта использования
   • Путь с наибольшим успехом и основной ценностью варианта использования — это базовый путь;
   • Взаимодействие путей обычно можно разделить на четыре этапа: запрос, проверка, изменение и ответ;
   • Что следует учитывать при написании путей：
     • В запросе времени пишется «при достижении периода времени»;
     • Не пишите «ли» на этапе проверки, просто напишите напрямую ожидаемый результат;
     • Взаимодействие со вторичными субъектами может быть ответом;
     • В теме должно быть указано ответственное лицо (может быть только главный исполнитель или система);
     • Шаги следует описывать с использованием основных терминов бизнеса, а не с использованием различных идиом;
     • Не вдавайтесь в подробности взаимодействия интерфейса, это ограничение дизайна;
     • Критерием оценки спроса является: «Иначе это не сработает», а не «Это будет работать вот так». Между этими двумя понятиями есть разница.
4. Путь расширения: путь для записи исключений и непредвиденных ситуаций.,нужно внимание：
   • Только аварии, которые могут быть обнаружены системой, требуют расширения пути;
   • дизайн, ошибки, вызванные недостаточной разработкой, не являются случайными расширениями,Например, базу данных не удалось сохранить.,Это не то, о чем должны заботиться требования;
   • Выборочные ветки, не вызывающие изменений в интерактивном поведении, не являются расширениями;
   • Переход к интерфейсу не является расширением.
5. Дополнительные ограничения：Другие детали, которые могут потребовать уточнения
   • Список полей.
   • Правила бизнеса.
   • требования к качеству.
   • дизайнограничение。

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

03. Резюме

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

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

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

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

Как рисовать – это всего лишь средство реализации идей. Что действительно важно, так это процесс мышления.

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

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

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

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

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

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

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

Для проектирования также рекомендуется аналогичный метод проектирования, называемый Domain Driven Design (Domain Deiven Design, DDD).

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

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

Желаю каждому, у кого есть мечта, получить желаемое.

-End-

Автор оригинала ｜Оу Сяо