А.3.2.1 Предусмотреть контроль вводимой информации. При вводенекорректных данных при добавлении и изменении в таблице, система должна выводить сообщение об ошибке.
А.3.2.2 Предусмотреть защиту от некорректных действий пользователя. Информационная система должна выводить предупреждающие сообщения при выполнении критических операций пользователя.
А.3.2.3 Обеспечить целостность информации. Обеспечить каскадное удаление данных в таблицах и создания резервной копии базы данных.
А.3.3 Условия эксплуатации
А.3.3.1 Условия эксплуатации в соответствие с СанПин 2.2.2.542 – 96.
А.3.3.2 Обслуживание программного средства осуществляется заранее обученным администратором.
А.3.4 Требования к составу и параметрам технических средств
А.3.4.1 Программное обеспечение должно функционировать на IBM- совместимых персональных компьютерах.
А.3.4.2 Минимальная конфигурация технических средств для клиента:
А.3.4.2.1 Процессор . Intel Celeron CPU 1.70 GHz;
Как отличать нефункциональные требования?
А.3.4.2.2 Объем ОЗУ. 512 Мб и выше.
А.3.5 Требования к информационной и программной совместимости
А.4.5.1. Программное обеспечение должно работать под управлением операционных систем семейства Windows (WindowsXP, Windows 7, Windows 8, Windows 10).
А.3.6 Требования к маркировке и упаковке
Требования к маркировке и упаковке не предъявляются.
А.3.7 Требования к транспортированию и хранению
Требования к транспортировке и хранению не предъявляются.
А.4Требования к программной документации
А.4.1 В состав сопровождающей документации должны входить:
А.4.1.2 Техническое задание (ПРИЛОЖЕНИЕ Б).
А.4.1.3 Руководство оператора(ПРИЛОЖЕНИЕ Г).
А.4.1.4 Программа и методика испытаний (ПРИЛОЖЕНИЕ Д).
А.4.1.5 Описание программы(ПРИЛОЖЕНИЕ В).
А.4.1.6 Диаграмма IDEF1X (ПРИЛОЖЕНИЕ В).
А.4.1.7 Диаграмма вариантов использования (ПРИЛОЖЕНИЕ А).
А.5 Требования к маркировке и упаковке
Требования к маркировке и упаковке не предъявляются.
А.6 Порядок контроля и приемки
А.6.1 Порядок контроля
Контроль выполнения осуществляется преподавателем еженедельно.
А.6.2 Порядок защиты
Защита осуществляется перед комиссией.
А.6.3 Срок защиты
Срок защиты определяется планом технологической практики.
А.7 Примечание
В процессе выполнения работы возможно уточнение отдельных требований технического задания по взаимному согласованию руководителя и исполнителя.
ПРИЛОЖЕНИЕ В
(обязательное)
ДиаграммаIDEF1X
Рисунок В.1 – Логическая модель данных
Рисунок В.2 – Физическая модель данных
ПРИЛОЖЕНИЕ Г
(обязательное)
Руководство оператора
Г.1 Назначение программы
Информационная система «Отдел кадров школы» предназначена учета учителей в школе. Информационная система предназначена для начальника отдела кадров, секретаря, завуча. Для каждого из них обеспечены свои собственные требования и права по доступу к информации.
3. Виды требований к программному обеспечению. Часть 2. (Курс бизнес-аналитик с нуля)
Г.2 Условия выполнения программы
Программное средство должно успешно запускаться на операционных системах семействаWindows (WindowsXP, Windows 7, Windows 8, Windows 10).Для успешного запуска клиентской части информационной системы и выполнения надлежащих функций, программное средство должно быть установлено на компьютерах со следующей конфигурацией:
— Intel Celeron CPU 1.70 GHz;
Для корректной работы программы необходимо установить MSExcel 2010 для вывода отчетов и .netFramework 4.5.
Г.3 Выполнение программы
После запуска информационной системы «Отдел кадров школы» откроется окно аутентификации пользователей, представленное на рисунке Г.1.
Рисунок Г.1 – Окно аутентификации пользователя
После успешного прохождения аутентификации, каждый из определенных типов пользователей, таких как администратор, завуч, секретарь или учитель переходит на главное окно системы. Главное окно администратора представлено на рисунке Г.2.
Рисунок Г.2 – Главное окно администратора
На главной форме администратора представлена таблица пользователей, со следующими полями: фамилия, имя, отчество, должность, логин и пароль. Должность пользователя выбирается из списка: администратор, учитель, завуч, секретарь и учитель. Администратор может добавлять, изменять и удалять данные из таблицы пользователей, также сохранять их.
Главное окно завуча представлено на рисунке Г.3.
Рисунок Г.3 – Главное окно звуча
На главной форме завуч может просматривать итоговые оценки по номеру класса и предмету. Завуч не может вносить изменения в таблицу с итоговой успеваемостью по классам и предметам.
Главное менюсекретаря представлено на рисунке Г.4.
Рисунок Г.4 – Главное меню секретаря
В главном меню секретаря расположены три кнопки: классы, нагрузка и предметы. Кнопка «Классы» предназначена для перехода на форму с учениками по классам школы. Кнопка «Нагрузка» предназначена для перехода на форму с нагрузкой на учителей, где указано какой предмет ведет каждый учитель у определенного класса. Кнопка «Предметы» предназначена для перехода на форму, где расположен список предметов изучаемых в школе.
При нажатии на кнопку «Классы» секретарь переходит на следующую форму формирования списка классов, представленную на рисунке Г.5.
Рисунок Г.5 – Формирование списка классов
На данной форме расположено две таблицы. Таблица, расположенная с левой стороны формы, предназначена для формирования списка классов. Добавление нового класса осуществляется путем нажатия на кнопку добавления, затем данные сохраняются в таблице. Для удаления класса необходимо выбрать класс из списка и нажать кнопку удалить.
Таблица, расположенная справа, предназначена для распределения учеников по классам, состоит из двух колонок: номер класса и фамилия, имя и отчество ученика. Номер класса выбирается из выпадающего списка. Секретарь может добавлять, редактировать и удалять записи по аналогии с первой таблицей, для сохранения изменений необходимо нажать на кнопку удалить.
При нажатии на кнопку «Нагрузка» секретарь переходит на следующую форму формирования списка нагрузки на учителей, представленную на рисунке Г.6.
Рисунок Г.6 – Формирование списка нагрузки
На данной форме расположена таблица с данными об учителе, предмете, который он ведет и классе. Данные в таблице выбираются из выпадающего списка. Секретарь может вносить изменения в таблицу нагрузки, а также добавлять и удалять данные. Для добавления данных необходимо нажать на кнопку добавить, в таблице появится новая строка, в этой строке выбрать необходимые данные и нажать на кнопку сохранить. Чтобы удалить данные о нагрузке, необходимо выделить строку из таблицы и нажать кнопку удалить.
При нажатии на кнопку «Предметы» секретарь переходит на следующую форму формирования списка школьных предметов, представленную на рисунке Г.7.
Рисунок Г.7 – Формирование списка предметов
На данной форме расположена таблица с названиями предметов. Секретарь может вносить изменения в предметов, а также добавлять и удалять данные. Для добавления данных необходимо нажать на кнопку добавить, в таблице появится новая строка, в этой строке выбрать необходимые данные и нажать на кнопку сохранить. Чтобы удалить данные о нагрузке, необходимо выделить строку из таблицы и нажать кнопку удалить.
Главное окно учителя представленную на рисунке Г.8.
Рисунок Г.8 – Главное окно учителя
На главной форме учителя расположена таблица с оценками учеников, состоящая из фамилии, имени и отчества ученика выпадающего из списка и оценки по предмету. Справа от таблицы расположены выпадающие списки, где можно выбрать период за который выставляется оценка, предмет по которому выставляется оценка и класс ученика. Далее выбирается ученик и выставляется оценка, данные заносятся в таблицу. Для добавления данных необходимо нажать на кнопку добавить, в таблице появится новая строка, в этой строке выбрать необходимые данные и нажать на кнопку сохранить. Чтобы удалить данные о нагрузке, необходимо выделить строку из таблицы и нажать кнопку удалить.
Г.4 Сообщение оператору
Информационная система «Учет успеваемости учащихся» при вводе некорректных или пустых значений выдает ошибки. Тексты сообщений об ошибке и их решения представлены в таблице Г.1.
Таблица Г.1 – Сообщения оператору
| № | Текст сообщения | Причина появления | Требуемые действия |
| 1 | 2 | 3 | 4 |
| 1 | Неверный логин или пароль | Неверно введен логин или пароль пользователя | 1) Ввести верный логин и пароль. 2) Если данные введены верно, обратитесь к системному администратору. |
| 2 | Встроке присутствуют недопустимые символы | Неверный формат данных. В строке присутствуют недопустимые символы. | 1) Ввести данные в соответствующую таблицу, изучив формат представления данных 2) Если данные введены верно, обратитесь к системному администратору. |
| 3 | Объект не найден | Указанный учитель не найден.. | 1) Если данные введены верно, обратитесь к системному администратору. 2) Если системный администратор не смог устранить проблему, обратитесь к разработчику. |
| 5 | Обязательное поле не заполнено | Поле для обязательного заполнения оставлено пустым. | 1) Ввести данные в незаполненные поля. 2) Если все поля заполнены, обратитесь к системному администратору. |
ПРИЛОЖЕНИЕ Д
(обязательное)
Описание программы
В.1 Общие сведения
Объектом описания является клиентская часть клиент-серверной информационной системы «Отдел кадров школы».
Для функционирования разработанной информационной системы необходимо, чтобы на станциибыла установлена операционная система семейства Windows (WindowsXP, Windows 7, Windows 8, Windows 10), а также MSExcel 2010 для вывода отчетов.
Для разработки данной информационной системы в качестве языка программирования был использован Delphi 7.
Для проектирования системы была использована среда разработкиMSVisualStudio 2015.
Последнее изменение этой страницы: 2018-04-12; просмотров: 262.
stydopedya.ru не претендует на авторское право материалов, которые вылажены, но предоставляет бесплатный доступ к ним. В случае нарушения авторского права или персональных данных напишите сюда.
Источник: stydopedya.ru
Требования к программе или программному изделию
4.1.1. Программа должна обеспечивать возможность выполнения следующих функций:
• получение информации об объекте инвентаризации;
• добавление нового объекта;
•создание новой метки;
•изменение информации об объекте.
4.1.2. Исходные данные:
•информация об объекте инвентаризации;
4.1.3. Организация входных и выходных данных:
Входные данные поступают с камеры.
Выходные данные отображаются на экране.
4.2. Требования к надежности
Предусмотреть контроль вводимой информации.
Предусмотреть блокировку некорректных действий пользователя при работе с системой.
4.3. Требования к составу и параметрам технических средств.
Система должна работать на IBM-совместимых персональных компьютерах, на телефонах androidвыше 4.2.2.
Минимальная конфигурация для ПК:
• тип процессора. Pentium II 400;
• объем оперативного запоминающего устройства 128 Мб;
• объем свободного места на жестком диске 60 Мб.
Минимальные конфигурация для Телефонов:
•тип процессора. 800-1000 МГц и выше.
•объем оперативно запоминающего устройства 500 Мб и выше.
4.4. Требования к программной совместимости.
Программа должна работать под управлением семейства операционных систем Win 32 (Windows ХР/7/8/10 и т. п.).
Требования к программной документации
5.1. Разрабатываемые программные модули должны быть самодокументированы, т. е. тексты программ должны содержать все необходимые комментарии.
5.2. Разрабатываемая программа должна включать справочную информацию о работе программы, описания методов сортировки и подсказки учащимся.
5.3. В состав сопровождающей документации должны входить:
5.3.1. Пояснительная записка на пяти листах, содержащая описание разработки.
5.3.2. Руководство пользователя.
Технико-экономические показатели
Эффективность системы определяется удобством использования системы для инвентаризации объектов и получение информации о нем, путем обработки видеоочков дополненной реальности.
Порядок контроля и приемки
После передачи Исполнителем отдельного функционального модуля программы Заказчику последний имеет право тестировать модуль в течение 7 дней. После тестирования Заказчик должен принять работу по данному этапу или в письменном виде изложить причину отказа принятия. В случае обоснованного отказа Исполнитель обязуется доработать модуль.
Министерство образования Российской Федерации
Уфимский Колледж Радиоэлектроники Телекоммуникаций и Безопасности
Кафедра программирования и информационных технологий
Источник: studopedia.ru
Как написать ТЗ, часть 1: ГОСТЫ и спецификации требований
Близнецы или тройняшки: ПО, информационная и автоматизированная системы – отличия и разные ГОСТ’ы
- программа (программное изделие). Российский ГОСТ 19781-90 «Обеспечение систем обработки информации программное» описывает это как данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определенного алгоритма.
- автоматизированная система (АС), которая согласно ГОСТ 34.003-90, состоит из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций. АС включает различные виды обеспечения: организационное, методическое, техническое, программное (ПО), информационное, лингвистическое, математическое, правовое, эргономическое.
Таким образом, программа или программное изделие – это часть АС. А термин «информационная система» трактуется согласно следующим определениям:
- совокупность информации, содержащейся в базах данных, информационных технологий и технических средств, которые обеспечивают её обработку [ФЗ РФ от 27.06.2006 г. № 149-ФЗ «Об информации, информационных технологиях и о защите информации», ГОСТ Р 50922-2006];
- автоматизированная система, результатом функционирования которой является представление выходной информации для последующего использования [ГОСТ РВ 51987].
Поэтому информационная система (ИС), которая помимо программного обеспечения, также включает техническую часть, например, носимые устройства так называемого интернета вещей (IoT) – «умные часы», компоненты комплекса «умный дом» и пр. – является АС. В России ТЗ на создание АС регламентирует ГОСТ 34.602-89, впервые введенный в 1990 году и переизданный в 2009 г.
С 1 января 2022 года ГОСТ 34.602-89 признан недействующим и заменен на ГОСТ 34.602-2020, что мы рассматриваем в новой статье.
А порядок построения и оформления ТЗ на разработку программы или программного изделия, которые не включает технического и других видов обеспечения, описывает ГОСТ 19.201-78, введенный в 1980 году и переизданный в 2010.
Рассмотрим, чем отличаются эти стандарты. ГОСТ 34.602-89 выделяет следующие разделы в ТЗ на создание АС:
По ГОСТ 19.201-78 в ТЗ на разработку программы должны быть следующие разделы:
- Введение
- Основания для разработки
- Назначение разработки
- Требования к программе или программному изделию
- Требования к программной документации
- Технико-экономические показатели (можно взять из ТЭО)
- Стадии и этапы разработки
- Порядок контроля и приемки
- Приложения
Оба стандарта допускают оформлять отдельные разделы ТЗ в виде приложений, вводить дополнительные, исключать или объединять подразделы в зависимости от особенностей и условий эксплуатации объекта разработки.
Однако, сегодня большинство разработчиков и аналитиков считают эти отечественные ГОСТ’ы морально устаревшими и все чаще вместо них для оформления требований к ИС используют шаблоны зарубежных стандартов: ISO IEEE 29148-2011 и IEEE 830-1998, которые регламентируют составление спецификаций требований к ПО. Преимущества этих шаблонов над российскими регламентами и практику их совместного использования рассмотрим далее.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
24 июля, 2023
Длительность обучения
12 ак.часов
Стоимость обучения
20 000 руб.
Стандарты ISO IEEE 29148-2011 и IEEE 830-1998: в чем разница и как их использовать для разработки ТЗ
SRS по IEEE 830-1998
IEEE 830-1998 – это рекомендуемая методика составления спецификаций требований к ПО (Software Requirements Specification). Она описывает критерии проверки качественно составленной SRS, ее части и шаблоны. Основными рекомендуемыми разделами SRS по IEEE 830-1998 являются следующие:
- Введение
- Назначение
- Область действия
- Определения, акронимы и сокращения
- Ссылки
- Краткий обзор
- Общее описание
- Взаимодействие продукта с другими продуктами и компонентами
- Функции продукта (краткое описание)
- Характеристики пользователя
- Ограничения
- Допущения и зависимости
- Детальные требования
- Требования к внешним интерфейсам
- Интерфейсы пользователя
- Интерфейсы аппаратного обеспечения
- Интерфейсы программного обеспечения
- Интерфейсы взаимодействия
- Функциональные требования
- Требования к производительности
- Проектные ограничения (и ссылки на стандарты)
- Нефункциональные требования (надежность, доступность, безопасность и пр.)
- Другие требования
- Приложения
- Алфавитный указатель
ТЗ по ГОСТ vs SRS по ISO IEEE 29148-2011
IEEE 830-1998 носит рекомендательный характер – не случайно в оригинале он называется Recommended Practice for Software Requirements Specifications и сегодня не так часто используется на практике, как международный стандарт по инженерии требований ISO IEEE 29148-2011, который обеспечивает единую трактовку процессов и продуктов для всей системы и ПО. По сути, этот стандарт заменяет IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998 и объединяет российские ГОСТ’ы 34.602-89 и ГОСТ 19.201-78. Он содержит два шаблона спецификации требований:
- System requirements specification (SyRS)– технические требования к системе и удобству взаимодействия человека с ней;
- Software requirements specification (SRS)– спецификация требований к ПО, включая программное изделие, программу или набору программ (продукт), которые выполняют определенные функции в конкретном окружении.
- требования стейкхолдеров;
- системные требования, которые описывают определение, поведение и свойства каждой функции системы, ограничения по реализации, технические и качественные метрики.
- Введение
- Цели
- Соглашения о терминах
- Предполагаемая аудитория и последовательность восприятия
- Масштаб проекта
- Ссылки на источники
- Общее описание
- Видение продукта
- Функциональность продукта
- Классы и характеристики пользователей
- Среда функционирования продукта (операционная среда)
- Рамки, ограничения, правила и стандарты
- Документация для пользователей
- Допущения и зависимости
- Функциональность системы
- Функциональный блок X (таких блоков может быть несколько)
- Описание и приоритет
- Причинно-следственные связи, алгоритмы (движение процессов, workflows)
- Функциональные требования
- Требования к внешним интерфейсам
- Интерфейсы пользователя (UX)
- Программные интерфейсы
- Интерфейсы оборудования
- Интерфейсы связи и коммуникации
- Нефункциональные требования
- Требования к производительности
- Требования к сохранности (данных)
- Требования к качеству программного обеспечения
- Требования к безопасности системы
- Требования на интеллектуальную собственность
- Прочее
- Приложение А: Глоссарий
- Приложение Б: Модели процессов и предметной области и другие диаграммы
- Приложение В: Список ключевых задач
Можно сказать, что все эти разделы дополняют и уточняют пункты, предусмотренные отечественными ГОСТ’ами. С практической точки зрения структура SRS по ISO IEEE 29148-2011 дает следующие преимущества по сравнению с ГОСТ 34.602-89 и ГОСТ 19.201-78:
- глубокий уровень детализации, в частности, подробное описание различных категорий пользователей, интерфейсов, разделение допущений и ограничений;
- разделение требований на функциональные и нефункциональные;
- рекомендации представлять функциональные требования в форме сценариев (вариантов) использования, т.н. use case, которые мы разбирали здесь;
- структурированный и детальный набор разных требований легко разделяется по итерациям гибкой разработки (Agile) через определение их приоритета и очередности реализации по релизам;
- тесная связь с бизнесом благодаря детальному описанию контекста, правил, процессов, организационной среды и других аспектов, описываемых в спецификации требований стейкхолдеров (StRS, Stakeholder requirements specification) в разделах «Видение» и «Общее описание»;
- наглядность трассировки требований разных уровней друг к другу, а также к бизнес-правилам и регламентирующим документам.
Недостатком SRS по ISO IEEE 29148-2011 можно назвать большой объем этого документа, что отражается в длительности и трудоемкости его разработки. Впрочем, несмотря на это и вышеотмеченные достоинства, хочется подчеркнуть, по сути SRS по ISO IEEE 29148-2011 не лучше и не хуже отечественных ГОСТ’ов. В любом случае, не зависимо от выбранного шаблона ТЗ на создание ИС, АС или ПО, этот документ должен отражать функциональные и нефункциональные требования к объекту разработки так, чтобы их можно было реализовать и проверить, что решение соответствует целям бизнеса и приносит стейкхолдерам пользу. Про ограничения, допущения и зависимости читайте здесь. В следующей статье мы продолжим разговор про разработку ТЗ, а пока предлагаем вам пройти открытый интерактивный тест на проверку знаний о стандартах и требованиях из этого материала.
Источник: babok-school.ru