Ниже представлен пример (образец) проектного документа спецификации на разработку интерфейса передачи данных в SAP PI.
Функциональная спецификация
— Каналы ввода: клавиатура, для ввода базы CD-привод.
— Каналы вывода: монитор, принтер, проектор.
— Схема информационных объектов (рис. 1).
Рис. 1. Схема информационных объектов.
Определение программного продукта базы данных
База данных должна выполнять: ввод данных, запросы на выборку, вывод данных на печать, монитор, доску.
Описание входных данных
Ключевое, 8 символов
т. Личные данные
Ключевое, 8 символов
100 символов, повторы допускаются
50 символов, повторы допускаются
100 символов, повторы допускаются
Маска ввода: 00.00.0000, повторы допускаются
250 символов, повторы не допускаются
Длинное целое, повторы не допускаются
Функциональные требования. Это документ или часть ТЗ
база данные картотека
Ключевое, 8 символов
8 символов, повторы допускаются
Фиксированный, маска ввода 0,00 р., повторы допускаются
Маска ввода 00.00.0000;0;_
Мастер подстановок, повторы допускаются
Кол-во мин. за месяц
Длинное целое, повторы допускаются
Мастер подстановок, повторы допускаются
Мастер подстановок, повторы допускаются
Описание выходных данных
· ф. Абоненты: код Абонента, текстовый; Фамилия, текстовый; Имя, текстовый; Отчество, текстовый; Тариф, текстовый, мастер подстановок;
· ф. Личные данные: код Абонента, текстовый; Фамилия, текстовый; Имя, текстовый; Отчество, текстовый; Дата рождения, Дата/Время; Домашний адрес, текстовый; Телефон, числовой;
· ф. Оплата: код Оплаты, текстовый; код Абонента, текстовый; Фамилия, текстовый; Имя, текстовый; Сумма, денежный; Оплатить до, Дата/Время; Вид оплаты, текстовый, мастер подстановок; Кол-во мин в месяц, числовой; Льготы, текстовый, мастер подстановок; Оплачено, логический.
· з. Задолженности(абонентская): код Оплаты, текстовый; Фамилия, текстовый; Имя, текстовый; Сумма, денежный; Оплатить до, Дата/Время; Оплачено, логический; Телефон, числовой;
· з. Задолженности(абонентская): код Оплаты, текстовый; Фамилия, текстовый; Имя, текстовый; Сумма, денежный; Оплатить до, Дата/Время; Оплачено, логический, мастер подстановок; Телефон, числовой.
· Отчет Квитанции: Поля Фамилия, Имя, Отчество, Домашний адрес, Телефон; Сумма, Оплатить до, Оплачено.
Описание нежелательных ситуаций
Программное средство не будет функционировать (либо будет функционировать некорректно) в следующих случаях:
— Если отключен компьютер.
— Отсутствует CD — ROM (не будет возможным установить базу данных).
— Если поврежден носитель (диск).
— Недостаточно места на жёстком диске (винчестере) для установки базы данных или недостаточно места на жёстком диске (винчестере) для сохранения новой информации.
Функциональная спецификация для разработки SAP-программ: быстрый старт – демо вебинара
— Если операционная система ниже Windows 2000.
— Если на компьютере отсутствует MS Access или другие программы, позволяющие работать с базами данных.
Спецификация качества
Завершенность: БД содержит всю необходимую информацию, которая требовалась от Заказчика
Завершённость: 1-я версия продукта.
Точность: В базе данных точно выполняются все отчёты и запросы
Автономность: База данных будет функционировать только при наличии Microsoft Access
Устойчивость: При введении неправильных входных данных база данных будет корректно функционировать
Защищенность: Можно случайно или намеренно удалить информацию из базы данных
Документированность: Информация, которой располагает база данных, понятна, доступна пользователю. Имеется справочная информация для пользователя
Информативность: Продукт позволяет наиболее быстро найти необходимую информацию об абонентах.
Коммуникативность: Информация легко воспринимается.
Временная: Быстрый переход на необходимую таблицу, запрос, отчёт благодаря удобному интерфейсу
По ресурсам: Запускается на минимальных системных ресурсах, не требует много памяти.
Модифицируемость: Можно изменить содержимое таблиц, отчётов и запросов.
Источник: studentopedia.ru
ФУНКЦИОНАЛЬНАЯ СПЕЦИФИКАЦИЯ ПРОГРАММНОГО СРЕДСТВА
Описание поведения ПС определяет функции, которые должно выполнять ПС, и потому его называют функциональной спецификацией ПС [20]. С учетом назначения функциональной спецификации ПС и тяжелых последствий неточностей и ошибок в этом документе, функциональная спецификация (ФС) должна быть математически точной.
Это не означает, что она должна быть формализована настолько, что по ней можно было бы автоматически генерировать программы, решающие поставленную задачу. А означает лишь, что она должна базироваться на понятиях, построенных как математические объекты, и утверждениях, однозначно понимаемых разработчиками ПС. Достаточно часто ФС формулируется на естественном языке. Тем не менее, использование математических методов и формализованных языков при разработке ФС весьма желательно.
Функциональные спецификации — это часть исходных данных для проектирования информационно-управляющей системы, определяющая, что должна сделать система и как она должна быть взаимосвязана с окружением. Разработка ФС тесно связана с обоснованием включения тех или иных действий в функциональные требования, но не заменяет его. Для математически определенного действия достаточно включить его наименование с указанием типов исходных данных. Однако при проектировании ИС именно выявление сущности выполняемого действия составляет один из важнейших элементов проектирования.
Функциональная спецификация состоит из трех частей:
- • описания внешней информационной среды, к которой должны применяться программы разрабатываемой ПС;
- • формулирование функций ПС, определенных на множестве состояний этой информационной среды (такие функции будем называть внешними функциями ПС);
- • описание нежелательных (исключительных) ситуаций, которые могут возникнуть при выполнении программ ПС, и реакций на эти ситуации, которые должны обеспечить соответствующие программы.
В первой части должны быть определены на концептуальном уровне все используемые каналы ввода и вывода и все информационные объекты, к которым будет применяться разрабатываемое ПС, а также существенные связи между этими информационными объектами. Примером описания информационной среды может быть концептуальная схема БД или описание сети датчиков и приборов, которой должна управлять разрабатываемая ПС.
Во второй части вводятся обозначения всех определяемых функций, специфицируются все входные данные и результаты выполнения каждой определяемой функции, включая указание их типов и заданий всех соотношений (или ограничений), которым должны удовлетворять эти данные и результаты. И, наконец, определяется семантика каждой из этих функций, что является наиболее трудной задачей функциональной спецификации ПС. Обычно эта семантика описывается неформально на естественном языке — примерно так, как это делается при описании семантики многих языков программирования. Эта задача может быть в ряде случаев существенно облегчена при достаточно четком описании внешней информационной среды, если внешние функции задают какие-либо манипуляции с ее объектами.
В третьей части должны быть перечислены все существенные случаи, когда ПС не сможет нормально выполнить ту или иную свою функцию (с точки зрения внешнего наблюдателя). Примером такого случая может служить обнаружение ошибки во время взаимодействия с пользователем или попытка применить какую-либо функцию к данным, не удовлетворяющим соотношениям, указанным в ее спецификации, или получение результата, нарушающего заданное ограничение. Для каждого такого случая должна быть определена (описана) реакция ПС.
Источник: studref.com