Как подготовить ТЗ на разработку программного обеспечения. Часть 2.

Раздел Требования к системе в целом

В этом разделе нужно зафиксировать все нефункциональные требования. Давайте поделим раздел на следующие пункты:

1. Требования к защите от влияния внешних воздействий
2. Требования к патентной чистоте
3. Требования к стандартизации и унификации
4. Дополнительные требования
5. Требования к функциям и задачам системы
6. Требования к видам обеспечения

Требования к структуре и функционированию системы

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

Показатели назначения

Ранее мы уже разобрали, что такое назначение. Давайте разберём это простыми словами на примере.

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

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

Цель добавили просто для того, чтобы вы точно не перепутали эти определения. На неё можно не обращать внимание.

Чтобы достичь нашего назначения нам нужно:

1. Создать систему регистрации / авторизации, верификации, заполнения профиля
2. Создать систему поиска пары
3. Разработать и внедрить игры в приложение.
4. Разработать систему подбора игроков.
5. Добавить функционал общения во время игры.
6. Создать систему матчей (совпадение лайков профилей) в игре и вне игры.
7. Создать чат

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

Выполнив 1 пункт, мы можем создать анкету. Чтобы найти другого человека, а в дальнейшем играть и общаться с ним, нужно выполнить 2 пункт.
Последующая логика такая же. Каждый выполненный пункт — показатель того, насколько система соответствует назначению. Если система соответствует назначению — значит всё работает как надо.

Показатели надёжности

В этом разделе можно встретить следующие формулировки:

• приложение должно выдерживать одновременно более N тысяч пользователей, при этом не тормозить,
• приложение должно хранить данные пользователя в БД на отдельном сервере,
• если система по разным причинам перестала работать (что-то с хост-машиной, либо сбой в системе), то она должна перезапуститься автоматически в течение 10 минут
• система не должна быть нагружена более чем на 80 процентов, при превышении лимита нужно закрывать доступ новым пользователям, чтобы снизить нагрузку;

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

Системные требования

Показатели надёжности и системные требования могут вас запутать. Давайте раз и навсегда разделим эти определения!

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

Системные требования охватывают вопросы:

• какие характеристики серверов или ПК должны быть,
• как они должны работать,
• как предотвращать перегрузки,
• как обслуживать эти сервера,
• какая ОС должна быть на сервере и т.д;

Требования к эргономике и технической эстетике

Замудренная формулировка, не правда ли? На самом деле здесь всё просто.

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

На примере страницы регистрации, описание UX выглядит примерно так...
Для начала напишем какие элементы находятся на этой странице.

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

1. Поле ввода логина
2. Поле ввода емейла
3. Поле для ввода пароля
4. Чекбокс подтверждения обработки персональных данных.
5. Кнопка Зарегистрироваться
6. Кнопка Вернуться на главную

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

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

Требования к транспортабельности для подвижных АС

В разделе указываете способы транспортировки оборудования.

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

Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

Этот раздел относится к серверам. Часто здесь дают ответы на следующие вопросы:

• кто будет обслуживать сервера,
• как часто их нужно обслуживать,
• каким образом это делать,
• как всё настроить и всё в таком духе;

Этот раздел будет важен для вас, если вы планируете размещать программное обеспечение на ваших серверах или ПК (допустим это десктоп приложение).

Требования к защите информации от несанкционированного доступа

Судя по нашему опыту работы с банками, (а работаем мы преимущественно с фин. организациями) именно они уделяют особое внимание этому разделу. Они наиболее детально описывают:

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

Такие требования обусловлены внутренними регламентами и требованиями к безопасности.

Требования по сохранности информации при авариях

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

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

Требования к защите от влияния внешних воздействий

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

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

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

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

Этот раздел носит юридический характер. Давайте кратко и для общего познания обговорим, что это такое.

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

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

**Пример. **У вас появилась идея сделать веб приложение, связанное с криптовалютой. По сути, это веб платформа, на которой владельцы биткоинов могут сдавать их в аренду, а банки арендовать. В дальнейшем банки могут обращаться с криптовалютой, как с активом. Ваше веб приложение разработали в РФ, и здесь вы можете оформить патентную чистоту.
В результате продукт выстрелил... Отличный старт! Пора расти. Больше всего популярна криптовалюта за рубежом, поэтому будем продвигать своё приложение на иностранном рынке. Здесь то мы и встречаемся с проблемой.

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

Именно юристы составляют требования для оформления патентной чистоты приложения. Если у вас Наполеоновские планы, не забудьте “потыкать” юриста, чтобы он добавил всю необходимую информацию в этот раздел.

Требования к стандартизации и унификации

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

Приведу пару возможных формулировок:

• нужно реализовать систему безопасности в приложении по ГОСТу,
• разработка должна проводиться по методологии waterfall,
• корпоративная система должна быть построена по методологии ERP 2;

Дополнительные требования

В разделе фиксируется всё, что не касается предыдущих и следующих разделов.

Часто сюда прописывают следующие пункты:

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

Требования к функциям и задачам системы

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

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

Сюда же можете записать временные регламенты — когда должна отрабатывать какая-нибудь функция.

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

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

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

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

Совместный для заполнения исполнителем и заказчиком раздел. В нём фигурируют пункты:

• математическое обеспечение,
• информационное обеспечение,
• лингвистическое обеспечение,
• программное обеспечение системы,
• техническое обеспечение,
• требования к метрологическому обеспечению,
• организационное обеспечение,
• методическое обеспечение,
• требования к численности и квалификации персонал;

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

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

Перечислю всё, что должен написать исполнитель:

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

Лингвистическое обеспечение — это перечень всех технологий, которые будут использоваться: языки программирования (C#, TypeScript), базы данных (mongoDB, SQL Lite), библиотеки (React, Angular)

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

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

Вот ещё один пример. Вам нужно шифровать данные, тогда укажите ПО, с помощью которого нужно это делать (например, Валидата).

Техническое обеспечение — это требования к серверу или ПК, на котором будет работать ПО

Например, технические характеристики серверов, если это веб-приложение, или технические характеристики компьютера, на котором будет работать десктопное приложение.

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

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

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

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

Для каждой группы пользователей нужно разбить роли и права доступа. Условно, если даже у уборщика и менеджера роль называется “администратор”, то админские права могут отличаться. Уборщик не может забронировать номер для клиента, а менеджер не может отметить, что в номере завершили уборку.

Методическое обеспечение — сюда входит техническая и пользовательская документация. По необходимости может быть создан документ “пользовательские сценарии”.

Техническая документация — это инструкция для разработчиков. В ней содержатся любые технические детали: описание API, комментирование кода, описание архитектуры.
Пользовательская документация (руководство пользователя) — это документ, в котором описано как пользователю начать работать с системой, и какие возможности приложения он может использовать.
Пользовательские сценарии — это описание действий пользователя. Т.е. описывается порядок действий пользователя.

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

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

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

• навык владения компьютером (допустим, десктоп приложение на Linux, а пользователь никогда не работал в этой ОС)
• умение работать с Excel (допустим, рекламная система умеет импортировать .csv формат для управления ставками в поисковой рекламной кампании. Для корректного импорта, нужно создать определенные поля с ключевыми словами, где для ключевого слова прописать специальную формулу с помощью которой система поймёт, какую ставку выставить. Пользователь может не знать, как оформлять документ так, чтобы система его поняла.),
• умение администрировать операционную систему (допустим, разработано сложное ПО, для перезапуска которого нужно использовать командную строку);

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

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