Цель статьи — показать, как бизнес-аналитик может донести функциональные требования к программному решению до команды разработки — с максимальной детализацией, плюс отталкиваясь от UI (интерфейса пользователя).
Дисклеймер: это статья для новичков, то есть тут будет хватать философски спорных вещей, о которых джедаи-БА любят поворчать за пивком. Тем не менее, многие вещи будут сознательно упрощены, чтобы дать рабочий инструмент и рекомендации. При этом, определенное погружение в теорию бизнес-анализа, конечно, потребуется.
Давайте для начала очертим контекст. Какова конечная задача аналитика в наших реалиях? Передать команде разработки требования. Какие требования? Требования к решению, дабы команда смогла построить такое решение, которое будет соответствовать пожеланиям заказчика и будущих пользователей. А что у нас такое требования к решению? Это конечный уровень в иерархии требований (например, иерархии по BABOK), состоящий из функциональных и нефункциональных требований. Опустим нефункциональные — это out of scope для данной статьи. Львиную долю (и в первую очередь по своей значимости) требований к решению составляют функциональные требования — это требования к функциональности системы, т. е. к тому, какой набор возможностей (функций) должна предоставлять система и каково должно быть наполнение этих функций. Если детализировать требования дальше, то один из популярных взглядов (НЕ приведено в BABOK, но используется многими на практике) гласит, что функциональные требования, в свою очередь, состоят из двух ключевых компонентов: требования к функциональности/поведению (основная часть) и требования к данным, которыми сие поведение будет оперировать (второстепенная часть). Требования к данным мы также опустим — это отдельный любопытный блок требований со своими техниками и подходами.
Соответственно, теперь вопрос можно поставить так: какие есть подходы к фиксации самых-самых основных требований, которые ожидаются от аналитика по факту его работы?
Есть разные подходы, и о большинстве вы, если вы аналитик, активно работающий с требованиями, слышали или освоили в той или иной мере: user stories с критериями приемки (свойственно agile-/адаптивному подходу к бизнес-анализу), use cases с детализацией, прототипы UI с текстовыми пометками, тупо описание человеческим языком абы как-то да поставить задачу (что довольно часто практикуется в условиях отсутствия поставленных процессов БА) и пр.
Но что, если в силу выбранного подхода к БА вам нужно проработать и зафиксировать подобные требования максимально подробно? Какие варианты есть для этого? Очевидно, что это не всегда нужно, но легче упростить свою задачу, умея делать ее досконально, чем наоборот, не так ли?
Принято, что контейнеры с максимальной детализацией требований — это артефакты, свойственные предиктивному подходу: Software Requirements Specification (спецификация требований к ПО), ТЗ (Техническое Задание), Functional Specification и прочие слова-синонимы, представляющие в своей сути таки одно — документ, детально описывающий требования к решению. Однако, то, как подать функциональные требования в рамках подобного документа, также может варьироваться и подвержено разным стандартам, подходам и вкусовщине. Например, наш любимый дядюшка Карл (Вигерс который) рекомендует в рамках SRS писать целевые требования так:
Дисклеймер: это статья для новичков, то есть тут будет хватать философски спорных вещей, о которых джедаи-БА любят поворчать за пивком. Тем не менее, многие вещи будут сознательно упрощены, чтобы дать рабочий инструмент и рекомендации. При этом, определенное погружение в теорию бизнес-анализа, конечно, потребуется.
Давайте для начала очертим контекст. Какова конечная задача аналитика в наших реалиях? Передать команде разработки требования. Какие требования? Требования к решению, дабы команда смогла построить такое решение, которое будет соответствовать пожеланиям заказчика и будущих пользователей. А что у нас такое требования к решению? Это конечный уровень в иерархии требований (например, иерархии по BABOK), состоящий из функциональных и нефункциональных требований. Опустим нефункциональные — это out of scope для данной статьи. Львиную долю (и в первую очередь по своей значимости) требований к решению составляют функциональные требования — это требования к функциональности системы, т. е. к тому, какой набор возможностей (функций) должна предоставлять система и каково должно быть наполнение этих функций. Если детализировать требования дальше, то один из популярных взглядов (НЕ приведено в BABOK, но используется многими на практике) гласит, что функциональные требования, в свою очередь, состоят из двух ключевых компонентов: требования к функциональности/поведению (основная часть) и требования к данным, которыми сие поведение будет оперировать (второстепенная часть). Требования к данным мы также опустим — это отдельный любопытный блок требований со своими техниками и подходами.
Соответственно, теперь вопрос можно поставить так: какие есть подходы к фиксации самых-самых основных требований, которые ожидаются от аналитика по факту его работы?
Есть разные подходы, и о большинстве вы, если вы аналитик, активно работающий с требованиями, слышали или освоили в той или иной мере: user stories с критериями приемки (свойственно agile-/адаптивному подходу к бизнес-анализу), use cases с детализацией, прототипы UI с текстовыми пометками, тупо описание человеческим языком абы как-то да поставить задачу (что довольно часто практикуется в условиях отсутствия поставленных процессов БА) и пр.
Но что, если в силу выбранного подхода к БА вам нужно проработать и зафиксировать подобные требования максимально подробно? Какие варианты есть для этого? Очевидно, что это не всегда нужно, но легче упростить свою задачу, умея делать ее досконально, чем наоборот, не так ли?
Принято, что контейнеры с максимальной детализацией требований — это артефакты, свойственные предиктивному подходу: Software Requirements Specification (спецификация требований к ПО), ТЗ (Техническое Задание), Functional Specification и прочие слова-синонимы, представляющие в своей сути таки одно — документ, детально описывающий требования к решению. Однако, то, как подать функциональные требования в рамках подобного документа, также может варьироваться и подвержено разным стандартам, подходам и вкусовщине. Например, наш любимый дядюшка Карл (Вигерс который) рекомендует в рамках SRS писать целевые требования так:
Не могу сказать, что это максимально возможная детализация, не допускающая креатива со стороны исполнителей, но тут мы подходим к одному из важных вопросов, с которым аналитику нужно определиться — кто в проектной команде отвечает за UI/UX?
Интерфейс пользователя и опыт взаимодействия пользователей с системой (как, непосредственно, в привязке к UI, так и в целом, за рамками сугубо интерфейса) — это часть требований к системе в одних проектных реалиях и вне рамок требований — в иных. Почему это важно? Классический аналитик фокусируется на требованиях. Классический аналитик старается по максимуму избегать деталей реализации решения (например, база данных и ее структура, архитектура кода и системы и пр.). Требования классического аналитика должны оставаться на уровне требований, не оперируя этими самыми деталями (например, N в INVEST для User Stories прямо так и кричит: stories should capture the essence of the requirement and should not represent a contract on how to solve it), иначе аналитик навяжет решения мудрым людям, обладающим компетенциями сделать эту работу лучше (например, даст команде на вход структуру базы данных, с которой местный администратор БД выпадет в осадок).
Так чем же считать UI со всеми его формочками, полями, списочками и кнопочками? Ответ зависит от того, как принято у вас в компании/отделе/команде/проекте. Как правило, если есть человек, отвечающий за это в явном виде и умеющий в это лучше, чем вы как аналитик, то UI — это НЕ требования, а реализация решения, и требования аналитика должны быть UI-free. Пример Карла Вигерса выше — это как раз то, как описать требования, не затрагивая при этом UI как способ их реализации. User Stories с обеспеченным N — в ту же степь. Классические Use Cases по рекомендациям мастеров Шаолиня — туда же (интерфейсонезависимые, свободные от специфик реализации).
Но так ли всегда на практике? Нет, часто встречаются аналитики, в компетенции которых — проектировать UI системы, ибо пригоднее в команде никого нет. В таком случае отличным вариантом может быть интеграция UI в требования и трактовка этой области как их части. И как раз для такого случая я поделюсь базовым подходом, позволяющим практически максимально детально описать требования к поведению системы, взяв UI за основу. Все, что я опишу ниже, применимо в первую очередь для артефактов максимальной детализации, о которых речь велась выше, но это не означает, что этому место только в SRS и нигде более. Если вы гибкий аналитик, не признающий догм и условностей, вы запросто можете заполнить ваши User Stories или постановки задач в Jira подобным контентом, если это послужит на благо вашей цели документирования.
Давайте возьмем какой-нибудь простой пример, в котором будет как просмотр, так и внесение информации в систему. Пусть у нас будет некий абстрактный каталог товаров с возможностью добавить новый товар — такая вот простая веб-страничка для администраторов какого-то крайне урезанного Интернет-магазина. Соответственно, с точки зрения UI тут у нас одна страница, плюс всплывающее окошко для добавления товара:
Интерфейс пользователя и опыт взаимодействия пользователей с системой (как, непосредственно, в привязке к UI, так и в целом, за рамками сугубо интерфейса) — это часть требований к системе в одних проектных реалиях и вне рамок требований — в иных. Почему это важно? Классический аналитик фокусируется на требованиях. Классический аналитик старается по максимуму избегать деталей реализации решения (например, база данных и ее структура, архитектура кода и системы и пр.). Требования классического аналитика должны оставаться на уровне требований, не оперируя этими самыми деталями (например, N в INVEST для User Stories прямо так и кричит: stories should capture the essence of the requirement and should not represent a contract on how to solve it), иначе аналитик навяжет решения мудрым людям, обладающим компетенциями сделать эту работу лучше (например, даст команде на вход структуру базы данных, с которой местный администратор БД выпадет в осадок).
Так чем же считать UI со всеми его формочками, полями, списочками и кнопочками? Ответ зависит от того, как принято у вас в компании/отделе/команде/проекте. Как правило, если есть человек, отвечающий за это в явном виде и умеющий в это лучше, чем вы как аналитик, то UI — это НЕ требования, а реализация решения, и требования аналитика должны быть UI-free. Пример Карла Вигерса выше — это как раз то, как описать требования, не затрагивая при этом UI как способ их реализации. User Stories с обеспеченным N — в ту же степь. Классические Use Cases по рекомендациям мастеров Шаолиня — туда же (интерфейсонезависимые, свободные от специфик реализации).
Но так ли всегда на практике? Нет, часто встречаются аналитики, в компетенции которых — проектировать UI системы, ибо пригоднее в команде никого нет. В таком случае отличным вариантом может быть интеграция UI в требования и трактовка этой области как их части. И как раз для такого случая я поделюсь базовым подходом, позволяющим практически максимально детально описать требования к поведению системы, взяв UI за основу. Все, что я опишу ниже, применимо в первую очередь для артефактов максимальной детализации, о которых речь велась выше, но это не означает, что этому место только в SRS и нигде более. Если вы гибкий аналитик, не признающий догм и условностей, вы запросто можете заполнить ваши User Stories или постановки задач в Jira подобным контентом, если это послужит на благо вашей цели документирования.
Давайте возьмем какой-нибудь простой пример, в котором будет как просмотр, так и внесение информации в систему. Пусть у нас будет некий абстрактный каталог товаров с возможностью добавить новый товар — такая вот простая веб-страничка для администраторов какого-то крайне урезанного Интернет-магазина. Соответственно, с точки зрения UI тут у нас одна страница, плюс всплывающее окошко для добавления товара:
Давайте вернемся к способам документирования требований к поведению, описанным выше, и кратко вспомним, как вы могли бы донести требования к такой системе до команды:
- Создать ряд User Stories (например, Просмотр товаров и Добавление товара) в Confluence и заполнить их критериями приемки (в формате GWT или любом ином).
- Сделать то же самое, только в виде Use Cases (Просмотреть товары Интернет-магазина и Добавить новый товар) с детализацией (все эти предусловия, сценарии и прочие параметры), которые вы можете разместить, где угодно (да хоть бы в той же самой Confluence).
- Нарисовать макет (собственно, он нарисован выше) и текстовыми пометками пояснить наиболее важные детали, неясные сходу из макета, прямо на скрине. Кстати, вполне себе вариант для такой «мегасложной» системы — зачем заморачиваться? 😊 И просто прикрепить это к таскам в Jira как постановку задачи.
- Написать SRS по образу и подобию скриншота из книги Карла Вигерса выше, ТЗ и другие страшные документы. Да-да, с титульным листом, историей изменений и всем этим прочим блэкджеком.
Этими вариантами способы подачи требований не ограничиваются — комбинаций техник, артефактов (контейнеров) и систем хранения информации не счесть, но я привел готовые рабочие варианты.
Наша с вами задача — показать, как это может быть подано в контексте последнего из вариантов в списке, но в привязке к UI. Давайте это и сделаем.
Если представить, что вы пишете SRS, то во всех популярных шаблонах для этого документа будет раздел, называющийся как-то в духе Functional Requirements, куда вам и нужно запихнуть функциональные поведенческие требования к элементам скоупа решения. Например, в контексте структуры документа это может выглядеть так:
- Создать ряд User Stories (например, Просмотр товаров и Добавление товара) в Confluence и заполнить их критериями приемки (в формате GWT или любом ином).
- Сделать то же самое, только в виде Use Cases (Просмотреть товары Интернет-магазина и Добавить новый товар) с детализацией (все эти предусловия, сценарии и прочие параметры), которые вы можете разместить, где угодно (да хоть бы в той же самой Confluence).
- Нарисовать макет (собственно, он нарисован выше) и текстовыми пометками пояснить наиболее важные детали, неясные сходу из макета, прямо на скрине. Кстати, вполне себе вариант для такой «мегасложной» системы — зачем заморачиваться? 😊 И просто прикрепить это к таскам в Jira как постановку задачи.
- Написать SRS по образу и подобию скриншота из книги Карла Вигерса выше, ТЗ и другие страшные документы. Да-да, с титульным листом, историей изменений и всем этим прочим блэкджеком.
Этими вариантами способы подачи требований не ограничиваются — комбинаций техник, артефактов (контейнеров) и систем хранения информации не счесть, но я привел готовые рабочие варианты.
Наша с вами задача — показать, как это может быть подано в контексте последнего из вариантов в списке, но в привязке к UI. Давайте это и сделаем.
Если представить, что вы пишете SRS, то во всех популярных шаблонах для этого документа будет раздел, называющийся как-то в духе Functional Requirements, куда вам и нужно запихнуть функциональные поведенческие требования к элементам скоупа решения. Например, в контексте структуры документа это может выглядеть так:
В этом разделе вы можете (и стоит) сгруппировать требования по структурным элементам скоупа системы. Например, это могут быть фичи (Features). Но могли бы быть и Use Cases или даже User Stories.
В рамках каждой фичи в разделе 2 в приведенном примере мы имеем подглаву «Описание интерфейса пользователя», где мы и будем в рамках данной статьи проводить бОльшую часть времени. Думаю, понятно, что если необходимо описать какие-либо функциональные требования вне привязки к UI (например, автоматическая рассылка системой почтовых уведомлений по расписанию), то вы просто переименуете подглаву в рамках такой фичи в нечто иное, т. к. UI там будет неприменим.
Итак, что описывать в главе «Описание интерфейса пользователя»?
Во-первых, выделите ключевые структурные элементы вашего UI (страницы, экраны, всплывающие окна и пр.) — это будет основа для дальнейшей структуризации требований в рамках каждой фичи. Во-вторых, определите их принадлежность к фичам. Например, вот, как это будет выглядеть для нашего примера:
В рамках каждой фичи в разделе 2 в приведенном примере мы имеем подглаву «Описание интерфейса пользователя», где мы и будем в рамках данной статьи проводить бОльшую часть времени. Думаю, понятно, что если необходимо описать какие-либо функциональные требования вне привязки к UI (например, автоматическая рассылка системой почтовых уведомлений по расписанию), то вы просто переименуете подглаву в рамках такой фичи в нечто иное, т. к. UI там будет неприменим.
Итак, что описывать в главе «Описание интерфейса пользователя»?
Во-первых, выделите ключевые структурные элементы вашего UI (страницы, экраны, всплывающие окна и пр.) — это будет основа для дальнейшей структуризации требований в рамках каждой фичи. Во-вторых, определите их принадлежность к фичам. Например, вот, как это будет выглядеть для нашего примера:
Соответственно, все, что нам осталось, — это забить контентом конечные подглавы. Всего-то ничего, правда? 😊
Начните с краткого описания того, что у вас за UI-элемент и для чего он нужен. Тут вы также можете привести (или сослаться отсюда на) прототип (wireframe) элемента, чтобы ваши читатели могли визуально понять необходимый набор контролов (элементов управления) в рамках элемента и их схематичное расположение:
Начните с краткого описания того, что у вас за UI-элемент и для чего он нужен. Тут вы также можете привести (или сослаться отсюда на) прототип (wireframe) элемента, чтобы ваши читатели могли визуально понять необходимый набор контролов (элементов управления) в рамках элемента и их схематичное расположение:
Далее пойдет непосредственно мясо. Вам необходимо в табличном виде описать требования к блокам этого структурного элемента (если таковые есть) и отдельным контролам. Каждый тип контрола обладает своими спецификами, которые необходимо предусмотреть, а потому на первых порах я бы предложил зафиксировать себе в неком чеклисте или напрямую в шаблоне SRS, какие аспекты различных типов контролов стоит продумывать, уточнять и описывать. В будущем, по мере набивания собственных шишек, вы уже сможете сами варьировать детальность описания и что-то опускать, а что-то наоборот — акцентировать, плюс для нестандартных/редких контролов вы уже будете логически понимать, какие их аспекты стоит указать, чтобы команда имела на руках все необходимые требования для реализации. Далее я покажу пример описания тех контролов, которые присутствуют в нашем примере, плюс кратко поясню, что необходимо учитывать для часто встречающихся и не затронутых примером типов.
Вот конечный вариант заполненных таблиц, а ниже будет разбор:
Вот конечный вариант заполненных таблиц, а ниже будет разбор:
Из чего у нас будет состоять такая таблица:
1. Название элемента. Я предлагаю брать за название ровно то, что будет использоваться в качестве лейбла (надписи) возле или внутри элемента (если таковая есть). Это позволит не описывать лейблы отдельно, занимаясь рутиной.
Важно: если вы работаете с такой категорией требований, как требования к данным (вспоминаем о том, что это вторая часть функциональных требований, которая дополняет требования к поведению/функциям), а я рекомендую их прорабатывать в контексте требований с высокой детализацией, то название может являться ссылкой, ведущей на привязанный к данному контролу атрибут сущности данных из раздела «Требования к данным». Разбор этого механизма выходит за рамки статьи, но, если вкратце, для тех, кто не сталкивался активно с подобной практикой ранее:
Большинство контролов в системе предназначены для внесения либо отображения данных системы. То есть, когда мы смотрим на текстовое поле «Товар» во всплывающем окне добавления товара, мы говорим о том, что это поле необходимо для ввода Наименования товара в систему. В свою очередь, первая колонка таблицы со списком товаров на странице предназначена для отображения того же самого Наименования товара. То есть можно утверждать, если по-простому, что где-то в нашей системе у нас есть сущность данных Товар, у которой, помимо прочих, есть атрибут или параметр Наименование товара. И на каких-то страницах/окнах посредством чего-то мы будем его отображать пользователю, а где-то — позволять вносить (добавлять илиредактировать). Вот на требования, говорящие о том же, что я только что описал, только более красивым и структурированным языком, и ссылаются контролы, связанные с данными. В частности, если мы говорим про SRS по типовому шаблону, то кликая на Товаре, мы перейдем в подраздел «Словарь данных» в разделе «Требования к данным». Я оставлю пример того, как этот атрибут может быть описан в этом подразделе, но разбирать это мы не будем:
2. Тип элемента.Собственно, что именно за UI-контрол перед нами. Предполагается, что вы знакомы с азами проектирования UI и его прототипирования, поэтому детально мы возможные виды рассматривать не будем.
3. Описание — вкратце укажите, какой цели с позиции пользователя служит данный контрол на странице. Если это нечто очевидное, смело опускайте.
4. Видимость и доступность. В зависимости от тех или иных условий и состояний, а также роли/прав пользователя отдельные контролы или даже блоки могут быть в какой-то момент времени видны или нет (например, колонка таблицы может быть видна пользователю в одной роли и не видна пользователю в другой), а также доступны (enabled) или нет (disabled). Последнее актуально только для интерактивных контролов (например, вы можете сделать поле ввода какой-либо информации недоступным, «сереньким» для пользователя, если вы не хотите, чтобы именно в данный момент он его заполнял — допустим, пока он не укажет некую информацию в предыдущем данному поле). Собственно, специфики этого и опишите в данной колонке.
4. Формат, проверки, поведение и все прочее, что важно описать для элемента управления (можете разбить это на несколько колонок, если вам так удобнее). Тут и кроются-таки основные функциональные требования, привязанные к контролам. Что тут может быть:
1) Точные текстовые значения для лейблов (надписей, текста).
У нас в примере это заголовки системы, страницы и окна.
2) Для контролов, для которых актуально такое понятие, как валидация, т. е. проверка указываемых данных по потере фокуса контролом или иному событию, указывается такой параметр, как Проверка. Означает он, что к данному контролу должно быть привязано функциональное требование для проверки чего-то с ним связанного. Естественно, это в первую очередь актуально для контролов ввода и выбора информации: текстовые поля, области, выпадающие списки, чекбоксы, радиокнопки и пр. Например, для полей «Товар», «Категория» и «Цена», учитывая, что стоящие за ними атрибуты данных обязательны к заполнению, нужно проверить сам факт ввода информации. Для поля «Цена» также необходимо проверить корректность введенных данных в плане формата.
3) Поведение системы по различным событиям, связанным с контролом. Это могут быть как очевидные, связанные с контролами действия (нажатие на иконки и кнопки), так и не очень очевидные (например, вы хотите, чтобы система что-то сделала по факту выбора первого значения в выпадающем списке, по факту потери фокуса текстовым полем, по мере ввода каждого символа в поле, после выбора одного из значений в группе радиокнопок, и пр.).
В нашем примере это поведения всех кнопок и иконок, а также ограничения по количеству вводимых символов, которые должны быть реализованы поведением системы по мере ввода символов пользователем.
4) Специфики формата при отображении или внесении информации.
Обратите внимание на Цену товара в примере. Вносится цена пользователем в формате дробного числа с двумя знаками после разделителя. Например, 1000.00. Это тот формат значений, который будет свойственен атрибуту данных, стоящему за этим полем. Вывести же мы хотим это в таблице в слегка ином виде: а) добавив символ валюты к значению, б) отобразив «N/A», если значение отсутствует (атрибут данных не обязателен к заполнению). Соответственно, подобную специфику нам полезно будет указать в требованиях к этому контролу (колонке таблицы).
Что еще может часто встречаться для контролов, которые, как сами по себе, так и их специфики, не были затронуты примером:
Меню: набор и порядок значений, пункт для навигации по умолчанию
Ссылка: целевая локация, в новом ли окне/вкладке открывать
Радиокнопки, чекбоксы, выпадающие списки: набор и порядок значений, выбранное по умолчанию значение
Текстовые поля, области: маски, подсказки, значения по умолчанию
Иконки, кнопки: всплывающие подсказки
А вообще, повторюсь: ведите свой собственный чеклист по мере наработки опыта и адаптации к вашей текущей команде. Например, если разработчик обращается к вам с вопросом (или, что хуже, вы сталкиваетесь с багом, причина которого — непродуманность каких-либо аспектов), это может быть поводом учитывать это в требованиях в будущем.
5. Добавляете прочие требования, не покрытые описанным. Например, однозначно неясно, что и как показывать в таблице на странице. Давайте это исправим (пометка: ссылка в требовании о содержимом таблицы — это ссылка на сущность данных в Словаре данных).
1. Название элемента. Я предлагаю брать за название ровно то, что будет использоваться в качестве лейбла (надписи) возле или внутри элемента (если таковая есть). Это позволит не описывать лейблы отдельно, занимаясь рутиной.
Важно: если вы работаете с такой категорией требований, как требования к данным (вспоминаем о том, что это вторая часть функциональных требований, которая дополняет требования к поведению/функциям), а я рекомендую их прорабатывать в контексте требований с высокой детализацией, то название может являться ссылкой, ведущей на привязанный к данному контролу атрибут сущности данных из раздела «Требования к данным». Разбор этого механизма выходит за рамки статьи, но, если вкратце, для тех, кто не сталкивался активно с подобной практикой ранее:
Большинство контролов в системе предназначены для внесения либо отображения данных системы. То есть, когда мы смотрим на текстовое поле «Товар» во всплывающем окне добавления товара, мы говорим о том, что это поле необходимо для ввода Наименования товара в систему. В свою очередь, первая колонка таблицы со списком товаров на странице предназначена для отображения того же самого Наименования товара. То есть можно утверждать, если по-простому, что где-то в нашей системе у нас есть сущность данных Товар, у которой, помимо прочих, есть атрибут или параметр Наименование товара. И на каких-то страницах/окнах посредством чего-то мы будем его отображать пользователю, а где-то — позволять вносить (добавлять илиредактировать). Вот на требования, говорящие о том же, что я только что описал, только более красивым и структурированным языком, и ссылаются контролы, связанные с данными. В частности, если мы говорим про SRS по типовому шаблону, то кликая на Товаре, мы перейдем в подраздел «Словарь данных» в разделе «Требования к данным». Я оставлю пример того, как этот атрибут может быть описан в этом подразделе, но разбирать это мы не будем:
2. Тип элемента.Собственно, что именно за UI-контрол перед нами. Предполагается, что вы знакомы с азами проектирования UI и его прототипирования, поэтому детально мы возможные виды рассматривать не будем.
3. Описание — вкратце укажите, какой цели с позиции пользователя служит данный контрол на странице. Если это нечто очевидное, смело опускайте.
4. Видимость и доступность. В зависимости от тех или иных условий и состояний, а также роли/прав пользователя отдельные контролы или даже блоки могут быть в какой-то момент времени видны или нет (например, колонка таблицы может быть видна пользователю в одной роли и не видна пользователю в другой), а также доступны (enabled) или нет (disabled). Последнее актуально только для интерактивных контролов (например, вы можете сделать поле ввода какой-либо информации недоступным, «сереньким» для пользователя, если вы не хотите, чтобы именно в данный момент он его заполнял — допустим, пока он не укажет некую информацию в предыдущем данному поле). Собственно, специфики этого и опишите в данной колонке.
4. Формат, проверки, поведение и все прочее, что важно описать для элемента управления (можете разбить это на несколько колонок, если вам так удобнее). Тут и кроются-таки основные функциональные требования, привязанные к контролам. Что тут может быть:
1) Точные текстовые значения для лейблов (надписей, текста).
У нас в примере это заголовки системы, страницы и окна.
2) Для контролов, для которых актуально такое понятие, как валидация, т. е. проверка указываемых данных по потере фокуса контролом или иному событию, указывается такой параметр, как Проверка. Означает он, что к данному контролу должно быть привязано функциональное требование для проверки чего-то с ним связанного. Естественно, это в первую очередь актуально для контролов ввода и выбора информации: текстовые поля, области, выпадающие списки, чекбоксы, радиокнопки и пр. Например, для полей «Товар», «Категория» и «Цена», учитывая, что стоящие за ними атрибуты данных обязательны к заполнению, нужно проверить сам факт ввода информации. Для поля «Цена» также необходимо проверить корректность введенных данных в плане формата.
3) Поведение системы по различным событиям, связанным с контролом. Это могут быть как очевидные, связанные с контролами действия (нажатие на иконки и кнопки), так и не очень очевидные (например, вы хотите, чтобы система что-то сделала по факту выбора первого значения в выпадающем списке, по факту потери фокуса текстовым полем, по мере ввода каждого символа в поле, после выбора одного из значений в группе радиокнопок, и пр.).
В нашем примере это поведения всех кнопок и иконок, а также ограничения по количеству вводимых символов, которые должны быть реализованы поведением системы по мере ввода символов пользователем.
4) Специфики формата при отображении или внесении информации.
Обратите внимание на Цену товара в примере. Вносится цена пользователем в формате дробного числа с двумя знаками после разделителя. Например, 1000.00. Это тот формат значений, который будет свойственен атрибуту данных, стоящему за этим полем. Вывести же мы хотим это в таблице в слегка ином виде: а) добавив символ валюты к значению, б) отобразив «N/A», если значение отсутствует (атрибут данных не обязателен к заполнению). Соответственно, подобную специфику нам полезно будет указать в требованиях к этому контролу (колонке таблицы).
Что еще может часто встречаться для контролов, которые, как сами по себе, так и их специфики, не были затронуты примером:
Меню: набор и порядок значений, пункт для навигации по умолчанию
Ссылка: целевая локация, в новом ли окне/вкладке открывать
Радиокнопки, чекбоксы, выпадающие списки: набор и порядок значений, выбранное по умолчанию значение
Текстовые поля, области: маски, подсказки, значения по умолчанию
Иконки, кнопки: всплывающие подсказки
А вообще, повторюсь: ведите свой собственный чеклист по мере наработки опыта и адаптации к вашей текущей команде. Например, если разработчик обращается к вам с вопросом (или, что хуже, вы сталкиваетесь с багом, причина которого — непродуманность каких-либо аспектов), это может быть поводом учитывать это в требованиях в будущем.
5. Добавляете прочие требования, не покрытые описанным. Например, однозначно неясно, что и как показывать в таблице на странице. Давайте это исправим (пометка: ссылка в требовании о содержимом таблицы — это ссылка на сущность данных в Словаре данных).
И напоследок:
1) Контролы могут дублироваться, а мы знаем, что дублирование, в общем и целом, — зло (поддерживаемость набора требований, все дела). Выносите такое куда-нибудь и ссылайтесь, вместо повторения.
2) Аналогично и по любой прочей информации.
Вот приведенные примеры:
1) Контролы могут дублироваться, а мы знаем, что дублирование, в общем и целом, — зло (поддерживаемость набора требований, все дела). Выносите такое куда-нибудь и ссылайтесь, вместо повторения.
2) Аналогично и по любой прочей информации.
Вот приведенные примеры:
Ссылка в первом примере ведет на раздел «Общие требования к UI». Не так важно, где он располагается — главное, что требования к указанному контролу будут описаны только в одном месте.
Во втором примере вместо того, чтобы заниматься формализмом, подобное можно вынести как правило сортировки в аналогичное предыдущему пункту место и ссылаться туда — и читаться проще будет (не считая дополнительного обременения читателей действиями по переходу по ссылке и возврату назад), и поддерживать в разы проще с позиции управления требованиями.
Соответственно, итоговый набор требований — это то, что практически максимально покрывает функциональные требования, затронутые рассмотренными блоками UI. Как видите, пространство для креатива или неверной интерпретации тут немного. А такое зачастую может являться именно тем подходом, который необходим аналитику в контексте коммуникации требований команде разработки. Да, как мы уже упоминали, бывает и обратное — например, «взрослой» agile-команде подобное может нести как раз вред (вспомним еще раз про Negotiable для User Stories): с позиции совместной проработки требований командой (что зачастую является предпочитаемым подходом в подобных командах), с позиции попытки залезть не в свой огород (когда у вас есть в команде дизайнер, UX-специалист и иные подобные роли), с позиции ограничения креатива разработчиков (кому-то наоборот нужно оставить простор для «додумывания», ибо работать по настолько четкой инструкции — скучно и рутинно) и т. п. Но это уже в тему планирования бизнес-анализа и выбора подхода к документированию требований. Главное, что мы тут рассмотрели — это то, как создать детальную документацию функциональных поведенческих требований на базе UI, если вам такое нужно и полезно в вашей ситуации.
Во втором примере вместо того, чтобы заниматься формализмом, подобное можно вынести как правило сортировки в аналогичное предыдущему пункту место и ссылаться туда — и читаться проще будет (не считая дополнительного обременения читателей действиями по переходу по ссылке и возврату назад), и поддерживать в разы проще с позиции управления требованиями.
Соответственно, итоговый набор требований — это то, что практически максимально покрывает функциональные требования, затронутые рассмотренными блоками UI. Как видите, пространство для креатива или неверной интерпретации тут немного. А такое зачастую может являться именно тем подходом, который необходим аналитику в контексте коммуникации требований команде разработки. Да, как мы уже упоминали, бывает и обратное — например, «взрослой» agile-команде подобное может нести как раз вред (вспомним еще раз про Negotiable для User Stories): с позиции совместной проработки требований командой (что зачастую является предпочитаемым подходом в подобных командах), с позиции попытки залезть не в свой огород (когда у вас есть в команде дизайнер, UX-специалист и иные подобные роли), с позиции ограничения креатива разработчиков (кому-то наоборот нужно оставить простор для «додумывания», ибо работать по настолько четкой инструкции — скучно и рутинно) и т. п. Но это уже в тему планирования бизнес-анализа и выбора подхода к документированию требований. Главное, что мы тут рассмотрели — это то, как создать детальную документацию функциональных поведенческих требований на базе UI, если вам такое нужно и полезно в вашей ситуации.
