Секретные техники проработки требований. Часть 3

В предыдущих статьях (1, 2) мы с вами рассмотрели большую часть техник, которые я использую на практике, чтобы проверить требования на полноту. В данной статье я хотел бы рассмотреть оставшиеся три техники:

• Администрирование.
• Отчетность.
• Нефункциональные требования.

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

Администрирование

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

Прошло полгода, и когда «сдавали» систему, представители заказчика спросили: «А как нам управлять справочными данными?» Дело в том, что один из основных справочников системы имел более 10 000 записей (вот вам и подводный камешек). А обновление данных должно было происходить не реже чем один раз в час. Также необходимо было реализовать синхронизацию данных пользователей системы из active directory.

От представителей информационной безопасности прозвучал очень интересный вопрос об управлении учетными записями в системе, а также журналировании действий пользователей (а вот это — целый булыжник, о который споткнулась наша лодка...).

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

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

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

Управление справочниками системы

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

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

Пример описания атрибутов я приводил во второй части статьи в разделе «Объектно-ориентированная модель», данный подход использую и для описания атрибутов для обмена.

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

Управление учетными записями, ролями и полномочиями

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

При проработке администрирования пользователей следует задаваться вопросами:

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

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

Архивирование и восстановление объектов

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

При проработке требований к архивированию объектов или данных системы необходимо описать, при каких условиях объект можно переносить в архив и как это будет выполняться. Какие операции с заархивированным объектом можно выполнять, есть ли необходимость возвращать объекты из архива и каким образом будет выполняться поиск заархивированных объектов? При проработке требований к архивированию не забывайте о пользователях и их комфорте.

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

При проработке требований к хранению удаленных объектов следует учитывать:

• Как и кто может восстанавливать данные?
• Какой срок хранения удаленных документов?
• Есть ли ограничения по объему удаляемого документа?

Журналирование действий пользователей

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

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

Рассмотрим пример. Для сотрудников с функциональной ролью «Аудитор» необходимо понимать, что выполнялось с объектом. Для этого часто реализовывают отдельный интерфейс или вкладку — «История», где отображается информация о том, кто, когда и какое действие выполнял с объектом.

Сотрудникам с функциональной ролью «Информационная безопасность» необходима более детальная информация, и анализируют они информацию несколько в ином разрезе: что именно пользователь выполнял в системе.

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

Отчетность

На одной из встреч с заказчиком я задал вопрос: «Какая отчетность должна быть реализована?» Заказчик ответил, что отчетность не нужна. Я переспросил несколько раз, обратив его внимание на разные аспекты, заказчик стоял на своем. Требования к отчетности не были зафиксированы и не вошли в скоуп работ по проекту.

Через два месяца после выхода в промышленную среду заказчик захотел пул отчетов. Что в этом плохого, спросите вы? Изменение в проектах и тем более после закрытия — это даже хорошо. Отвечу: чтобы удовлетворить требования заказчика, нам пришлось изменять структуру базы данных, а это, в свою очередь, существенно увеличило трудозатраты и бюджет на доработку. Для реализации отдельных требований были необходимы существенные доработки, и заказчик был вынужден отказываться от них. Если бы на старте проекта требования к отчетности были проработаны, можно было бы сэкономить бюджет на другие доработки.

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

Итак, что я рекомендую учитывать при проработке требований к отчетности:

Варианты использования — или, другими словами, как отчетом будут пользоваться

• Отчет будут печатать — необходимо учитывать, что после печати отчет должен быть читабельный.
• Для дальнейшего анализа — необходимо описать требования к визуализации (о визуализации — немного ниже), агрегации, фильтрации, сортировке, группировке. Действия по перечисленным операциям должны быть изначально реализованы — или пользователь должен иметь возможность выполнять эти операции самостоятельно после получения данных?
• Гибридный — проводится первоначальная обработка полученных результатов и выводится на печать.

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

• Необходимо ли обрабатывать данные после отображения результата запроса?
• Есть ли необходимость хранить данные после получения (архив отчетов за период)? Если да, ВНИМАНИЕ: нужно более детально проработать требования к отчетности. Возможно, понадобится организовывать хранилище данных, а это совсем нетривиальная задача.

Источники данных

Для себя я выделяю три источника данных:

• Внутренняя — база данных системы.
• Внешняя — базы данных других систем.
  
• Гибридная — часть данных тянется из внутренней базы данных, а часть — из внешних.

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

• доступность данных на момент формирования отчета;
• производительность построения отчета.

Поэтому тут нужно быть предельно внимательным и сразу предупреждать заказчика о возможных проблемах.

Визуализация

Если вариант использования — «Для печати», рекомендую проработать так называемый визуальный макет, в котором есть:

• верхний колонтитул;
• заголовок (название отчета);
• тело отчета — основная часть;
• нижний колонтитул.

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

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

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

Самостоятельно реализовать сервис для визуализации данных будет трудозатратно. Уточните, какой ориентировочный срок и бюджет для реализации визуализации данных. Помните, что на рынке есть много хороших решений: PowerBI, Google Data Studio, Tableau и другие. Проанализируйте их.

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

