Основы проектирования корпоративных систем - Сергей Зыков

Наименование продукта должно описываться текстовым полем ограниченной длины (например, 50 символов). Описание должно быть текстовым полем большей длины, по которому пользователь может понять, подходит ему товар или нет. Также должно быть изображение – обычное, цветное, статическое, объема порядка сотен килобайт. Возможно, одной фотографии будет недостаточно (это тоже можно обсудить с заказчиком). Поскольку в требованиях также говорится о доставке заказа, нужно определить такое понятие, как вес, потому что он выступает определяющим условием для типа и стоимости доставки. И, конечно, у продукта должна присутствовать цена. Это атрибут не конкретного экземпляра, а всего типа продуктов. Еще нужен некий внутренний код (артикул) для идентификации продукта (это тоже наводит на мысль об использовании СУБД).

Еще одним важным требованием будет работа с корзиной. У корзины тоже должны присутствовать атрибуты. Это количество товаров в корзине (общее и каждого вида), способ доставки, возможно, еще некоторые связанные атрибуты – способ оплаты и т. д. Также важны функции – способы, которыми пользователь будет оперировать с объектами в корзине. Здесь существует ряд функций, связанных с добавлением и удалением товаров (по одному, группой). Имеет смысл предусмотреть полную очистку корзины и удаление товаров по одному. И, наконец, оформление заказа. История заказов – вероятнее всего, таблица базы данных с полями: реквизиты заказчика (ФИО, логин), адрес доставки, дата заказа, номер заказа (первое, что спрашивает оператор в интернет-магазине).

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

Также необходимо определить технологии, которые будут присутствовать в списке требований. При этом мы должны детализировать несколько глобальных параметров. Это прежде всего вид интерфейса. Скорее всего он будет графическим. Интерфейс содержит окна, выпадающие списки, меню, командные кнопки (вход в систему, оформление заказа, дополнительные возможности). Таким образом, интерфейс должен делиться на графическую и логическую части. То есть это определенные классы элементов управления (будут ли это предопределенные классы. NET или разработанные вручную) и логическая часть (сценарии работы пользователя). При этом понятно, что работа осуществляется реализацией некоторых сценариев (например, вход – заказ – выход) и ряд сценариев вариативен.

В общей архитектуре системы имеется клиентская часть, которая уже была описана, и логика, а также есть некая часть, связанная с СУБД, где хранится каталог товаров и история заказов, плюс есть механизм, определяющий серверную часть реализации. Он работает с базой данных, извлекая из нее необходимую информацию, он передает эту информацию в интерфейс пользователя и содержит логику работы. Таким образом, это трехзвенная архитектура вида клиент – сервер. Далее нужно детализировать такие параметры, как тип СУБД (Oracle, Microsoft SQL Server и т. д. исходя из сроков реализации, объемов данных, используемой модели, интенсивности транзакций), язык и среда реализации (платформы Java или. NET, язык Java или C# исходя из опыта разработчиков и пожеланий заказчика; Java-решение может быть менее затратным), CASE-средства для создания, развития и поддержки продукта.

Следующее, на что следует обратить внимание, – ограничения, накладываемые на программный продукт. Именно они во многом будут определять трудозатраты при производстве конечного продукта, скажутся на качестве проекта и его функциональности. Есть ряд параметров, которые следует учесть прежде всего: это в первую очередь время непрерывной работы – время, которое сервер должен работать до отказа; время восстановления работы, которое должно быть отражено в документации (нужно понимать, какие действия входят в восстановление работоспособности после сбоя); количество и типы пользователей – существуют менеджеры магазина, заполняющие каталог, пользователи, отвечающие за финансовую часть, рядовые покупатели (если система будет расширяться, могут появиться администратор сети, администратор безопасности и т. д.); возможно, будут разные типы пользователей: обычные, привилегированные (имеющие дополнительные возможности). Нужно также оговорить количество одновременных пользователей, ограничив его сверху, и исходя из этого строить программные решения: механизмы взаимодействия с СУБД, откаты транзакций и т. д.

Порядок объема базы данных – сотни мегабайт. Если предусмотреть дополнительные или более высококачественные фотографии размером порядка мегабайта и если товаров порядка сотни, то размер БД будет порядка гигабайта. Сейчас это предварительные соображения, но в документ с требованиями необходимо внести данные о том, какого рода ограничение должно быть на объем данных сверху. Для определения интенсивности транзакций нужно сделать предположение, насколько сложные запросы к базе данных возможны, какова интенсивность транзакций, каков их механизм, какова пропускная способность интернет-канала, который будет узким местом в системе. Поэтому имеет смысл предусмотреть различные механизмы представления информации. Ряд пользователей будет заинтересован в более качественных фотоизображениях, поэтому необходимо оговорить тот порог, который предусматривается для пропускной способности, просто чтобы обезопасить себя от изменения факторов, за которые мы не можем отвечать. Если пропускная способность сети падает ниже возможностей модема, можно говорить о том, что система не сможет работать стабильно. Можно обсуждать с заказчиками скорость порядка десятков мегабит. В любом случае нужно четко описать и это количественное ограничение.

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

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

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