Карьера в IT. Системный аналитик, часть 2. Use cases\User stories
Всем привет.
Продолжим наше погружение в теоретические знания, необходимые системному аналитику (это применимо также и для бизнес-аналитика, первые три части моих лекций - точно).
Use cases
В первую очередь поговорим про Use case (далее используются термины «варианты использования», «сценарии», «юзкейсы»).
Use case описывает сценарий взаимодействия участников (как правило — пользователя и системы). Участников может быть 2 и больше. Пользователем может выступать как человек, так и другая система. С помощью Use Case может быть описано и пользовательское требование, и требование к взаимодействию систем, и описание взаимодействия людей и компаний в реальной жизни.
Чтобы ответить на вопрос “как их писать” - приведу пример, после которого всё станет понятно. Допустим, разберем простейший сценарии самой стандартной авторизации пользователя в систему:
Сам по себе UC должен описывать только успешный сценарий. Если же есть какие-то ответвления от него, то они описываются отдельно в расширениях - как в данном примере. Также, если альтернативный сценарий слишком большой - то он описывается отдельным сценарием использования, как, например, для варианта с "Напомнить пароль". Потому что по сути, это отдельный и самостоятельный сценарий, который еще даже больше текущего.
Т.к. варианты использования является набором требований более высокого уровня абстракции, чем набор отдельных функциональных требований - только с помощью них глубокий системный анализ провести невозможно. Но для некоторых проектов (где системный аналитик, или просто аналитик не глубоко погружен в технические дебри) и компаний - очень даже подходит, когда нужно описать для разработчиков верхнеувровневые требования.
И кроме этого, UC это естественный способ описывать диалог, он понятен человеку без подготовки и поэтому с помощью них очень удобно согласовывать задачу с заказчиком, без необходимости показывать всё своё сложное и большое ТЗ.
User stories
User Story — это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя.
Особенности:
Не являются детальным описанием требований, а представляют собой обсуждаемое намерение (нужно сделать что-то, вроде этого);
Короткие, легко читаемые и понятные всем (как разработчикам, так и пользователям);
Описывают небольшую часть функциональности, которая может быть реализована за короткий промежуток времени;
Не занимают больших, громоздких документов. Как правило сгруппированы в списки.
Структура - Как, <роль/персонаж пользователя>, я <что-то хочу получить>, <с такой-то целью> .
Примеры:
Как пользователь, я хочу иметь возможность добавить комментарий к заявке для предоставления дополнительной информации;
Как сотрудник поддержки, я хочу иметь возможность перевести заявку в статус "Отложено";
Как пользователь, я хочу видеть все заявки, созданные мной, чтобы отслеживать их статус.
В этих пожеланиях есть один actor, одно действие и одна ценность (value, impact).
C актером все более-менее просто. Вы выделили персонажей, или у вас есть роли, и вы легко их вписываете в начало истории.
Действие
Наверное, здесь сложно ошибиться - это суть истории, “что нужно сделать”. Что можно улучшить. Действие должно быть одно - основное. Нет смысла описывать “авторизуется и выполняется поиск”. Укажите то действие, что вам действительно нужно.
Важно описывать историю на уровне “ЧТО?” делает, а не “КАК?” Это главное в истории. Опишите проблему, а не ее решение. То, "Как" сделать - вы потом опишите в других документах, в том же ТЗ или постановке.
Ценность
Главная проблема с User Story. Вы всегда знаете первую часть истории,но всегда сложно указать для чего это делается. Но, все должно быть указано как User story согласно шаблону, и потому вы пишите “чтобы …” и какую-то чушь, в которую сами не верите.
Уберите эту часть из истории. Если ничего не потеряли - значит формализация ценности в истории была бесполезна. Что же можно сделать?
Отказаться от формулировки “чтобы”. Это корень зла. Да, для каких-то историй можно указать ценность истории в таком формате, но не для большинства.
Также можно перейти с понятия ценности (value) на влияние (impact). Ваша история не обязательна должна иметь ценность, но обязательно должна оказывать влияние на того актера, что указан в истории. А уже это влияние ведет в конечном итоге к цели, которая имеет для вас ценность.
Кроме этого, есть хороший инструмент оценки пользовательских историй - INVEST (лично мне, импонируют люди, которые придумывают такие зашифрованные вещи в словах. Сразу вспоминается система S.P.E.C.I.A.L и подобные ей):
P.S.: Удивлен, что пост с практическим пояснением лекционного материала зашел хуже, чем сама лекция) Дайте фидбэк - нужны вам вообще практика с примерами?)
P.P.S: Уже по традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
P.P.P.S: Если я не путаю - Пикабу мне в самом начале предлагал создать пост-опрос для пикабушников. Но сейчас я в упор не вижу этого функционала. Тыкните носом в него, пожалуйста (если мне не померещилось) - есть хорошая идея для опроса)
Карьера в IT. Системный аналитик, часть 1.1. Практика
Всем привет.
Штож, обойтись без того, чтобы тебя обозвали душнилой (пусть и косвенно, спасибо за это), когда ты рассказываешь теорию про что-нибудь - невозможно.
Именно поэтому на своих обучениях, я очень настаиваю на том, чтобы мои менти делали домашние задания (а у меня их много, больше, чем многим хотелось бы) - потому что без практики чтение теории бесполезно (хотя всё также необходимо, как минимум ее спрашивают на собеседованиях - поэтому уж простите, но буду душнить и дальше).
Как это происходит - мы выбираем какую-нибудь систему, на которую менти хотел бы написать ТЗ и после каждой пройденной темы закрепляем ее на практике. Прошли виды требований - написали требования, прошли UC\US - написали UC\US, прошли REST - описали пару микросервисов и всё это для одной системы, а не на рандомные темы. По итогу получается очень даже неплохой документ для портфолио.
Поэтому буду тут делать тоже самое. Давайте в качестве системы, которую мы будем описывать, возьмем ITSM-систему (ближайшие аналоги: JIRA, NAUMEN service desk). Это такой подвид систем, которые позволяют управлять IT-услугами.
Обычно, они предоставляют возможность заказчику заводить бизнес-инициативы/запросы на улучшения системы/запросы на устранение багов в качестве заявок в системе и отслеживать их жизненный путь. Также они позволяют самой команде разработки заводить задачи для себя, отслеживать их, приоритезировать, управлять и так далее.
Сейчас напишем небольшое ТЗ для такой системы.
Глоссарий
Не пренебрегайте этим разделом, пожалуйста. ТЗ вы пишете не для себя, помните это.
Заявка – сущность системы, которая содержит информацию о запросе пользователя (как заказчика, так и члена команды разработки). Основная бизнес-сущность системы.
SLA (Service Level Agreement) - договор между заказчиком услуги и ее поставщиком, определяющий права и обязанности сторон и согласованный уровень качества предоставления услуги.
В формате service desk системы, как правило, это количество времени, за которое должна быть решена заявка в разрезе приоритетов. Условно, баг с критичным приоритетом должен решиться за 24 часа.
Введение
На данный момент связь с командой разработки осуществляется посредством почты, через которую отправляются запросы на внедрения нового функционала, либо исправления различных дефектов. Нередкий случай - когда такое письмо теряется\игнорируется и задача долго не решается. Отсутствует прозрачность процесса и понимание того, на каком этапе сейчас находится запрос.
Бизнес-требования.
БТ1: Увеличить прозрачность процесса внесения изменений в систему\исправления дефектов.
В каждый момент времени заказчик должен понимать на каком этапе жизненного цикла находится заявка. Должна быть возможность оставлять комментарии\вопросы внутри сущности "Заявка", для оперативной коммуникации с командой разработки.
БТ2: Система должна вести статистику и отчетность по всем заявкам с целью отслеживания количества выполненных вовремя\просроченных\отмененных\отложенных заявок для определения результативности команды разработки. Необходимо для проверки того, выполняет ли она заявки в срок, согласно SLA.
... Что-то еще.
Системные требования.
Тут миллион возможных фичей, мы возьмем для примера парочку из них:
Краеугольный камень такого рода систем - создание заявки;
И поиск заявок по различным фильтрам.
Создание заявки
Требуется реализовать процесс создания заявки следующим образом: по нажатию на кнопку "Создать заявку", открывается диалоговое окно создания заявки, согласно макету:
Я максимально не дизайнер, поэтому если у вас это вызывает кровотечение из глаз - просьба не вызывать археологов и не кидаться тапками.
Пикабу не умеет в таблицы, да?
Таблица 1. Состав элементов формы диалогового окна создания заявки.
По нажатию на кнопку "Создать" требуется проверять были ли заполнены все обязательные поля:
Если нет, то не заполненные обязательные поля подсвечиваются красным и отображается подсказка с стандартным текстом.
Если все обязательные поля были заполнены, то инициируется процесс создания заявки (когда будем проходить интеграцию front-to-back распишем детально этот момент. Так же опишем модель данных объекта task (заявка) и всё остальное необходимое, для разработчиков).
Поиск заявок
Требуется реализовать возможность поиска заявок по различным параметрам фильтрации, таким как (тут я уже фронт и фильтры рисовать не буду):
Приоритет;
Исполнитель;
Описание заявки;
Статус;
Дата создания с\Дата создания по;
Просроченные заявки
Куча других вариантов
Если был выбран фильтр по приоритету, то найти все заявки, у которых priority (приоритет) = выбранному значению.
Если был выбран фильтр по исполнителю, то найти все заявки, у которых assignee (исполнитель) = выбранному значению (представим, что там выпадающий список всех сотрудников).
Если был выбран фильтр по описанию заявки, то требуется выполнить поиск по подстроке и найти все заявки, у которых в полях topic, shortDescription и description найдено введенное значение.
Описание логики фильтрации для кучи других вариантов)
Все фильтры могут работать одновременно через условие ИЛИ. Если в результате поиска не было найдено ни одной заявки, то отобразить сообщение с текстом "По вашему запросу ни одной заявки не найдено".
Итого
Примерно в таком формате за несколько человекодней можно описать вполне себе хорошее ТЗ на различные функции нашей предполагаемой системы.
Само собой, я учел не все моменты, не все ограничения\необходимые требования и вот это всё - поэтому приветствую критиков в комментариях.
Однако, это и не было целью - целью было показать то, как нужно писать ТЗ и требования (чтобы показать тем, кто их не видел - как они вообще выглядят). Ну и для закрепления на практике примером рассказанный ранее материал - чтобы это не было просто очередной "скучной лекцией или рефератом".
P.S. Спасибо @himen.ru, за дельные и конструктивные комментарии.
P.P.S.: Уже по традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
Карьера в IT. Системный аналитик, часть 1. Виды и качества требований
Всем привет.
Сегодня перейдем к более прикладной и конкретной теории, без которой нельзя обойтись хоть бизнес-, хоть системному аналитику (к слову, один из самых частых вопросов, который задают на собеседовании начинающего аналитика - какие виды требований ты знаешь? Какими качествами требование должно обладать?).
Не буду душнить и писать сухую теорию про то, что требование - это совокупность утверждений относительно атрибутов, свойств или качеств программной системы... бла-бла-бла. Я думаю, что все понимают - что такое требование к системе. Теперь давайте разберемся, какими они бывают.
Виды требований.
Общепринято делить требования на следующие категории:
Функциональные требования, которые включают в себя:
Бизнес-требования - что система должна делать с точки зрения бизнеса. Т.е. содержат в себе высокоуровневые задачи и цели заказчика. Как правило их формулируют именно те люди, которые заказывают какой-либо продукт. Они описывают те цели, которые заказчик намеревается достичь с помощью системы (ПО). В 90% случаев эти требования направлены на получение дополнительной прибыли заказчика:
Либо через внедрение доработки\системы, которая будет приносить прямую прибыль через, допустим, привлечение новых клиентов (привет ДБО и различные мобильные приложения);
Либо через сокращение издержек и оптимизацию процессов, что тоже приводит к увеличению прибыли;
Либо по необходимости. Например, когда центробанк выдал на-гора очередное распоряжение по необходимости считать ПДН (показатель долговой нагрузки) клиента - банкам ничего не остается делать, кроме как внедрять соответствующие доработки. Ну тут тоже есть косвенная финансовая выгода: ты делаешь доработку > не получаешь штрафы и не теряешь лицензию > профит.
Пример бизнес-требования: “Требуется уменьшить время работы над одной заявкой сотрудником колл-центра на 50%” (чувствуете прямую выгоду? Быстрее обработка > больше заявок будет обработано в единицу времени > дешевле стоимость обработки или просто выше КПД).
Пользовательские требования описывают цели и задачи, которые пользователи смогут решить с помощью системы. Их часто представляют в виде сценариев использования (Use case, о которых поговорим позже).
Функциональные требования (системные) - определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований. Другими словами, что должны сделать разработчики, чтобы по итогу получилась система, позволяющая пользователь выполнять их функционал и выполняющие бизнес-требования заказчика.
Например, “Требуется реализовать возможность поиска товара по продавцу, категории, диапазону сумм и рейтингу”.
Нефункциональные требования описывают характер поведения системы и атрибуты качества и также делятся на несколько категорий:
Бизнес-правила - описывают почему система должна работать именно так в разрезе внутренних корпоративных правил, требований закона и различных стандартов.
Например, многие табачные компании и компании, производящие алкоголь, требуют постоянного доказательства того, что промо-сайтами пользуются люди, достигшие определенного возраста. Это бизнес-правило (подтверждение возраста) возникает по требованию этических комитетов заказчика, хотя и несколько противоречит маркетинговым целям и требованиям по usability;Атрибут качества - описывают дополнительные характеристики продукта в различных измерениях, важных для пользователя или разработчиков. Эти характеристики включают практичность, портабельность, целостность, эффективность, устойчивость;
Ограничения - это формулировка условия, которое модифицирует требование или набор требований сужая выбор возможных решений.
Например, "Требуется ограничить загрузку файлов размером более 20мб", "Ограничить работу приложения только на IOS" или только в браузере Chrome и т.д.
Внешние интерфейсы - описание аспектов взаимодействия с другими системами и операционной средой. К ним относятся требования к API продукта или системы, а также требования к API других систем, с которыми осуществляется интеграция.
Именно такую классификацию требований предложил и описал Вигерс в своей книге "Разработка требований к программному обеспечению" и сейчас, в целом, все придерживаются ее.
На схеме это выглядит примерно вот так:
Качества требований:
С видами требований разобрались. Теперь нельзя обойти стороной вопрос о том, а какими они должны быть, эти требования? Вот список качеств, которыми требование, очень желательно, должно обладать:
Атомарность - требование является атомарным, если его нельзя декомпозировать на несколько требований. Например, “Требуется ограничить загрузку файлов размером более 20мб” является атомарным, т.к. его нельзя разделить на несколько частей;
Завершенность и полнота - требование содержит полный набор информации для однозначного понимания;
Краткость - чем лаконичнее требование, тем лучше;
Консистентность - требование не должно противоречить самому себе и другим требованиям;
Выполнимость - требование возможно реализовать в рамках проекта (его сроков и бюджета);
Проверяемость - реализованность требования может быть определена через один из четырёх возможных методов: осмотр, демонстрация, тест или анализ;
Однозначность - разработчик, тестировщик (или любой другой человек) должен понять это требование также, как и вы. Соответственно требование не должно быть расплывчато, размыто, не должно содержать непонятных аббревиатур.
Понятно, что на практике далеко не все требования обладают каждым из этих качеств. Где-то из-за спешки, где-то из-за ошибки или даже нежелания. У кого-то просто своеобразный стиль и он любит писать длинный сложносочиненные требования - и это неплохо, там где уместно. Самое главное, чтобы требование было консистентным, завершенным, выполнимым и однозначным.
У меня, как и у многих на самом деле, в начале моей карьеры аналитика были проблемы с тем, что я просто физически сопротивлялся тому, чтобы писать кратко. Мне казалось, что если я написал одно предложение и этого будто бы хватало - что-то не так и нужно налить воды и чего-нибудь еще придумать. Но на самом деле, если вы уместили решение задачи в одно предложение и оно полностью покрывает всё что необходимо - эт круто и не нужно этого пугаться (но перепроверить, что ничего не упущено не помешает =) )
P.S.: Опять получился длиннопост, но скорее всего все последующие будут примерно такими же, т.к. на самом деле темы объемные и уместить все что хочется (и необходимо) рассказать в одном посте достаточно тяжело.
P.P.S.: Буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
Окончательные системные требования к компьютерной игре Atomic Heart
От GTX 960 до RTX 3080 и не больше 16 Гбайт ОЗУ даже на «ультрах» в 4K.
Сооснователь и руководитель студии Mundfish Роберт Багратуни в интервью порталу Wccftech раскрыл полные системные требования постапокалиптического боевика Atomic Heart и рассказал о подготовке игры к релизу.
Напомним, исходную версию «аппетитов» Atomic Heart авторы представили в начале 2021 года. В сентябре 2022-го разработчики назвали пересмотренные минимальную и рекомендуемую конфигурации, но к настоящему моменту устарели и они.
По словам Багратуни, для запуска Atomic Heart хватит и 8 Гбайт оперативной памяти (если отключить оптимизацию шейдеров в настройках), однако в таком случае игроки столкнутся с подтормаживаниями при входе в новую локацию.
Для работы на ПК игре понадобятся Windows 10 (64 бит) и DirectX 12
Минимальные требования (1080p, 30 кадров/с, низкие настройки графики).
* процессор: Intel Core i5-2500 или AMD Ryzen 3 1200;
* видеокарта: NVIDIA GeForce GTX 960 или AMD Radeon R9 380;
* оперативная память: 8 Гбайт (рекомендуется 12 Гбайт);
* место на диске: 90 Гбайт (предпочтительнее SSD).
Минимальные требования (1080p, 60 кадров/с, низкие настройки графики).
* процессор: Intel Core i5-6500 или AMD Ryzen 3 1200;
* видеокарта: NVIDIA GeForce GTX 1060 или AMD Radeon RX 580;
* оперативная память: 8 Гбайт (рекомендуется 12 Гбайт);
* место на диске: 90 Гбайт (предпочтительнее SSD).
Багратуни также раскрыл, что ПК-версия Atomic Heart будет включать функцию предварительной компиляции шейдеров до начала игры, но её при желании можно будет отключить. Поле зрения настроить не дадут.
Чтобы разогнать Atomic Heart до 60 кадров/с на средних и высоких настройках графики, понадобится:
Средние требования (1080p, 60 кадров/с, средние настройки графики).
* процессор: Intel Core i5-6600K или AMD Ryzen 5 1400;
* видеокарта: NVIDIA GeForce GTX 1070 или AMD Radeon RX 5600 XT;
* оперативная память: 16 Гбайт;
* место на диске: 90 Гбайт (SSD).
Высокие требования (1080p, 60 кадров/с, высокие настройки графики).
* процессор: Intel Core i5-7600K или AMD Ryzen 5 1600;
* видеокарта: NVIDIA GeForce GTX 1080 или AMD Radeon RX 5700 XT;
* оперативная память: 16 Гбайт;
* место на диске: 90 Гбайт (SSD).
Atomic Heart получит поддержку особенностей контроллера DualSense, но только на PS5 (не ПК)
Максимально красивую картинку в Atomic Heart, уточняет Багратуни, смогут выдать только высокопроизводительные ПК, однако и на консолях нынешнего поколения игра будет выглядеть сопоставимо (хоть и без трассировки лучей).
На «ультра» в Atomic Heart смогут рассчитывать пользователи с ПК следующих конфигураций:
Требования «Ультра» (1080p, 60 кадров/с, настройки графики «Ультра»).
* процессор: Intel Core i7-7700K или AMD Ryzen 5 2600X;
* видеокарта: NVIDIA GeForce RTX 2070 Super или AMD Radeon RX 6700 XT;
* оперативная память: 16 Гбайт;
* место на диске: 90 Гбайт (SSD).
Требования «Ультра 4K» (2160p, 60 кадров/с, настройки графики «Ультра»).
* процессор: Intel Core i7-8700K или AMD Ryzen5 3600X;
* видеокарта: NVIDIA GeForce RTX 3080 или AMD Radeon RX 6800 XT;
*оперативная память: 16 Гбайт;
*место на диске: 90 Гбайт (SSD).
Источник:
Нужна помощь с выбором объема оперативной памяти для консоли на Ryzen 7 6800U
Всем привет! Нужна помощь пикабушников с выбором. Желательно, аргументированная)
Планирую приобрести компьютер-консоль на Windows на базе Ryzen 7 6800U и использовать ее в значительной степени для игр (это осознанный выбор не в пользу Steam Deck).
Речь о устройствах вроде Aya Neo 2, GPD Win 4 и т.п. Грубо говоря это как Steam Deck, но на 30% мощнее.
Почти все такие устройства представлены как с 16 гб, так и с 32 гб оперативной памяти на борту. При этом около 4ГБ забирает себе интегрированный видеоадаптер.
Вопрос такой: достаточно ли будет оставшихся 12 Гб, чтобы тянуть ААА проекты вроде Elden Ring, God of War и т.п.? Конечно, запускаться они будут в основном на низких и средних настройках и скорее всего в разрешении 800p или 1200p. При этом всё это на Windows 11.
Если бы имелась отдельная видеопамять, вопрос бы не возник - 16ГБ точно хватило бы, но вот на счет 12ГБ я не уверен.
Я не нашел в сети каких-то сравнений для конкретно этого чипа, а они имели бы смысл, так как это пока единственный интегрированный видеоадаптер, который может тянуть ААА-проекты.
Подозреваю, что 16ГБ будет хватать впритык, и держать в фоне браузер будет уже крайне нежелательно. Но это лишь моя догадка.
Разница в цене довольна большая, поэтому и приходится подумать.
RUST
Друг познается в чате
«Чат на чат» — новое развлекательное шоу RUTUBE. В нем два известных гостя соревнуются, у кого смешнее друзья. Звезды создают групповые чаты с близкими людьми и в каждом раунде присылают им забавные челленджи и задания. Команда, которая окажется креативнее, побеждает.
Реклама ООО «РУФОРМ», ИНН: 7714886605