Учебный пример описания требований к программному изделию

Размещено на http://www.allbest.ru/

Учебный пример описания требований к программному изделию

Грибановская Н.В.

Коровина О.В.

Фролов А.И.

The paper discusses the training example of the specifications description for a software according to IEEE 830-1993. This example has been used as the practice task for the subject «Software development technology» for the specialty «Software of computer techniques and automated systems».

Требования должны однозначно определять конечный продукт разработки. Результатом анализа требований является документ, который обычно называется спецификацией требований к программному обеспечению (SRS - Software Requirements Specification). Как правило, требования разделяются на 2 уровня: С-требования выражают требования в форме, удобной заказчику; D-требования представляют собой более подробную форму С-требований и предназначены для разработчиков.

Существует несколько способов организации SRS. Например, в соответствии со стандартом IEEE 830-1993 (Institute of Electrical and Electronic Engineering - Институт инженеров по электротехнике и электронике) для документирования требований используются следующие разделы [1,2]: программный спецификация автоматизированный

D-требования С-требования

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

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

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

По результатам проделанной работы студенты готовят отчет, включающий логическую модель данных, тексты программ и описание требований, следуя форме IEEE 830-1993. Один из вариантов описания системы представлен далее.

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

Область применения (какие аспекты программ этот документ должен охватить)

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

Определения, термины и сокращения

2 Общее описание

Система обеспечивает решение следующих задач:

– учет студентов;

– поддержка перечня специальностей и их учебных планов;

– формирование рабочих и отчетных документов.

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

Система включает в себя следующие подсистемы: Приемной комиссии; Учебного управления; Факультета; Администрирования.

Подсистема Приемной комиссии обеспечивает реализацию следующих функций:

– ввод личных данных студентов (ФИО, дата рождения, адрес прописки), зачисленных на определенную специальность;

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

Подсистема Учебного управления обеспечивает реализацию следующих функций:

– формирование и поддержка перечня специальностей по факультетам;

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

– вывод учебного плана.

Подсистема Факультета обеспечивает реализацию следующих функций:

– ввод групп студентов и поддержка актуальности их списков;

– просмотр учебных планов специальностей;

– формирование и вывод списков групп и экзаменационных ведомостей для КР, КП, ЗАЧ и ЭКЗ по дисциплинам.

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

2.1 Перспективы продукта (в этом разделе данный программный продукт сравнивается с другими похожими или конкурирующими продуктами)

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

2.2 Функции продукта

Данное приложение обеспечивает решение следующих задач:

1) ввод личных данных студентов, зачисленных на определённую специальность;

2) формирование списков зачисленных студентов по специальностям;

3) формирование и поддержка перечня специальностей по факультетам;

4) формирование и поддержка учебного плана специальностей;

5) ввод и редактирование учётных записей пользователей.

2.3 Пользовательские характеристики (какие люди будут типичными пользователями программы)

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

2.4 Ограничения (все условия, которые могут ограничивать возможности разработчиков).

Данное приложение будет использоваться на персональных компьютерах, работающих под управлением операционной системы Windows 2000/XP или более поздней и оснащенных процессорами с тактовой частотой не менее 600 МГц. Для разработки будет использоваться СУБД InterBase 6.0. Использование данной СУБД обусловлено её высокой изученностью и наличием в среде Borland Delphi компонентов, обеспечивающих взаимодействие с ней.

2.5 Предположения и зависимости

Нет.

2.6 Распределение требований (порядок, в котором требования будут выполняться)

Требования, описанные в разделах 1 и 2 этого документа, будут называться «С-требования», в разделе 3 - «D-требования». Основной аудиторией С-требований будет сообщество заказчиков, вторичной - разработчиков. Для D-требований ситуация обратная.

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

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

3.1 Требования к внешнему интерфейсу

3.1.1 Пользовательские интерфейсы

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

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

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

Рисунок 1 - Окно авторизации пользователя

В подсистеме «Приемная комиссия» проводится зачисление студентов на определённую специальность, а также возможно формирование списков студентов, уже зачисленных на выбранную специальность (рисунок 2).

Рисунок 2 - Окно «Приемная комиссия»

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

Рисунок 3 - Окно «Учебное управление»

Подсистема «Факультет» предназначена для поддержки и корректировки учебного плана. Для выбранной специальности можно просмотреть и изменить план. При необходимости возможно создание новой дисциплины и включение её в текущий план (рисунок 4).

Рисунок 4 - Окно «Факультет»

В подсистеме «Администрирование» должна быть реализована возможность добавления новых пользователей созданной программы и изменение учётных записей уже созданных пользователей (рисунок 5).

Рисунок 5 - Окно «Администрирование»

3.1.2 Аппаратные интерфейсы

Разрабатываемая система использует стандартные аппаратные интерфейсы (устройства ввода/вывода: клавиатура, мышь, монитор, принтер и другие; сетевой адаптер для доступа к локальной сети), средства доступа к которым реализуются операционной системой.

3.1.3 Программные интерфейсы

Программный продукт разработан для функционирования под управлением операционной системы Windows. Для его корректной работы необходимо полноценное функционирование этой операционной системы и наличие запущенных и настроенных программных средств сетевого взаимодействия по протоколам TCP/IP. Никаких других требований к программным интерфейсам нет.

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

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

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

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

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

При работе данного приложения будет использоваться в среднем 5Мб оперативной памяти, для хранения базы данных на сервере будет использоваться минимум 512Мб. Само приложение занимает 850Кб. Для хранения базы данных необходимо до 8 Гб свободного пространства на жёстком диске.

Время ответа на запрос программы не более 2 сек.

3.4 Ограничения проектирования

Проектирование приложения должно быть выполнено с использованием объектно-ориентированного подхода. Реализация должна быть выполнена в среде Borland Delphi.

3.5 Атрибуты программной системы

3.5.1 Надежность

Не более 1 отказа при 100 запусках программы.

3.5.2 Доступность

Программа должна быть доступна на ПК под Windows 2000/XP (или более поздней версии).

3.5.3 Защита

Защита от несанкционированного доступа к информации - механизм аутентификации при входе пользователя в систему.

3.5.4 Поддержка

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

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

Нет.

4 Сопровождающая информация

4.1 Оглавление и индекс

Будет приложено.

4.2 Приложения

Будут добавлены.

ЛИТЕРАТУРА

1. Брауде, Э. Технология разработки программного обеспечения [Текст] / Э.Брауде - СПб.: Питер, 2004.- 655с., ил.

2. IEEE Software Engineering Standards Collection, 1997 Edition, Piscataway, NJ:IEEE, 1997

Размещено на Allbest.ru