– Время на принятие решений и выполнение операций превышает желаемое.
– Оптимизации и прочие внутрикорпоративные движения повышения эффективности.
– Желание стать более современным и цифровизированным подразделением.
– Хайп на рынке, влияние внешнего маркетинга.
– Вера в чудесное новое решение всех проблем.
– Новости законодательства и отраслевых регуляторов.
– Воля вышестоящего руководства.
Кроме того, может быть и множество других причин. Здесь важно, что появляется воля лица, принимающего решения, которая может быть выражена в выделении на создание ИТ-решения некоторого количества ресурсов (финансовых, временных, экспертных и др.), что должно привести к автоматизации какого-то участка бизнеса и изменить показатели, характеризующие этот участок, соответственно ожиданиям.
Появляется критерий «соответствие ожиданиям», то есть:
– ожидания должны быть сформированы;
– ожидания должны быть формализованы до метрик или категорий, которые позволили ли бы определить меру соответствия ситуации этим ожиданиям;
– для метрик и категорий определены целевые значения.
В реальности так бывает редко. Обычно ожидания сродни мечте или иллюзорному образу «светлого будущего». При этом воля (или драйв, как нынче модно говорить) имеется, а, значит, есть и движение к мечте.
Особенность мечты, как мы все знаем из многочисленных трудов по мотивации, в том, что пока не выстроен более-менее измеримый и непротиворечивый образ этой мечты, движение носит хаотический характер, а шансов достичь цели немного.
Более того, велик шанс не понять, что цель уже достигнута и разочароваться. Увы, все тоже самое, часто с куда большими затратами, верно и для создания ИТ-решений.
Чем более размыты и абстрактны ожидания, тем меньше шансов на удовлетворенность результатами проекта.
Итак, ключевые факторы начала разработки это:
– Желание, или даже мечта, драйв;
– Возможность привлечь для создания решения необходимые ресурсы;
– Понимание целей того, что собрались сделать, и вера в бизнес-полезность этого.
Пока мы говорили о желании, мечте, но всем известно, что разработка ведется на основе требований. И если мечты и желания исследуются поэтами, писателями, психологами, то требования – область деятельности аналитиков, менеджеров продуктов и разработчиков.
Немного остановимся, на том, что такое требование и каковы его свойства.
Глава 2. Немного о требованиях
Основные виды требований
Детально требования и все аспекты работы с ними проработаны книгах по управлению требованиями, например, Карла Вигерса и соавторов. Приведем необходимый для дальнейшего изложения минимум, а за остальным предлагаем обратиться к упомянутой классике.
Итак, выделяются следующие виды требований:
Бизнес-требование – высокоуровневая бизнес-цель организации или заказчиков системы, в то же время под бизнес-требованием может пониматься достаточно детализированное требование любой другой категории, если его выполнение прямо связано с достижением бизнес-цели заказчика, а отклонение от него ведет к не достижению или неполному достижению этой цели. Обычно, говоря о подготовке качественных бизнес-требований, имеют в виду эту расширенную трактовку.
Бизнес-правило – политика, предписание, стандарт или правило, определяющее или ограничивающее некоторые стороны бизнес-процессов. По своей сути это не требование к программному обеспечению (ПО), но оно служит источником нескольких типов требований к ПО.
Ограничение – ограничение на выбор вариантов, доступных разработчику при проектировании и разработке решения
Требование к взаимодействию – описание взаимодействия с пользователем, другой программной системой или устройством.
Функциональное требование – описание требуемого поведения системы в определенных условиях. Функциональные требования описываются в форме традиционных утверждений со словами «должен» или «должна».
Источник: readli.net
Как мы создали шаблон функциональных требований к разработке ПО
Всем привет, мы – Таня и Лиза, системные аналитики в МТС Банке, работаем над мобильным приложением и сайтом для физических лиц. В этой статье мы поделимся опытом внедрения структурированного шаблона функциональных требований (ФТ) к разработке ПО в нашем банке.
Статья будет полезна тем, кто работает с фронтовым функционалом – системными и бизнес-аналитикам. Неважно, Junior вы или Lead, в большой работаете компании или в стартапе, – наш рассказ вас наверняка заинтересует. Поговорим не только о том, как мы докатились до такой жизни, приняли единый формат ФТ, но и том, какие именно артефакты аналитик готовит в ходе своей работы. А еще мы подробно расскажем про причины поиска подходящего формата, сложности перехода и составляющие наших ФТ.
Потребность в единообразии
В документации содержатся описания экранных форм, взаимодействия с бэком, обработки ошибок, архитектурные диаграммы, бизнес-требования. Все это должно помочь тестировщикам, разработчикам и бизнесу понять происходящее в функционале без необходимости лезть в код.
Многие аналитики, сами того не желая, пишут непонятную и запутанную документацию без структуры. Или бывает такое, что аналитик пишет понятно, но из-за того, что он работает над проектом не один, в общей массе получается каша. Ведь полное описание даже небольшой фичи каждому аналитику представляется абсолютно по-своему. Это сильно затрудняет как работу над документацией, так и ее восприятие.
Поэтому мы постарались собрать лучшие мысли наших аналитиков, отмести ненужное и на основе этого создать шаблон документации. Сначала мы хотели найти какое-то готовое решение, но сейчас есть в основном ГОСТы, для нас они перегружены. Есть еще открытые стандарты типа UML, но их можно использовать только точечно. Например, для построения диаграмм. Все наши потребности такие стандарты не закрывают.
Структура шаблона
В ходе обсуждений и анализа актуальной документации выяснилось, что самое главное для нас – наличие следующих разделов:
- точки входа;
- бизнес-требования;
- пользовательские сценарии;
- дизайн;
- архитектура.
Давайте пройдемся по каждому из разделов.
Мы ведем документацию в Confluence и ниже вы можете встретить наш опыт по работе именно с этим инструментом. Но если вы пользуетесь Word, Notion или чем-то еще, – вы тоже можете использовать наш шаблон, просто придется подумать над его адаптацией для вашего инструмента.
Точки входа
Они отвечают на вопрос «Как пользователь может попасть в описываемый функционал?». Чем нагляднее описаны точки входа – тем проще будет неподготовленному человеку найти ваш функционал.
Например, в квартиру мы можем попасть через главный вход, запасной вход и подземную парковку. А в фичу мы можем попасть с каких-то других страниц.
Вот так это выглядит у нас:
В этот раздел мы решили добавлять скриншоты или макеты, они упрощают восприятие.
Еще стараемся давать ссылки на описание другой фичи, из которой возможен переход. Это позволит переходить по документации, как по продукту.
Полезная функция: функционал Confluence в информации о странице позволяет посмотреть все входящие связи. Поэтому, если вы уже где-то оставляли ссылку в других статьях на нужную страницу, то найти все точки входа можно именно через информацию о странице.
Бизнес-требования
Тут мы собираем информацию, которая была предоставлена бизнесом на вход, а также ожидаемые финансовые результаты от внедрения этой фичи, бенч-исследования. Честно сказать, этот раздел в нашем ФТ наименее структурирован, так как источником бизнес-требований (БТ) выступают заказчики, а они могут быть очень разными. Часто используется формат Пользовательских историй (User Story). Подробнее о них можно почитать, например, тут.
В идеальном случае в БТ стоит зафиксировать такую информацию:
- краткое описание задачи/фичи – вся суть в 2 предложениях;
- обоснование задачи/фичи – зачем ее выполнять, что это даст;
- рамки задачи и роли – перечень процессов и задействованных ролей. С комментариями, какие процессы новые, какие изменяются, что именно меняется;
- ограничения – важные допущения и их причины/обоснования;
- описание бизнес-процессов в виде «схема + текст» с указанием ролей. Если изменяется существующий процесс – схемы AS IS и TO BE. Если процесс очень простой – можно обойтись без схемы;
- описание интерфейсов – подготовленные макеты;
- нефункциональные требования – скорость работы, прогнозируемая нагрузка и прочее.
Сценарии
Мы включили в шаблон Use Cases (Сценарии использования), потому, что это один из основных инструментов аналитика, используемых в написании ФТ. Суть UC состоит в том, что мы описываем взаимодействие пользователя и разрабатываемой системы по шагам. Очень показательный пример, объясняющий принцип написания Сценариев использования приводит в своей книге «Современные методы описания функциональных требований к системам» Алистер Коберн. Он советует представить, что ваш сценарий – это передачи футбольного мяча от одного игрока к другому. Важно не терять мяч и отслеживать, кто им владеет на каждом шаге сценария, логична ли была передача, не потеряли ли мы мяч на каком-либо этапе. Чтобы было нагляднее, я опишу процесс открытия страницы со списком сущности Сегмент:
Первое, что бросается в глаза – это строка с Предусловием. Предусловия – неотъемлемая часть UC. Часто для того, чтобы воспроизвести сценарий, нужно заранее выполнить несколько действий. Например, авторизоваться, создать заказ (для сценария оплаты заказа) и так далее.
Далее вы можете наблюдать взаимодействие 3 систем в вышеописанном сценарии: пользователя, сайта (фронта) и сервиса (бэка). Важно следить, чтобы «мяч» передавался от одной системы к другой без потерь и разрывов. Базовый сценарий, как правило, описывает полный успешный вариант использования. Альтернативный сценарий начинается с определенного шага и описывает как бы ответвление от базового сценария. Важно описывать все альтернативные сценарии для того, чтобы у разработчиков было меньше вопросов, а у тестировщиков – готовая фактура для написания тест-кейсов.
Последнее, что хотелось бы сказать про Сценарии использования – это их длина. Рекомендуется не делать сценарии слишком длинными и запутанными, достаточно ограничиться 9 основными шагами. Если же их не хватает, то дробим сценарий на несколько сценариев. Например, как тут:
Архитектура
В нашем банке было принято решение, что все ФТ-аналитики должны сопровождать визуальным описанием взаимодействия систем. Минимальной необходимостью стала диаграмма последовательности (sequence diagram). Конечно, приветствуется и поощряется, если аналитик решил добавить схему, отрисованную в BPMN или какую-нибудь другую UML-диаграмму при необходимости. Но диаграмма последовательности – это наш мастхев. На этой же странице в Confluence мы добавляем список API-методов, которые отображены на диаграмме.
Диаграмма последовательности визуализирует взаимодействие пользователя и системы или нескольких систем (это очень красиво и интересно).
Выглядит диаграмма вот так:
Мы не будем детально описывать, что означает каждый элемент этой диаграммы, так как объем нашей статьи не безграничен. Хотим лишь рассказать, что диаграмму последовательности можно запилить не только в таких графических инструментах, как draw.io, но с помощью текста (для тех, кто хочет быть хоть чуть-чуть ближе к разрабам), используя PlantUML. Очень классный инструмент, оставляем ссылки на инструкцию и редактор.
В Confluence диаграмму из PlantUML можно добавить с помощью макроса PlantUML Macro, он преобразует текст в картинку и вы всегда будете иметь доступ к исходному коду.
Дизайн
Во вкладке Дизайн описываются все экранные формы. Мы решили делать это так – создаем таблицу такой структуры:
В колонку Макет вставляем одно изображение, которое дает представление об общем виде функционала. Колонка Название элементов заполняется названиями компонентов из макета, например «сумма», «кнопка далее», «информационное окно о комиссии» и тому подобное.
В логике же содержится уже полное описание поведения поля. В первую очередь, для его описания нужно понять, можно ли это поле редактировать.
Описание нередактируемых элементов
В качестве нередактируемых элементов могут выступать:
- статичный текст, гиперссылка, документ и так далее;
- поле со статичным значением. Нужно описать его источник и при необходимости правила вывода.
Описание редактируемых полей
Для описания используем такую структуру для основных типов полей:
Текстовое поле
Прописываем маску, если она есть
Максимальное количество символов
Пишем число, после которого ввод будет невозможен
Минимальное количество символов
Пишем минимальное количество символов, если такое имеется
Возможные символы для ввода
Если есть какие-то ограничения, то можно просто прописать регулярное выражение
Значение по умолчанию
Прописываем, какое и откуда значение по умолчанию (если есть)
Валидация после ввода
Например, на соответствие формату e-mail. Рекомендуется сразу писать, что отображать в случае ошибки.
Валидаций может быть несколько, мы указываем их в порядке приоритета.
Ввод числа
Аналогично текстовому полю
Аналогично текстовому полю
Пишем максимальное число для ввода. Оно может быть динамическим, тогда нужно прописать источник
Возможные символы для ввода
Аналогично текстовому полю
Значение по умолчанию
Аналогично текстовому полю
Валидация после ввода
Аналогично текстовому полю. Скорее всего, будет еще валидация на соответствие диапазону
Чек-бокс
Значение по умолчанию
Слайдер
Правое значение слайдера
Левое значение слайдера
Сколько единиц в одном делением слайдера
Значение по умолчанию
Аналогично текстовому полю
Могут быть нестандартные ситуации. Например, к введенному числу в поле надо добавлять «месяцы» или «месяцев». Можно это добавить как строку «другое», а если история повторяется часто, то вынести как отдельную строку «единицы измерения» в шаблоне.
Общий вид ФТ
Ранее мы рассмотрели, из каких частей состоят наши ФТ. Каждую часть мы описываем в отдельной странице. Теперь давайте соединим части. Для этого мы создаем головную страницу, к которой уже будет крепиться все содержимое.
Крепим содержимое мы с помощью трех макросов:
Aura Tab Group – позволяет создать бар из вкладок;
Aura Tab – позволяет включить вкладку в бар;
Включить страницу (стандартный) – позволяет подтянуть контент из другой страницы.
Получаем ФТ с вкладками. Нам очень нравится, что благодаря вкладкам ФТ не превращается в бесконечный вертикальный документ.
Каждое описание сопровождается таблицей с ссылками на задачи в Jira. Это позволяет достаточно быстро найти нужную задачу в процессе чтения документации. Выглядит таблица так:
Внедрение шаблона
Confluence дает возможность создания шаблона, в котором можно разместить болванку для быстрого создания документации по нашему шаблону, чтобы не создавать все эти таблицы и не прикреплять макросы каждый раз.
Если у вас нет каких-то кнопок, обратитесь к администратору.
Мы создали по шаблону на каждый раздел, теперь при клике на три точки он будет показываться в списке.
После создания шаблона нужно провести коммуникацию с командами, рассказать, показать, попросить использовать созданные шаблоны, ответить на вопросы.
Остается лишь собирать обратную связь, на основе которой в дальнейшем предстоит улучшать шаблон. Причем обратная связь нужна не только от аналитиков, но и от тестировщиков, разработчиков и остальных потребителей. Ведь мы пишем документацию не ради документации, а ради общего удобства.
Дальнейшие шаги
В нашем банке есть 4 кластера. В каждом из них функционируют свои продуктовые команды, и конечно, в них есть системные аналитики, много аналитиков. Амбассадором внедрения единого шаблона стал наш кластер. У нас есть еженедельные синки системных аналитиков, где мы обсуждаем текущие задачи, интересные кейсы, делимся опытом и задаем вопросы. Комьюнити аналитиков в банке постоянно развивается, меняются задачи, появляются новые идеи.
Знакомясь с документацией коллег по цеху мы видим, что каждый аналитик, использует общепринятый шаблон, немного приспосабливая его под себя.
Кто-то добавляет новые вкладки к основным, кто-то придумывает, как описать исключения, чтобы тестировщикам было удобно работать с документацией. А кто-то исключает некоторые разделы из шаблона из-за специфики задач команды.
Наш шаблон ФТ имеет некую универсальность за счет макроса Auro, который позволяет ему быть гибким, легко изменяемым и развивающимся. Главное во всей проделанной нами работе – то, что отдел аналитиков банка быстрыми шагами движется к единообразию в описании функционала.
Мы ловим отзывы от разрабов и тестеров, что раньше нужно было переключаться с одного описания на другое. Это было непросто в случае, если описания созданы в разных форматах. Когда привыкаешь к определенному шаблону документации – скорость работы увеличивается, так как ты можешь быстро найти тот раздел, который нужен именно сейчас.
Во всем нужно искать золотую середину. С одной стороны, важны постоянные улучшения и непрерывное развитие. С другой стороны, единообразие никто не отменял и даже более того, к нему советуют стремиться. Кажется, что у нас получилось найти такой формат, который отвечает обоим требованиям.
Конечно, мы осознаем, что в процессе разработки ПО, особенно в крупных банках, порождает гораздо больший набор артефактов (схемы развертывания, ролевые модели, сетевые схемы, требования к логированию/мониторингу и так далее). Возможно мы интегрируем их в шаблон в будущем.. А пока мы нашли компромисс между объемом, подробностью документации и скоростью ее подготовки.
Надеемся, что эту статью вы прочитали с интересом, и информация из нее пригодится вам в работе. Ждем ваши вопросы и замечания в комментариях. Там же просим рассказывать о вашем опыте работы с функциональными требованиями. Спасибо за уделенное время!
Источник: temofeev.ru
Основные форматы представления требований
Текстовая расшифровка одиннадцатого урока курса Введение в профессию аналитика.
В этом модуле мы очень поверхностно рассмотрим основные форматы представления требований, с акцентом на . На прошлом вебинаре мы рассматривали уровни требований, и я теперь постоянно буду эту терминологию использовать.
На уровне сводными документами, как мы говорили, является концепция (Vision) и техническое задание.
Я вам сначала покажу примеры концепций, а потом мы сформулируем выводы. Rational Unified Process, о котором я говорил, — это фактически большая база знаний о том, как создавать разные продукты. Мы ему должны быть благодарны, , за явное выделение роли аналитиков и их специализаций. Именно в RUP были детально впервые описаны разные роли аналитиков — в частности, , системного аналитика и ещё некоторые дополнительные роли.
А , мы должны быть ему благодарны за большое количество шаблонов документов, которые в его рамках были разработаны. В том числе несколько шаблонов концепций.
Здесь у меня два примера концепций.
Вот первый. Это очень распространённый шаблон, который я сам не раз использовал для написания концепции. Что он нам даёт? Он показывает, какие должны быть описаны, не предлагая готовых форматов. Форматы в данном случае могут быть достаточно произвольными — текстовыми или в виде диаграмм.
Но структура и сущность этих очень хорошо в структуре этого документа описана.
Вот второй, чуть более подробный пример. Чем он отличается от предыдущего? Это просто более подробный шаблон. И RUP предлагал, в зависимости от сложности и от назначения вашего продукта, воспользоваться из готовых шаблонов. А для нас они ценны тем, что задают структуру описания бизнес требований.
Этот модуль называется «форматы представления требований». И применительно к я хотел показать, что нет однозначных форм для их описания, но есть достаточно хорошо проработанное представление о том, что же является , и что надо учесть, когда мы их разрабатываем.
Требования описываются в текстовом виде. Этот шаблон я сначала назвал плохим шаблоном, но потом исправил на «спорный». В одном из курсов предлагается каждое требование описывать в такой форме, в виде таблички со строками:
- формулировка требования,
- какая цель будет достигнута при его реализации,
- причина возникновения требования, кто
- будет работать с функциями, которые оно реализует,
- источник данных,
- правила, связанные с требованием и
- трассировка на функции, которые его реализуют.
На самом деле, разрабатывать требования в таком формате — это самоубийство.
Единственная причина, почему я поменял «плохой» на «спорный»: вы всё же можете иногда использовать этот шаблон — в ситуации когда кругом враги, всё нужно записывать, никому верить нельзя, и всё, что вы говорите, будет использовано против вас. Если говорить серьёзно, такой шаблон явно избыточен, и заполнять такую табличку для каждого требования я не вижу необходимости.
Хотя некоторые полезные вещи тут есть. Формулировка самого требования и описание контекста (зачем это требование реализуется) — это важнейшие вещи, которые в каждом требовании должны присутствовать. И ещё очень полезна трассировка на функции, хотя вряд ли её надо описывать в виде таблички. Её лучше делать с использованием современных систем управления требованиями.
Вы должны знать, что такие шаблоны бывают, и в некоторых курсах даже рекомендуются к использованию. Но, с моей точки зрения, это совершено бессмысленный шаблон, потому что он даёт очень мало пользы в приближении к создаваемому продукту.
Есть ещё такие рекомендации по формулировке требований. Они взяты с сайта сообщества аналитиков uml2.ru, активным участником которого я являюсь. Это просто рекомендации, которые предлагают вам текстовые шаблоны для описания требований. Они, может быть, покажутся вам тривиальными, но иногда бывает полезно ими воспользоваться.
Важная мысль, которую они доносят: то, что вместе с требованием обычно нужно ещё давать его контекст, то есть объяснять, зачем это требование реализуется. Я не буду сейчас их подробно рассматривать. Этим слайдом я только хотел показать, что если вы не знаете, как правильно сформулировать требование, то рекомендации вы легко можете найти. Они бывают плохими, бывают хорошими.
Предыдущая с моей точки зрения, была плохая. Эта, тоже с моей точки зрения, — неплохая.
Подводя итог по этому уровню, по уровню . Требования могут представляться в произвольном виде, в виде текста или диаграмм. Жёстких форматов, как правило, нет, а если они есть, то нужно понимать, кто и с какой целью их придумал. Но есть структура сводных документов и есть определённые наработанные практики по разработке . Эти практики и структура очень полезны, и им желательно следовать. В нашем курсе мы будем разрабатывать концепцию, руководствуясь одним из таких шаблонов.
Переходим на уровень пользовательских требований. Уровень пользовательских требований наилучшим образом проработан. Есть конкретные методы их разработки, написаны книги, по каждому из этих методов проводятся курсы, обучающие, как разрабатывать требования именно в этих форматах. Здесь перечислены основные форматы.
Самый известный, лучше всех проработанный метод, — разработка требований с помощью вариантов использования, или use cases. Для них иногда используется название прецеденты.
Есть известная книга Алистера Коберна «Современные методы разработки функциональных требований к системам». Мы ещё будем в курсе на неё ссылаться. Это плохой и устаревший перевод названия книги «Writing Effective Use Cases», но он отражал именно тот факт, что на момент написания этой книги это был лучше всего проработанный и всеми признаваемый метод разработки требований к системам. Он описывает, как люди взаимодействуют с системой в виде пошаговых сценариев.
User Stories — это другой формат описания пользовательских требований, который мы тоже будем в этом курсе рассматривать. У него есть существенные отличия от вариантов использования. Это не такой глубокий формат.
Если варианты использования предполагают, что сценарий прописывается детально до начала реализации, то User Story обозначает только цель пользователя и контекст, зачем это ему нужно. Этот формат предназначен, в первую очередь, для обсуждения внутри команды. У User Story есть начальный вариант, который предлагается для обсуждения, а в результате обсуждения к ней добавляются комментарии, атрибуты и определённые формы требований. Этот формат предназначен для того, чтобы быстро собирать требования, быстро их описывать, быстро обсуждать, анализировать, и тут же запускать в работу.
Есть ещё один метод, которого мы коснёмся в курсе. Это сценарии, основанные на персонажах. Метод разработан Аланом Купером. Он написал книгу «Об интерфейсе», где этот метод описан. Основная идея его состоит в том, что, когда вы разрабатываете продукт для массового пользователя, нельзя для разных классов пользователей использовать одни и те же сценарии работы с вашим продуктом.
Он предлагает выделять для пользователей определённые классы, или сегменты пользователей, различающиеся своим поведением, своим опытом, отношением к продукту и целями. И для каждого из этих классов разрабатывать свой сценарий взаимодействия с вашим продуктом, а потом продукт делать так, чтобы он удовлетворил потребности всех этих пользователей. Почему я говорю вам об этом методе? Сейчас всё больше ожидается, что аналитики должны этим методом владеть. Хотя у него есть определённые ограничения, и не все могут его использовать.
Ещё один метод описания требований на пользовательском уровне — это описание бизнес процессов. Многие из вас наверняка с этим методом работали. Здесь тоже есть свои подходы, специальные нотации, свои методы, описывающие то, как люди взаимодействуют между собой для достижения своих целей. И как они при этом задействуют разрабатываемый нами продукт.
На самом деле, отражают гораздо больше разных аспектов, кроме взаимодействия людей. Но если говорить о разработке программных продуктов, то в первую очередь моделируется именно взаимодействие людей и систем между собой по определённым сценариям.
Это самые основные, самые известные методы описания пользовательских требований, и первые три из них мы затронем в нашем курсе. — это отдельная тема.
Какие из этих методов применяются, если говорить об ? На предыдущем вебинаре мы вспоминали определение автоматизированной системы. Говорили о том, что это комплекс средств автоматизации, включающий персонал, реализующий информационную технологию для реализации определённых функций. Мы говорили о том, что персонал является частью автоматизированной системы и поэтому при разработке требований мы можем принимать во внимание, что люди выполняют функции в рамках автоматизированной системы. Что цель им навязывается этой системой, и что у этих людей есть определённая квалификация, их специально обучают, чтобы эти функции выполнять. Поэтому методы разработки пользовательских требований, которые возникли в эпоху автоматизированных систем, часто бывают неприменимы при разработке сайтов.
Но у большинства есть две стороны. Их часто называют и . Фронт — это то, чем избушка повёрнута к лесу, где она взаимодействует с пользователем, для которого продукт создан. Это массовый пользователь интернета. А с другой стороны, для того, что бы этот сервис обслуживать, есть сотрудники компании, которые этот сервис эксплуатируют, и их вполне можно подвести под определение автоматизированной системы.
Например, если принимает деньги от пользователя, то с другой его стороны есть бухгалтерия, и для неё нужно реализовать функциональность, которая позволяет ей своих целей достигать. Если продаёт билеты или позволяет выбирать билеты для авиакомпаний, то, соответственно, есть сотрудники, которые работу этого сервиса обеспечивают. Техническая поддержка есть, наверное, есть служба эксплуатации, есть, опять же, бухгалтерия. И со стороны вполне применимы методы, которые разработаны для автоматизированных систем. А это, если предыдущий слайд посмотреть, в первую очередь Use Cases и . при разработке для эти методы бывают очень хорошо применимы.
Если говорить о массовом пользователе, то его в эту схему не втиснешь. Таких пользователей не заставишь достигать своих целей в рамках вашей системы. И поэтому применяются другие методы. Для них больше подходят User Stories и метод персон. Он, собственно, для решения этой проблемы и предназначен.
Но если вы как аналитик участвуете в разработке требований к системе, то вы можете принимать участие в разработке двух сторон системы и применять соответствующие методы.
Иногда бывают ситуации, в которых Use Cases можно применять и по отношению к массовым пользователям, в том случае, когда их нужно провести через достаточно строгую процедуру. Это, например, процедура покупки билета или процедура оплаты заказа. Бывают такие достаточно узкие рамки, в которые пользователя надо втиснуть, чтобы он достиг своей цели. Для его же блага, что называется. Но таких ситуаций, в , очень немного.
Если мы говорим об интерфейсах для массовых пользователей, то там эти методы обычно неприменимы. Хотя очень часто видишь в интернете, где аналитик применял метод Use Case и попытался вас втиснуть в свою процедуру, потому что он им владеет, и хочет, чтобы вы шли только по тому сценарию, который он разработал. Но при попытке выйти за рамки этого сценария всё идёт не так.
Если говорить о самом низком уровне — уровне требований к реализации, то методы разработки требований невозможно подвести под общий знаменатель. Это очень разнообразные способы представления требований, выбор которых зависит от создаваемого продукта.
К ним можно, например, отнести макеты пользовательского интерфейса, когда вы детально прорабатываете, как должен выглядеть ваш сайт, и все сценарии взаимодействия пользователей вам известны. Тогда вступают в работу более низкоуровневые требования, где детально описываются с точностью до пикселя пакеты интерфейсов.
алгоритмы, которые должны быть реализованы, структура моделей данных — часто аналитикам приходится участвовать и в разработке таких вещей. Диаграммы классов рисовать, модель базы данных разрабатывать. Хотя по определению это работа не аналитика, а разработчика или архитектора. Но, тем не менее, аналитикам приходится этим заниматься. Сценарии взаимодействия отдельных частей системы между собой, спецификации детального взаимодействия с внешними системами на уровне отдельных полей Конечно этот перечень не исчерпывающий, но я бы сказал, что этот уровень невозможно детально классифицировать по способам представления требований.
Источник: www.webursitet.ru