Мышление письмом по восьмой главе “Наведение внимания”.
Составьте глоссарий или понятийную базу / словарь выбранной роли. Опишите хотя бы 5-10 ключевых понятий, с которыми сталкиваетесь вы или члены вашей команды.
Пробую описать с какими понятиями работает системный аналитик.
Проектная команда
Название дисциплины: Системная инженерия (Инженерия киберфизических систем)
Описание: команда, состоящая из агентов, которая занимается созданием ПО для нужд заказчиков. Команда состоит из аналитиков, дизайнеров, разработчиков, тестировщиков, архитекторов, платформенных инженеров и других ролей. Системный аналитик часть команды или нескольких команд.
Пример: команда разработки Яндекс.Музыки.
Ловушка: команда строителей, которые строят мне дачный домик.
Есть ощущение, что понятие “проектная команда” не точное. В случае ИТ и роли системного аналитика было бы вернее говорить о “команде разработки” проекта/продукта/системы. При этом у нас например, мы все являемся отделом разработки одного продукта. Но внутри отдела команды разработки ещё поделены с привязкой к конкретным блокам/модулям/функциональности продукта. И системный аналитик как раз может быть закреплён уже за этими маленькими командами разработки.
Системный аналитик
Название дисциплины: Системная инженерия (Инженерия киберфизических систем)
Описание: агент в роли, который занимается сбором требований к системе, оформлением этих требований в описание задач на понятном разработчикам языке. Переводчик с бизнесового языка на программерский.
Пример: системный аналитик Лена из моей команды
Ловушка: бизнес аналитик Оля из моей команды
В описании есть запретное слово - требования. Там скорее всего потребности и пожелания. Интересы заказчиков. Но у нас тоже этим словом часто пользуются и в вакансиях оно куда не глянь. И там где учат систименому анализу тоже это слово в ходу. Поэтому оставила.
Предметная область (домен)
Название дисциплины: Методология
Описание: domain не тот, который доменное имя сайта, а который из Domain Driven Design. Предметная область - область деятельности в реальном мире. У нас ещё специализация деятельности происходит по предметным областям. Предметная область описывается специфичными для неё понятиями, связями между этими понятиями. У взрослых предметных областей есть учебники, которые описывают дисциплину.
Пример: врачебное дело, строительство, бухучёт, разработка ПО.
Ловушка: мытьё посуды, написание кода. Это практики, а не предметные области.
Задача системного аналитика
Название дисциплины: Системная инженерия (Инженерия киберфизических систем)
Описание: помочь пользователям и команде разработки понять друг друга. Для этого аналитик должен вникать в предметную область заказчиков, чтобы понимать их язык. И должен разбираться на каком-то верхнем уровне в том, что такое разработка ПО. Системный аналитик должен быть сосредоточен на том, чтобы команда разрабатывала приложение, которое решает проблему заказчиков. Для этого системный аналитик общается с экспертами предметной области. Изучает источники данных. Анализирует существующее ПО. Проектирует модели данных и процессов.
Пример: описывает требования, проектирует модели данных.
Ловушка: пишет код, тестирует систему, определяет приоритет задач.
Эксперт предметной области
Описание: агент представитель предметной области, который хорошо разбирается как всё устроено. Обладает знаниями понятий предметной области, связями между ними и принципами работы внутри предметной области.
Данные
Описание: информация о системе или её части, отображаемая в пригодном для обработки виде.
Источник данных
Описание: имеется в виду источник данных о системе. Источниками могут базы данных, документация процессов, интеграций.
Модель данных
Описание: описание предметной области с помощью понятий и связей между ними. Описание может быть составлено на естественном языке, либо в виде схем, таблиц.
Пользовательский интерфейс (UI)
Описание: визуальное представление нашей системы на экране пользователя. Графические элементы управления и вывода информации на электронные устройства.
Клиент-серверное взаимодействие
Описание: способ общения между приложениями с помощью обмена запросами и ответами. Так они предоставляют друг другу различные данные.
API
Описание: application programming interface - интерфейс взаимодействия с приложением. Контакт, который предоставляет приложение, для того, чтобы можно было от него получить данные. Описывается спецификацией в соответствии с выбранной технологией получения данных.
Пример: Web API Яндекс.Маркета, меню в ресторане (в некотором смысле).
Требование
Описание: пригодное для практического применения представление проблемы, которую нужно решить, или возможности, которую нужно использовать. Требования акцентируют внимание на ценности, которую можно получить при их реализации. Требования можно представить в виде документа, набора документов или в ином соответствующем обстоятельствам виде.
Пользовательские требования
Описание: описание нужд пользователей и других заинтересованных сторон, которые нужно удовлетворить, чтобы выполнить бизнес-требования.
Пример: Как пользователь сайта, я хочу фильтровать отзывы на положительные и отрицательные, чтобы быстрее получать интересующую меня информацию от покупателей товара.
Функциональные требования
Описание: описание того, что должно делать ПО, чтобы пользователи смогли выполнить свои задачи (пользовательские требования) в рамках бизнес-требований.
Пример: Автоматически удалять отзыв о магазине, интегрированный с Яндекс Маркета, на сайте, если этот отзыв был удален в Яндекс Маркете.
Нефункциональные требования
Описание: описывают то, как хорошо ПО исполняет свои функциональные требования, — его свойства, ограничения и особенности.
Пример: Сайт должен отправлять не более 100 запросов в час в систему Яндекс Маркет для получения отзывов.