Диаграмма — представление данных при помощи графических компонентов (линии, точки), связанных со справочниками, имеет одну или несколько числовых шкал.

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

Карта — представление показателей, связанных с географическими данными (страна, регион, город и т.д.)

А возможно, будет достаточно реализовать отображение графиков в Excel.

Источник

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

• возможность настраивать представление данных;
• навигацию между разделами отчета.

Дополнительные возможности

Отчеты могут иметь ряд дополнительных возможностей:

• Публикация отчетов: для некоторых отчетов необходимо иметь возможность публиковать результаты на веб-ресурсах в виде тех же диаграмм, карт и т.д. В данном случае следует учитывать периодичность обновления данных. На практике бывали случаи, когда требования к публикации на веб-ресурсах не прорабатывались, и на первых этапах развития системы просто публиковали изображение, которое предварительно подготавливалось сотрудником, поэтому не забудьте проработать требования не только к публикации, но и к визуализации данных.
• Формирование и отправка отчетов по расписанию: при проработке требований к формированию и отправке отчетов по расписанию следует учитывать время формирования (как правило, отчеты формируются в нерабочее время, но и в правилах бывают исключения) и способ отправки (электронная почта или сохранение на сетевой ресурс). Следует продумать, с какого электронного адреса будет отправляться отчет, и список получателей. При проработке получателей рекомендую отправлять на группу контактов, группами легче в будущем управлять и сопровождать.
• Экспорт данных: требования к возможностям экспортировать данные в Excel, Word, PDF или другие форматы.

Нефункциональные требования

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

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

1. Runtime — это требования, которые описывают время работы системы.
2. Design time — это требования, определяющие аспекты проектирования системы.

К группе Runtime относят:

1. Доступность.
2. Надежность.
3. Время хранения данных.
4. Масштабируемость.
5. Удобство использования.
6. Безопасность.
7. Производительность.
8. Ограничения.

1. Доступность — требования ко времени непрерывной работы системы

Пример требований к доступности: система должна поддерживать режим 24*7 — круглосуточный режим работы.

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

Мне больше нравится, как это изложено в требованиях по доступности, ранжированных по девяткам:

Сразу скажу, все заказчики хотят доступность в шесть девяток, но когда начинаем прорабатывать аппаратную архитектуру, соглашаются на 95-99 :-D

2. Надежность

Требования к надежности описывают поведение системы в нештатных ситуациях. Требования к надежности должны предусматривать:

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

Ниже приведу несколько примеров:

1. Отказ аппаратной составляющей архитектуры
   
   • Система должна сохранять работоспособность при отказе или выходе из строя веб-серверов.
   • Необходимо обеспечить сохранение всей накопленной информации на момент отказа или выхода из строя одного из дисковых накопителей.
   • В случае полного отключения электроэнергии система должна обработать и после возобновления электроэнергии запустить повторно на выполнение все незавершенные операции.
2. Сбои в программной логике
   
   • Система должна обеспечивать работоспособность в случае сбоя одного из своих модулей.
3. Перебои работы каналов связи или локальной сети:
   
   • Система должна обеспечивать гарантированную доставку информации при обмене данными между предприятиями холдинга.
   • Необходимо реализовать квитанцию о доставке информационного пакета. В случае если квитанция не получена в течение 5 минут, необходимо повторно отправить информационный пакет.

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

3. Требования к времени хранения данных

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

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

При проработке архивирования данных не забывайте о возможных связях объектов вашей системы.

4. Масштабируемость

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

Как правило, выделяют два направления масштабирования:

1. Вертикальное масштабирование — это увеличение производительности компонентов системы с целью повышения общей производительности. К примеру, увеличение дискового пространства или CPU.
2. Горизонтальное масштабирование — разбиение системы на более мелкие структурные компоненты и разнесение их по отдельным физическим машинам (или их группам) и (или) увеличение количества серверов, параллельно выполняющих одну и ту же функцию.

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

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

5. Требования к удобству использования

Пример из реального документа с требованиями:

Система должна иметь удобный, интуитивно понятный и дружественный интерфейс.

Когда я вижу подобное в требованиях, сразу задаю вопрос: какие критерии проверки удобства и дружественности интерфейса?

Недостаточно написать — удобный, интуитивно понятный и дружественный. Следует раскрыть эти сущности.

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

1. Шрифты: осмысленные размеры шрифтов и их поведение при адаптивном дизайне.
2. Адаптивность: проработайте размещение и поведение элементов системы при адаптивности. Максимальное и минимальное разрешение. Разрешение, при котором изменяется размещение элементов.
3. Ошибки: информативная обработка сообщений об ошибках. Недостаточно показать код ошибки — следует сообщить, что пользователю делать с этой ошибкой. А также потрудитесь отдельно проработать требования к страницам с информацией об ошибке.

