Формирование требований к новой ИС
На основе результатов предпроектного обследования должна быть разработана концепция проекта новой или модернизация старой информационной системы. Эта концепция должна содержать предложения и первичные формулировки целей дальнейшего проектирования, общие требования к новой информационной системе. Она должна содержать, кроме того, модель бизнес-процесса предметной области с новой информационной системой и прототип новой ИС.
При этом надо отметить, что на практике уровень требований к системе зависит не только от квалификации системных аналитиков и разработчиков системы, но и от уровня готовности самого предприятия, от уровня его информатизации.
Приступим к формированию требований к новой ИС. Понятие требование, как и многие другие понятия индустрии программного обеспечения в настоящее время имеет несколько описаний. IEEE Standard glossary of Software Engineering Terminology (1990) определяет требования как:
1. условия или возможности, необходимые пользователю для решения проблем или достижения целей;
2. условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;
3. документированное представление условий или возможностей для пунктов 1 и 2.
Это определение охватывает как пользователей (внешнее поведение системы), так и разработчиков (некоторые скрытые параметры). Термин пользователи в данном определении подразумевает всех лиц, заинтересованных в проекте.
Напомним, что существуют функциональные и нефункциональные требования. Функциональные требования определяют поведение системы и процесс обработки информации. Нефункциональные требования определяют атрибуты системы или атрибуты системного окружения, то есть описывают требования к базам данных, информационной инфраструктуре, защите информации. К нефункциональным требованиям относят также требования к ресурсам: финансовым, человеческим, материальным. Их иногда называют ограничениями.
Карл И. Вигерс, дважды лауреат Software Development Productivity Award предлагает следующую модель требований, разбивая функциональные требования по трем уровням: бизнес-требования, требования пользователей и функциональные требования (рис. 30).
Рис. 30 Требования к системе
Бизнес-требования содержат высокоуровневые цели организации или заказчиков системы. Их формирует тот, кто финансирует проект или покупает систему или менеджер реальных пользователей. Эти требования записываются в уставе проекта, который иногда называют документом об образе и границах проекта или документом рыночных требований.
Требования пользователейописывают цели и задачи, которые пользователям позволит решить система. Они могут быть описаны с помощью вариантов использования (методология RUP), сценариев (методология SADT) или таблиц «событие – отклик».
Функциональные требования определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи могли выполнить свои задачи в рамках бизнес-требований. Они могут быть описаны как требования поведения, например: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Системные требования обозначают высокоуровневые требования к продукту. Говоря о системе, подразумеваются как программное обеспечение, ток и подсистемы ПО, оборудование и люди.
Бизнес-правила включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Они не являются требованиями к ПО, поскольку находятся вне системы, но они накладывают ограничения.
Все функциональные требования документируются в спецификации требований к ПО, где описывается поведение системы. Этот документ может быть представлен в любом виде, в том числе и в виде базы данных, электронной таблице, набора карточек (для небольшой системы). Спецификации требований используются не только при разработке ИС, но и тестировании, проверке на качество, управлении проектом.
В дополнение к функциональным требованиям спецификация содержит нефункциональные, где описаны цели и атрибуты качества. Атрибуты качества представляют собой дополнительное описание функций продукта, выраженное через описание таких характеристик как легкость и простота использования, легкость перемещения, целостность, эффективность и устойчивость к сбоям. Другие нефункциональные требования описывают внешние взаимодействия между системой и внешним миром, а также ограничения дизайна и реализации.
Разработка требований может быть подразделена на следующие этапы: извлечение, анализ, документирование и утверждение. В эти этапы входят следующие действия:
- идентификация классов пользователей для данного продукта;
- выяснение потребностей тех, кто представляет каждый класс пользователей;
- определение задач и целей пользователей, а также бизнес-целей, с которыми эти задачи связаны;
- анализ информации, полученной от пользователей, чтобы отделить задачи от функциональных и нефункциональных требований, бизнес-правил, предполагаемых решений и поступающих извне данных;
- распределение высокоуровневых требований по компонентам ПО, определенным в системной архитектуре;
- установление относительной важности атрибутов качества;
- установление приоритетов реализации;
- документирование собранной информации и построение моделей;
- просмотр спецификации требований, который позволяет удостовериться в том, что запросы пользователей всеми понимаются одинаково, и устранение возникших проблем до передачи документа разработчикам.
Рассмотрим процедуру формирования требований к системе на нашем примере.
Вначале определим бизнес-требования системы, которые вырабатываются с учетом бизнес - целей предметной области.
На этапе предпроектного обследования при построении модели бизнес-процесса мы ставили цель: увеличение продаж, поскольку это позволит увеличить прибыль предприятия. На этом этапе проектирования должна быть уточнена бизнес-цель подразделения и выбрана модель управления. Эта процедура может быть выполнена только топ - менеджментом предприятия с учетом бизнес - цели предприятия. Это бизнес-требование в дальнейшем окажет влияние на выбор модели новой ИС. То есть бизнес-требование и будущая модель системы управления предприятием и, как следствие, новая ИС связаны между собой. На различных уровнях управления предприятием выбираются различные модели управления. Эти модели должны быть гармонизированы. На любом предприятии могут быть использованы, например, следующие модели управления:
- ERP - Enterprise Resource Planning - управление ресурсами предприятия;
- MRP - Manufacturing Resource Planning - планирование ресурсами предприятия;
- CRM - Custоmer Relationship Management - управление отношениями с заказчиками;
- HRM - Human Resource Management - управление персоналом;
- PLM - Product Lifecycle Management - управление жизненным циклом продукции;
- PRM - Partnership Relation Management - управление отношениями с партнерами;
- SCM - Supply Chain Management - управление логистическими цепочками (модель взаимодействия с поставщиками).
Наша предметная область связана с заказчиками и другими подразделениями предприятия (производственный отдел, склад, касса, отдел договоров). Эффективность всего предприятия будет зависеть от прибыли, которая, в свою очередь, зависит от успешных продаж крепежных изделий заказчику, отгрузки крепежных изделий по договорам точно в срок, уменьшения срока хранения готовых изделий на складе. Поэтому из всех моделей управления на этом уровне управления логичнее всего предложить заказчику модель CRM - модель управления отношений с заказчиками. Этот выбор должен быть согласован с заказчиком и утвержден соответствующим протоколом.
С учетом выбранной модели управления, анализа узких мест и уточнений бизнес - целей предметной области, можно сформулировать начальные бизнес - требования к системе. Итак, с точки зрения топ-менеджеров, нам необходимо следующее:
- совершенствование каналов продаж;
- снижение рисков при продажах;
- выявление новых источников прибыли;
- интеграция в общую среду информационной системы предприятия, в том числе финансовую и производственную, для создания более целостного представления о потребителях, чем традиционные фрагментированные представления на уровне отдельных подразделений;
- организация приема и обработки данных, поступающих по различным каналам связи, включая Web.
Приступим к документированию бизнес - требований. Для создания документа можно использовать следующий шаблон:
1. Бизнес – требования
1.1. Исходные данные, возможности бизнеса и нужды клиента
1.2. Бизнес - цели и критерии успеха
1.3. Потребности клиента или рынка
1.4. Бизнес - риски
2. Образ решения
2.1. Положение об образе проекта
2.2. Основные функции
2.3. Предположения и зависимости
3. Масштабы и ограничения проекта
3.1. Объем первоначально запланированной версии
3.2. Объем последующих версий
3.3. Ограничения и исключения
4. Бизнес-контекст
4.1. Профили заинтересованных лиц
4.2. Приоритеты проекта
4.3. Операционная среда
Приступим к описанию бизнес – требований нашей задачи:
Бизнес – требования
Исходные данные, возможности бизнеса и нужды клиента: Заказчик «Метиз-М» тратит в среднем 1 - 2 часа на обслуживание в отделе продаж (изучение номенклатуры изделий, оформление заявки, проверка готовности заказа на складе, ожидание выписки счета, оплата счета, выписка требования). Сотрудник отдела продаж тратит на обслуживание одного заказчика не менее 40 минут. С учетом оформления ручных документов, он обслуживает за день 8 – 10 клиентов. Времени на подготовку аналитических документов для руководителя отдела продаж не достаточно. Часть заказчиков обслуживается не по отдельным контактам, а по договорам. В этом случае в отделе продаж они расходуют не более 30 минут, но они тратят не менее 1 часа на подготовку договора и достаточно много времени на согласование и подписание контракта. Клиенты хотели бы получать информацию о продукции «Метиз-М» по сети и по сети посылать заявку на приобретение продукции. Получать счета по электронной почте. Оплачивать продукцию не только в кассе, но и с помощью безналичных расчетов. Осуществлять непосредственные контакты с сотрудником отдела продаж только при получении требования на готовую продукцию. Это позволит не только уменьшить время на обслуживание клиента, улучшить сервис обслуживания, но и получать дополнительную информацию о заказчиках продукции «Метиз-М», и усовершенствовать каналы продаж.
Бизнес - цели и критерии успеха.
Бизнес – цель 1. Уменьшить среднее рабочее время каждого сотрудника на обслуживание заказчика до 20 минут в течение 3 месяцев после первого выпуска информационной системы.
Бизнес - цель 2. Уменьшение времени заказчика для оформления заказа не более 1 часа с учетом двух возможностей: сетевого обслуживания и непосредственного контакта с клиентом в течение 3 месяцев после выпуска системы.
Бизнес – цель 3. Увеличить число продаж на 50% в течение 3 месяцев после первого выпуска информационной системы.
Критерий успеха 1. Все сотрудники отдела продаж, работающие с заказчиками должны в течение 2 месяцев после первого выпуска системы перейти на работу с ИС.
Критерий успеха 2. Выявление новых источников (увеличение на 50%) прибыли за счет поиска новых каналов продаж в течение 12 месяцев после запуска ИС.
Факторы бизнес – риска.
Фактор бизнес – риска 1. Введение новых форм обслуживания заказчиков зависит от уровня информатизации организации-заказчика. Не все заказчики готовы к новой форме обслуживания. Вероятность = 0,5.
Фактор бизнес – риска 2. Не все сотрудники отдела продаж готовы к работе с новой ИС. Потребуются финансовые и временные ресурсы на обучение персонала. Вероятность = 0,6.
Фактор риска 3. Возможна реструктуризация отдела продаж и изменение функций сотрудников отдела продаж. Вероятность = 0,3.
Образ решения.
Положение об образе проекта. Для клиентов «Метиз-М» новая информационная система будет представлять собой Интернет-приложение, позволяющее ознакомиться с номенклатурой производимых крепежных изделий, оформить заявку на покупку готовых изделий. Кроме того, эта система позволит произвести оплату покупаемой продукции. Для сотрудников отдела продаж информационная система представляет собой приложение, представляющее информацию о готовой продукции на складе, выписывать счет на оплату продукции, отправлять информацию в отдел договоров о выполнении заказа. Для топ-менеджеров предприятия информационная система представляет собой приложение, которое готовит аналитические отчеты о продажах, выдает целостное представление о потребителе крепежных изделий.
Основные функции.
Основные функции 1. Создание, просмотр, изменение и удаление текущей номенклатуры готовой продукции (прайс-лист «Метиз-М»).
Основные функции 2. Предоставление бланка-заказа готовой продукции клиенту, прием бланка-заказа от клиента.
Основные функции 3. Запрос на склад о требуемой продукции.
Основные функции 4. Создание счета на оплату, предоставление счета клиенту.
Основные функции 5. Создание требования на оплаченную продукцию.
Основные функции 6. Изменение состояния склада после продажи продукции.
Основные функции 7. Запрос на отгрузку оплаченной продукции.
Основные функции 8. Создание сообщения в отдел договоров о продаже продукции.
Основные функции 9. Создание и выдача текущих и аналитических отчетов.
Основные функции 10. Обеспечение доступа к системе через корпоративную сеть интранет или через Интернет для авторизированных пользователей.
Предположения и зависимости.
Предположения и зависимости 1. В отделе продаж будут установлены компьютеры, подключенные к сети интранет. Сеть интранет будет иметь выход в сеть Интернет.
Предположения и зависимости 2. Заказчики и клиенты «Метиз-М» будут оснащены компьютерами, имеющими выход в Интернет.
Масштабы и ограничения проекта
Ограничения и исключения
Ограничения и исключения 1. Некоторые клиенты не будут иметь доступа в Интернет и будут обслуживаться ИС непосредственно через сотрудника отдела продаж.
Ограничения и исключения 2. Информационная система будет применяться только для «Метиз-М».
Следующий этап формирования требований – разработка требований пользователей и описание их в виде документа о вариантах использования. Варианты использования в данном случае меняют традиционный подход к сбору информации; пользователей не спрашивают, что с их точки зрения должна делать система, а выясняют, какие задачи собирается с ее помощью решать пользователь. Цель такого подхода – описать все подобные задачи. Последовательность работ при формировании требований следующая: вначале отбираются пользователи системы, далее перечисляются для каждого пользователя варианты использования и затем описывается каждый вариант использования. При описании вариантов использования учитывают, что к важным элементам описания вариантов использования относятся:
- уникальный идентификатор;
- имя, кратко описывающее задачи пользователя в формате «глагол + объект»;
- краткое текстовое описание на естественном языке;
- список предварительных начальных условий, которые должны быть удовлетворены до начала разработки варианта использования;
- выходные условия, описывающие состояние системы после успешного завершения разработки вариантов использования;
- пронумерованный список действий (сценарий), иллюстрирующий последовательность этапов взаимодействия лица и системы от предварительных условий до выходных условий. При этом один из сценариев считается нормальным направлением развития, другие – альтернативными направлениями;
- приоритет, частота варианта использования и другие особые требования.
Выделим пользователей проектируемой системы. Результаты предпроектного обследования показали, что к ним относятся: заказчик, сотрудник отдела продаж, обслуживающий заказчиков, руководитель отдела продаж, кассир, кладовщик, менеджер отдела договоров, сотрудник производственного отдела, сотрудник отдела цен.
Для каждого пользователя перечислим варианты использования:
| Действующее лицо (актер) | Вариант использования (прецедент) |
| Заказчик | 1. Просмотр номенклатуры изделий. 2. Оформление бланка-заказа. 3. Отмена заказа. 4. Получение документов на оплату. 5. Оплата наличными через кассу. 6. Оплата через банк. 7. Оплата по взаимозачету. 8. Получение документов об оплате. 9. Представление документов об оплате. 10. Получение требования на выдачу продукции. |
| Сотрудник отдела продаж | 11. Просмотр заказов на текущую дату. 12. Просмотр договоров на текущую дату. 13. Предоставление бланка-заказа. 14. Прием бланка-заказа. 15. Просмотр текущего состояния склада. 16. Запрос на склад о выполнении договора на текущую дату. 17. Запрос на склад о возможности выполнения заказа покупателя. 18. Формирование отказа на выполнение заказа. 19. Формирование документа об изменении сроков поставки продукции по договорам. 20. Создание счета на оплату продукции. 21. Проверка оплаты. 22. Проверка выполнения договорных обязательств по оплате. 23. Создание требования на получение продукции со склада. 24. Изменение состояния склада. 25. Создание сообщения об отгрузке продукции по обслуживаемому договору. 26. Генерация текущего отчета о продажах. |
| Руководитель отдела продаж | 27. Генерация текущего отчета о заказчиках. 28. Генерация текущего отчета о выполнении договоров. 29. Генерация текущего отчета о выполнении заказов. 30. Генерация аналитического отчета. |
| Кассир | 31. Регистрация счета на оплату. 32. Создание документа о произведенной оплате. |
| Кладовщик | 33. Регистрация требования на выдачу продукции. 34. Создание накладной на вывоз продукции со склада. |
| Менеджер отдела договоров | 35. Регистрация сообщения о выполнении договора. |
| Сотрудник производственного отдела | 36. Создание номенклатуры изделий. 37. Изменение номенклатуры изделий. 38. Просмотр номенклатуры изделий. 39. Удаление номенклатуры изделий. |
| Сотрудник отдела цен | 40. Создание цен товарной продукции. 41. Изменение цен товарной продукции. 42. Просмотр цен товарной продукции. |
В качестве примера рассмотрим описание одного варианта использования.
| № варианта использования | Вариант использования 2 |
| Название | Оформление бланка-заказа |
| Автор | Ипатова Э.Р. |
| Дата создания | 15.09.04 |
| Действующее лицо | Заказчик |
| Описание | Заказчик входит в систему из корпоративной сети интранет или с домашнего компьютера, просматривает текущую номенклатуру изделий, текущую цену на изделия, выбирает изделия. Запрашивает бланк заказа и заполняет его. Отправляет бланк заказа. |
| Предварительные условия. | Заказчик имеет доступ к системе. Текущая номенклатура изделий и текущая цена готовой продукции подготовлены к использованию системой. |
| Выходные условия | Заказ на продажу изделий сохранен в системе со статусом «принят». Заказ на продажу изделий не сохранен в системе в связи с отсутствием изделий на складе. Система выводит список тех позиций заказа, которые могут быть выполнены. |
| Нормальное направление | 1.0. Заказ может быть выполнен полностью или частично. 1. Заказчик запрашивает номенклатуру изделий. 2. Система выдает текущую номенклатуру изделий. 3. Заказчик выбирает изделия. 4. Заказчик запрашивает текущую цену выбранных изделий. 5. Система выдает текущие цены выбранных изделий. 6. Заказчик выбирает изделия с текущей ценой. 7. Система выводит бланк-заказа с указанием стоимости каждой позиции изделия, общей суммы, включая все налоги. 8. Заказчик подтверждает заказ или делает запрос на изменение заказа (переход к пункту 3). 9. Система подтверждает, что заказ принят на рассмотрение и указывает время ожидания подтверждения заказа. |
| Альтернативное направления 1 | 1.1. Заказ не может быть выполнен в виду отсутствия нужной номенклатуры изделий. 1. Изделий, необходимых заказчику в номенклатуре нет. 2. Система выводит запрос о выходе из системы. 3. Заказчик подтверждает выход из системы. |
| Альтернативное направление 2 | 1.2. Заказ не оформляется в связи с ценой, не удовлетворяющей заказчика. 1. Цена на изделия не удовлетворяет заказчика. 2. Система выводит запрос о выходе из системы. 3. Заказчик подтверждает выход из системы. |
| Приоритет | Высокий |
| Частота использования | Около 100 заказчиков в день |
| Особые требования | 1. Заказчик должен иметь возможность отменить заказ в любой момент времени до подтверждения заказа. 2. Заказчик должен иметь возможность просматривать все свои заказы за текущий год и повторить его при условии, что все пункты заказа совпадают с текущими условиями (текущей номенклатурой и ценой). |
| Замечания и вопросы | 1. Дата заказа по умолчанию – текущая. 2. Пиковая нагрузка на этот вариант использования с 8.00 до 18.00 по местному времени. |
Заключительный этап формирования требований – создание спецификации требования к ПО. Этот итоговый документ является задокументированным соглашением между клиентом и разработчиком. В настоящее время доступны различные шаблоны спецификации, однако многие применяют шаблон, описанный в IEEE Standard 830-1998, «IEEE Recommended Practice for Software Requirements Specifications» (IEEE, 1998b).
1.Введение
1.1. Назначение
1.2. Соглашения, принятые в документах
1.3. Предполагаемая аудитория и рекомендации по чтению
1.4. Границы проекта
1.5. Ссылки
2. Общее описание
2.1. Общий взгляд на продукт
2.2. Особенности продукта
2.3. Классы и характеристики пользователей
2.4. Операционная среда
2.5. Ограничения дизайна и реализации
2.6. Документация для пользователей
2.7. Предположения и зависимости
3. Функции системы
3.х Функция системы x
3.х.1. Описание и приоритеты
3.х.2. Последовательности «воздействие – реакция»
3.х.3. Функциональные требования
4. Требования к внешнему интерфейсу
4.1. Интерфейсы пользователя
4.2. Интерфейсы оборудования
4.3. Интерфейсы ПО
4.4. Интерфейсы передачи информации
5.Другие нефункциональные требования
5.1. Требования к производительности
5.2. Требования к охране труда
5.3. Требования к безопасности
5.4. Атрибуты качества
6. Остальные требования
7. Приложения
Этот шаблон может быть изменен в соответствие с особенностями проекта. Анализ шаблона показывает, что в некоторых разделах он пересекается с шаблоном на документ об образе и границах проекта, что совершенно естественно. Спецификация требований является итоговым документом, а документ об образе и границах – промежуточным.
Спецификация требований к системе.
Введение
1.1. Назначение. Этот документ описывает функциональные и нефункциональные требования к выпуску 1.0 «Системы продаж Метиз-М».
1.2. Предполагаемая аудитория. Этот документ предназначен для групп проектировщиков и программистов для создания системного и детального проектов системы и ее программной реализации.
Общее описание
2.1. Общий взгляд на продукт. Система продаж Метиз-М – это новая система, которая заменит текущие процессы заказа продукции в «Метиз – М» и отпуска готовой продукции по договорам. Предполагается построить несколько версий системы для интеграции ее в корпоративную систему управления предприятием «Метиз-М». Контекстная диаграмма, описывающая взаимодействие системы с внешними объектами изображена на рис.31.
Рис.31 Контекстная диаграмма системы продаж
2.2. Классы и характеристики пользователей
| Класс пользователей | Описание |
| Заказчик (привилегированный) | Заказчик – это физическое или юридическое лицо, находящееся в России, странах СНГ и ближнем зарубежье, желающее купить изделия предприятия «Метиз-М» в свободной продаже или по договору. Всего потенциальных клиентов – 10000. Из них – 1000 – постоянные клиенты с большим объемом продаж. Ожидается, что 50% заказов будет поступать из корпоративной сети компании (заказ непосредственно в отделе продаж) и 50% - из сети Internet. |
| Сотрудник отдела продаж | В настоящее время непосредственно продажами занимается один сотрудник отдела. При введении новой системы продаж ожидается увеличение потока заказчиков. Поскольку предполагается обслуживать покупателей разных часовых поясов, имеет смысл ввести двухсменное обслуживание системы с учетом выходных дней (не менее 3 сотрудников). Этих сотрудников необходимо обучить работе с ПК, информационной системой и работой с Internet. |
| Руководитель отдела продаж | Руководитель отдела продаж – это сотрудник компании «Метиз – М», управляющий процессом реализации готовой продукции. При введении «Системы продаж Метиз-М» он должен будет выдавать запросы о заказчиках, продажах и получать аналитические отчеты. Его необходимо обучить работе с ПК, информационной системой и работой с Internet. |
| Кассир | Кассир - это сотрудник бухгалтерии, который должен будет вводить в систему информацию о произведенной оплате и выводить на печать документ об оплате. В настоящее время кассу могут обслуживать два кассира. Увеличивать число кассиров не надо, поскольку планируется увеличение числа продаж по безналичному расчету. Кассира необходимо обучить работе с ПК и информационной системой. |
| Кладовщик | Кладовщик – это сотрудник склада, занимающийся выдачей готовой продукции. Он должен провести регистрацию требования и выдать на печать накладную на товар, включая и транспортную накладную. В настоящее время отпуском товара занимаются три кладовщика. В связи с прогнозируемым увеличением продаж необходимо увеличить число кладовщиков до 6 человек. Их необходимо обучить работе с ПК и информационной системой. |
| Менеджер отдела договоров | Менеджер отдела договоров – сотрудник отдела договоров, который занимается мониторингом договоров и закрытием договоров. В настоящее время – это один сотрудник. Увеличивать штат при введении системы не рекомендуется. Система будет автоматически закрывать договор, если произведена выдача товара со склада. Менеджер будет получать эту информацию. Его необходимо обучить работе с ПК и информационной системой. |
| Сотрудник производственного отдела | Сотрудник производственного отдела должен по необходимости (не реже одного раза в месяц) вносить изменения (редактировать) номенклатуру изделий, выпускаемых Метиз-М. Его необходимо обучить работе с ПК И информационной системой. |
| Сотрудник отдела цен | Сотрудник отдела цен должен по необходимости (не реже одного раза в месяц) вносить изменения (редактировать) цены на продукцию Метиз-М. Его необходимо обучить работе с ПК и информационной системой. |
2.3. Операционная среда
Операционная среда - 1. Система продаж Метиз-М работает со следующими Интернет-браузерами: Microsoft Internet Explorer версии 5.0 и версии 6.0, Netscape Communicator версии 6 и версии 7.
Операционная среда – 2. Система продаж установлена на сервере, работающим под управлением текущих утвержденных корпорацией версий Red Hat Linux и Apache HTTP Server.
Операционная среда – 3. Система продаж должна осуществлять доступ зарегистрированных пользователей через корпоративную сеть интранет и авторизированных пользователей через корпоративный брандмауэр из Internet.
2.4. Ограничения дизайна и реализации
Ограничения дизайна и реализации – 1. Документация системы по конструкции, коду и сопровождению должна соответствовать стандарту
Ограничения дизайна и реализации – 2. Система должна использовать текущую версию корпоративного стандарта процессора базы данных Oracle.
Ограничения дизайна и реализации – 3. Весь код HTML должен соответствовать стандарту HTML 4.0.
Ограничения дизайна и реализации – 4. Все сценарии должны быть написаны на Perl.
2.5. Документация для пользователей
Документация для пользователей – 1. Система должна предоставлять иерархическую и перекрестно связанную систему справки в формате HTML с доступом по сети, описывающую и иллюстрирующую все функции системы для конкретного зарегистрированного и авторизированного пользователя.
Документация для пользователей – 2. При первом доступе пользователя к системе и далее по требованию пользователя система должна подключать интерактивную обучающую программу.
2.6. Предположения и зависимости
Предположения и зависимости – 1. Доступ к системе продаж открыт для заказчиков ежедневно, включая выходные и праздничные дни.
Предположения и зависимости – 2.Обработка заказов системой продаж производится только в рабочие дни.
Предположения и зависимости – 3. Работа системы продаж зависит от системы оплаты (оплата по безналичному расчету и проведение взаимозачетов).
Предположения и зависимости – 4. Работа системы продаж зависит от системы производства, формирующей номенклатуру и цены на изделия Метиз – М.
Функции системы
В качестве примера рассмотрим функцию заказа на приобретение крепежных изделий.
3.2. Заказ
3.2.1. Описание и приоритет. Заказчик продукции Метиз – М, идентификация которого подтверждена, может заказывать крепежные изделия, исходя из номенклатуры изделий и учитывая цены на продукцию. Заказчик должен иметь возможность в любой момент до принятия заказа к исполнению изменить заказ или отменить его. В некоторых дополнительно оговоренных случаях отменить заказ при условии принятия его к исполнению. Приоритет – высокий.
3.2.2. Последовательности «воздействия – реакция»
| Воздействие | Реакция |
| Заказчик делает запрос на размещение заказа крепежных изделий. | Система опрашивает заказчика о деталях заказа, способе оплаты за заказ. |
| Заказчик делает запрос на изменение заказа. | Если заказ не принят к исполнению, то система позволяет заказчику изменить заказ. |
| Заказчик делает запрос на отмену заказа. | Если заказ не принят к исполнению или воздействие будет иметь статус «Принято», то заказ будет отменен. |
3.2.3. Функциональные требования.
| Название требования | Действие системы |
| Заказ.Размещение | Система продаж должна позволять заказчику, зарегистрированному в системе, размещать заказ на приобретение продукции Метиз – М согласно номенклатуре выпускаемых изделий. |
| Заказ.Размещение.Регистрация | Система должна подтвердить, что заказчик зарегистрирован в системе после заполнения им соответствующей регистрационной анкеты. |
| Заказ.Размещение.Регистрация.Нет | Система отказывает в регистрации, если заказчик не выполнил правил регистрации в системе или данные о заказчике противоречат политике безопасности предприятия. |
| Заказ.Размещение.Номенклатура | Система должна выводить заказчику номенклатуру изделий «Метиз-М» с указанием текущей цены. |
| Заказ.Размещение.Номенклатура. Предложения для продажи.Выбор | Система должна предоставить заказчику систему выбора продукции из имеющихся предложений для продажи с учетом текущей номенклатуры изделий. |
| Заказ.Размещение.Номенклатура. Выбор | Система должна предоставить заказчику систему выбора продукции из текущей номенклатуры изделий. |
| Заказ.Размещение.Дата | Система должна запрашивать заказчика о дате отгрузки готовой продукции. |
| Заказ.Размещение.Дата.Крайний срок | Система должна в случае невозможности выполнения заказа в срок, указанный заказчиком, предложить ему реальный срок выполнения заказа. |
| Заказ.Размещение.Оплата | Система должна выводить заказчику перечень форм оплаты за готовую продукцию. |
| Заказ.Размещение.Оплата.Выбор | Система должна предоставить заказчику систему выбора способа оплаты за готовую продукцию. |
| Заказ.Номенклатура | Система должна выводить зарегистрированному пользователю текущую номенклатуру изделий с указанием текущих цен (то, что предприятие может производить). |
| Заказ.Номенклатура.Предложения для продажи. | Система должна выводить заказчику перечень крепежных изделий, готовых в данный момент для продажи с указанием текущих цен. |
| Заказ.Оплата. | Система должна выводить заказчику формы оплаты готовой продукции. |
| Заказ.Подтверждение.Вывод | Когда заказчик указывает, что он больше не хочет продолжать заказывать крепежные изделия, система должна вывести заполненный бланк заказа с указанием как сумм отдельных позиций заказа, так и общей суммы заказа. |
| Заказ.Подтверждение.Приглашение | Система должна подсказать заказчику подтвердить заказ. |
| Заказ.Подтверждение.Отказ | Если заказчик не подтверждает заказ, он должен иметь возможность либо изменить заказ, либо отменить заказ. |
| Заказ.Завершение.Сохранение | После подтверждения заказа система должна присвоить заказу следующий доступный номер и сохранить заказ со статусом «принят». |
| Заказ.Завершение.Склад | Система должна сообщить системе склад о необходимости выдачи готовой продукции. |
| Заказ.Завершение.Склад.Изменение | Система склад должна внести коррективы в перечень готовых изделий, предназначенных для продажи |
| Заказ.Завершение.Производство | Система должна сообщить системе производство о необходимости произвести заказанную продукцию. |
| Заказ.Завершение.Производство. Изменение | Система производства должна внести коррективы в перечень изделий, необходимых произвести со статусом «под заказ» |
| Заказ.Завершение.Заказчик | Система должна выдать заказчику на руки готовый бланк заказа или послать его по e-mail. |
| Заказ.Предыдущий период | Система должна позволять заказчику просматривать сделанные им заказы в течение текущего года. |
| Заказ.Предыдущий период.Повтор | Система должна позволять заказчику повторить любой заказ, сделанный им в течение текущего года. |