4. Навигация: отдельно раскрывал эту тему во второй части статьи.
5. Поиск: для удобства пользователя поиск размещают практически на всех интерфейсах пользователя (я не говорю сейчас о диалоговых или информационных интерфейсах). Поиск информации может быть глобальным — в рамках всей системы, или локальным — в рамках определенного модуля, а также контекстным.
6. Кроссбраузерность: если у вас система работает через браузеры, опишите браузеры и их версии, на которых должна функционировать система. Тут важный аспект: чем больше браузеров, тем больше работы у разработчиков и верстальщиков, а также увеличивается время на тестирование.
7. Обработка отдельных элементов: к примеру, ссылки, которые посещал пользователь, должны отображаться не синим, а фиолетовым. Также необходимо указать коды цветовой гаммы: цвет активной ссылки — #0000FF, цвет посещенной ссылки — #800080

6. Требования к безопасности

Требования к безопасности бывают трех категорий:

• связанные с разграничением доступа;
• связанные с работой с приватными данными;
• направленные на снижение рисков от внешних атак.

Для понимания ниже приведу несколько примеров каждой категории.

Примеры требований с разграничением доступа:

• Необходимо обеспечить возможность создавать как групповые, так и индивидуальные роли.
• В системе должна быть реализована сквозная аутентификация active directory.
• Ролевая модель должна управляться на уровне active directory путем добавления пользователей в группы active directory.

Примеры требований, связанных с работой с приватными данными:

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

Примеры требований, направленных на снижение рисков от внешних атак:

• Обмен документами между компаниями холдинга должен выполняться только через сервисную шину предприятия.
• Веб-приложение должно использовать протокол https.

7. Требования к производительности

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

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

Одним из важных факторов может оказаться количество выполняемых транзакций. Также этот фактор может повлиять аппаратную архитектуру. На одном из проектов не учли, что система должна была выполнять более 40 000 транзакций в минуту, и система просто не выдерживала. Нам пришлось остановить работу пользователей в системе более чем на два месяца и проводить изменения ядра и оптимизацию пользовательских функций. Благо, что на время остановки клиент мог работать в старой системе, и нам, помимо разработки, пришлось еще выполнять работы по повторному экспорту данных.

В документах часто можно встретить требования в стиле: «Страница должна загружаться не более чем за 5 секунд». При этом аналитики не задумываются о таких моментах, как быстродействие пользовательских ПК или других девайсов, потерь в сети и других проблем, не связанных с быстродействием самой системы. Что делать, если заказчик таки требует указать требования к быстродействию? Варианта два: или указывайте параметры, при каких вы обеспечите быстродействие в 5 секунд, или проводите тестирование с серверов, где развернута система — это значительно уменьшит риски, что на быстродействие повлияют внешние факторы.

Одним из интереснейших проектов из моей практики был проект по внедрению CRM-системы на 150 000 пользователей. Не учли такой момент, как слишком большой трек отдаленных рабочих мест с реально древним оборудованием и быстродействием каналов связи. В некоторых клиентских точках из-за быстродействия каналов связи система просто падала по таймауту.

8. Ограничения

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

На одном из проектов мы с удивлением узнали, что у клиента есть ПК, на которых установлена ОС Windows XP c браузером IE 8, и это очень ограничивало нас в разработке, а именно — в выборе технологии реализации.

К группе Design time относят:

• Требования к расширяемости.
• Требования к переносимости.
• Требования к взаимодействию.
• Требования к поддержке.
• Требования к возможности тестирования.
• Требования к локализации.

Требования к расширяемости

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

На самом деле я очень редко в документах встречал требования к расширяемости. Однако не стоит забывать, что такие требования могут быть. К требованиям к расширяемости можно отнести идеологию OpenSource или предоставление API. Вот несколько примеров:

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

Требования к переносимости

В требованиях к переносимости описывают требования работы системы на разных платформах.

Переносимость системы включает:

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

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

Требования к взаимодействию

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

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

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

Для более сложных интеграций используют протоколы обмена данными между системами или, как пример, реализовывают API (application programming interface).

Зачастую для разработки API разработчикам достаточно описания данных в следующем виде:

Для интеграции систем аналитики описывают мапинг полей:

При мапинге полей следует обращать внимание на совпадение типа полей и их длину (в таблице указал в скобках максимальное количество символов).

Требования к поддержке

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

Примеры функций:

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

Требования к возможности тестирования

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

Пример шаблона тест-кейсов:

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

Требования к локализации

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

На одном из проектов не были описаны требования к локализации. Заказчик у нас был из чудесного города Тбилиси. К моему большому удивлению, мы обнаружили, что аналитики недостаточно внимания уделили требованиям к локализации, и когда разработчики реализовали модуль локализации, они попросили все термины, которые необходимо перевести на грузинский язык... И вот тут началась паника: что делать, как переводить и как тестировать... После переговоров с заказчиком удалось его уговорить, что перевод он предоставит и тестирование на грузинской локализации он также проведет. И вопрос, что нам пришлось бы делать, если бы не удалось уговорить заказчика, к счастью, остался только в моих мыслях...

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

Уверен, что моя статья, как минимум, натолкнет вас на размышления.

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

Гармонии вам и процветания! До новых встреч на страницах DOU!