Вопросы разработки задания на ВКР в соответствии с ГОСТ (Тонких Артём Петрович)

1. Классификация требований к программному обеспечению Вопросы разработки задания на ВКР в соответствии с ГОСТ

Тонких Артём Петрович

2. Определение понятия требования

ISO/IEC/IEEE 29148:2011 Программная и системная инженерия. Процессы жизненного
цикла. Разработка требований
«Требование – утверждение, которое идентифицирует эксплуатационные,
функциональные параметры, характеристики и ограничения
проектирования продукта или процесса, а также является однозначным,
проверяемым и измеримым»
Rational Unified Process (RUP), Version 2003.06.13
«Условие или возможность, которой должна удовлетворять система»
IEEE Std 610.12, «IEEE Standard Glossary of Software Engineering Terminology»
«Условия или возможности, необходимые пользователю для решения
проблем или достижения целей;
Условия или возможности, которыми должна обладать система или
системные компоненты, чтобы выполнить контракт или удовлетворять
стандартам, спецификациям или другим формальным документам;
Документированное представление условий или возможностей для
пунктов 1 и 2.»
2

3. Требования являются базой для

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

4. Дискретность требований

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

5. Способы организации представления и группировки требований

5

6. Группировка требований по SWEBOK

Требования к продукту и процессу – параметры относящиеся
к продукту или процессу его создания.
Функциональные и нефункциональные требования:
Функциональные описывают функции, которые выполняет ПО;
Нефункциональные требования накладывают определенные ограничения.
Независимые свойства – требования, которые не могут быть
адресованы к одной из компонент системы, в проявляются при
взаимодействии.
Количественные требования – требования, поддающиеся
количественному определению/измерению, например, система
должна обеспечить пропускную способность «столько-то
запросов в секунду».
Системные и программные требования – относятся к
системе в целом или к программной составляющей.
6

7. Группировка требований по К. Вигерсу

Функциональные
требования
Бизнес-требования
Пользовательские
требования
Нефункциональные
требования
Бизнес-требования
Бизнес-правила
Пользовательские
требования
Атрибуты качества
Функциональные
требования
Системные
требования
Функциональные
требования
Внешние интерфейсы
Ограничения
7

8. Уровни требований по К. Вигерсу

Бизнес-требования определяют высокоуровневые цели
организации или заказчика (потребителя) разрабатываемого ПО.
Постановка задачи и описание назначения ПО. (Ответ на вопрос
ПОЧЕМУ?)
Пользовательские требования описывают цели\задачи
пользователей системы, которые должны выполняться
пользователями при помощи создаваемой системы, варианты
использования. (Ответ на вопросы КТО? и ЧТО?)
Функциональные требования определяют функциональность
(поведение) программной системы, которая должна быть
создана разработчиками для предоставления возможности
выполнения пользователями своих обязанностей в рамках
бизнес-требований и в контексте пользовательских требований
(Ответ на вопрос ЧТО?)
8

9. Другие типы требований по К. Вигерсу

Нефункциональные требования включают эксплуатационные
характеристики и описание атрибутов качества.
o
o
o
o
Бизнес-правила включают корпоративную политику, законодательные акты,
стандарты, учетную практику и алгоритмы вычислений.
Атрибуты качества –дополнительные характеристики продукта, важные для
пользователей и/или разработчиков. Эти характеристики включают практичность,
целостность, эффективность, устойчивость.
Ограничения – условия, ограничивающие выбор возможных решений по
реализации отдельных требований или их выбора (платформы, протоколы и т.д.).
Внешние интерфейсы – требования, которые содержат конкретизацию аспектов
взаимодействия разрабатываемого ПО с другими системами (операционной
средой, аппаратным оборудованием, пользователями и др.)
Системные требования классифицируются как составная часть
группы функциональных требований и описывают высокоуровневые
требования к ПО, при этом система может состоять из программной
и аппаратной частей, персонала.
9

10. Требования в RUP

Методология RUP выделяет отдельную дисциплину
Requirements, которая объединяет работы, роли и артефакты
(документы, модели и пр.), связанные с созданием требований к
ПО и управления ими.
Д. Лефингвелл представил обобщенную классификационную
схему – структуру требований, которая отражает
рекомендованный RUP подход
10

11. Схема Д. Лефингвелла. Уровни требований

Потребность (Need) – отражение
проблемы бизнеса, персоналии или
процесса, которое должно быть
соотнесено с использованием или
приобретением новой системы.
Характеристика продукта (Feature) –
множество логически связанных
функциональных требований, которые
обеспечивают возможности
пользователя и удовлетворяют бизнесцелям.
Требования к ПО (Software
Requirements)
11

12. Детализация Software Requirements

Функциональные требования выражают поведение системы –
входы, выходы и функции, которые система предоставляет
пользователю, без учета физических ограничений.
Нефункциональные требования
Usability (Удобство использования);
Reliability (Надежность);
Performance (Производительность);
Supprtability (Поддержка).
Ограничения проектирования – ограничения, относящиеся к
дизайну или процессу создания системы, которые не влияют на
внешнее поведение, но должны быть учтены для соответствия
различного вида обязательствам
12

13. Модель FURPS+

Требования могут быть категоризированы по модели FURPS+,
которая описывает основные категории требований с
подкатегориями:
Functionality (Функциональность);
Usability (Удобство использования);
Reliability (Надежность);
Performance (Производительность);
Supprtability (Поддержка).
«+» в FURPS+ говорит о включении дополнительных категорий:
desing constraints (ограничения проектирования);
Implementation requirements (требования к реализации);
Interface requirements (требования к интерфейсам);
fhysical requirements (требования к физическим характеристикам)
13

14. Представление требований в IEEE 830-1998

Стандарт IEEE 830-1998 описывает рекомендуемые способы
спецификации требований к программному обеспечению.
Результатом процесса спецификации требований является
однозначно интерпретируемый и целостный документспецификация требований.
Стандарт на документальное оформление требований задает
определенные группировки одинаковых по своей сути
требований (по их назначению), фиксируя классификацию
требований.
14

15. Спецификация программных требований в IEEE 830 (SRS)

Функциональность. Ответ на вопрос «ЧТО должно делать ПО?»
Внешние интерфейсы. Как ПО должно взаимодействовать с
людьми, другими ПО или аппаратурой.
Производительность. С какой скоростью должны производиться
те или иные операции, каково время отклика и т.п.
Атрибуты. Определяют точность, переносимость,
модифицируемость и т.п.
Ограничения проектирования. Использование определенных
языков программирования, баз данных, форматов обмена и т.п.
15

16. Документирование требований в соответствии с ГОСТ

ГОСТ 34.601-90. Информационная технология. Комплекс
стандартов на автоматизированные системы.
Автоматизированные системы. Стадии создания.
ГОСТ 34.602-89. Информационная технология. Комплекс
стандартов на автоматизированные системы. Техническое
задание на создание автоматизированной системы
ГОСТ 19.201-78. Единая система программной
документации. Техническое задание. Требования к
содержанию и оформлению.
16

17. ГОСТ 34.602-89

Регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в
которую входят программное и аппаратное обеспечение, люди,
которые работают с ПО, и автоматизируемые процессы.
Согласно ГОСТ 34.602-89 Техническое задание на создание АС
техническое задание включает следующие разделы:
При разработке ТЗ для государственных проектов Заказчики, как
правило, требуют соблюдение именно этого стандарта.
17

18. Требования к системе в целом

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

19. Требования к системе в целом

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

20. Требования к системе в целом

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

21. Требования к системе в целом

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

22. Требования ГОСТ к функциям (задачам)

функциональные требования в привязке к подсистемам и
очередям автоматизации;
временной регламент реализации функциональных требований;
требования к качеству реализации каждого из функциональных
требований (форма представления выходной информации,
характеристики необходимой точности и времени выполнения,
требования одновременности выполнения группы функций,
достоверности выдачи результатов);
перечень и критерии отказов для каждого функционального
требования, по которому были заданы требования по надежности.
22

23. Требования к видам обеспечения

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

24. Требования к видам обеспечения

Лингвистическое обеспечение:
требования к применению в системе языков программирования высокого
уровня, языков взаимодействия пользователей и технических средств
системы;
требования к кодированию и декодированию данных, к языкам ввода-вывода
данных, языкам манипулирования данными, средствам описания предметной
области (объекта автоматизации), к способам организации диалога.
Программное обеспечение:
требования к независимости программных средств от используемых средств
вычислительной техники и операционной среды;
требования к качеству программных средств, а также к способам его
обеспечения и контроля.
24

25. Требования к видам обеспечения

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

26. Требования к видам обеспечения

Организационное обеспечение:
к структуре и функциям подразделений, участвующих в функционировании
системы или обеспечивающих эксплуатацию;
к организации функционирования системы и порядку взаимодействия
персонала АС и персонала объекта автоматизации;
к защите от ошибочных действий персонала системы.
Методическое обеспечение:
требования к составу нормативно-технической документации системы
(перечень применяемых при ее функционировании стандартов, нормативов,
методик и т. п.).
26

27. Соотнесение типов требований по Вигерсу и ГОСТ 34.602

27

28. ГОСТ 19.201-78

Единая система программной документации (ЕСПД) – это
комплекс государственных стандартов, устанавливающих
взаимоувязанные правила разработки, оформления и обращения
программ (или ПО) и программной документации.
Согласно ГОСТ 19.201-78 Техническое задание. Требования к
содержанию и оформлению техническое задание включает
следующие разделы:
1. Введение.
2. Основания для разработки.
3. Назначение разработки.
4. Требования к программе или программному изделию.
5. Требования к программной документации.
6. Технико-экономические показатели.
7. Стадии и этапы разработки.
8. Порядок контроля и приемки.
9. Приложения.
Этот стандарт относится к разработке именно ПО.
28

29. Требования к программе или программному изделию

Требования к функциональным характеристикам;
Требования к надежности;
Требования к условиям эксплуатации;
Требования к составу и параметрам технических средств;
Требования к информационной и программной совместимости;
Требования к маркировке и упаковке;
Требования к транспортированию и хранению;
Специальные требования.
29

30. Вопросы разработки задания на ВКР в соответствии с ГОСТ

30

31. Примеры формулировок задания на ВКР

Требования к структуре и функционированию системы
АИС должна иметь трехуровневую архитектуру. АИС должна быть
централизованной.
В АИС предлагается выделить следующие функциональные подсистемы:
подсистема сбора, обработки и загрузки данных;
подсистема хранения данных;
подсистема формирования и визуализации отчетности.
Информационный обмен между подсистемами должен осуществляться через
единое информационное пространство и посредством использования
стандартизированных протоколов и форматов обмена данными.
Все компоненты подсистем АСУ должны функционировать в пределах единого
логического пространства, обеспеченного интегрированными средствами
серверов данных и серверов приложений.
В АИС должна обеспечиваться работа в двух режимах:
сетевой режим взаимодействия;
автономный;
Работа пользователей в режиме 24 часа в день, 7 дней в неделю (24х7).
31

32. Примеры формулировок задания на ВКР

Требования к численности и квалификации персонала
системы
Для эксплуатации АИС определены следующие роли: администратор,
пользователь, техник.
Требования к надежности
Время восстановления работоспособности прикладного ПО АИС при любых
сбоях и отказах не должно превышать одного рабочего дня, исключая случаи
неисправности серверного оборудования.
В АИС должна быть обеспечена возможность восстановления данных с
внешнего накопителя после восстановления активного накопителя.
Должно осуществляться разграничение прав доступа к системе.
Должен вестись журнал событий системы.
32

33. Примеры формулировок задания на ВКР

Требования к эргономике и технической эстетике
В части внешнего оформления:
реализация графического многооконного режима;
настраиваемость графических элементов интерфейса, в том числе цветового
оформления, в пределах возможностей операционной системы;
интерфейсы подсистем должен быть типизированы;
в шапке отчетов должен использоваться логотип Заказчика.
В части диалога с пользователем:
интерфейс должен обеспечивать удобную навигацию в диалоге с пользователем;
наличие контекстно-зависимой помощи.
для наиболее частых операций должны быть предусмотрены «горячие» клавиши;
при возникновении ошибок в работе подсистемы на экран монитора должно
выводиться сообщение с наименованием ошибки и с рекомендациями по её
устранению на русском языке.
В части операций ввода-вывода данных:
ввод-вывод данных системы должен выполняться в интерактивном режиме
33

34. Примеры формулировок задания на ВКР

Требования к защите информации от несанкционированного
доступа
Аутентификация пользователей;
Проверка полномочий пользователя при работе с системой;
Разграничение прав доступа пользователей на уровне задач и информационных
массивов, должно строиться по принципу «что не разрешено, то запрещено»;
Ограничение на доступ пользователей к выполнению функций системы
(заполнение документов, получение отчетов и др.);
Протоколирование действий пользователей, связанных с информационной
безопасностью (вход в систему, выход из нее, открытие и редактирование
документов и пр.).
34

35. Примеры формулировок задания на ВКР

Требования по сохранности информации при авариях
Программное обеспечение АИС должно восстанавливать свое функционирование
при корректном перезапуске аппаратных средств;
В АИС должно быть обеспечено резервное копирование данных.
Выход из строя жестких дисков дискового массива не должен сказываться на
работоспособности подсистемы хранения данных.
Для восстановления данных и программного обеспечения из резервной копии
должны использоваться средства резервного копирования и архивирования.
Должна быть предусмотрена возможность восстановления данных за день сбоя с
помощью их повторного ввода или импорта (для данных из внешних систем,
получаемых автоматически).
35

36. Примеры формулировок задания на ВКР

Требования по стандартизации и унификации
Разработка системы должна осуществляться с использованием стандартных
методологий функционального моделирования: IDEF0, DFD и
информационного моделирования IE и IDEF1Х в рамках рекомендаций по
стандартизации Р50.1.028-2001 «Информационные технологии поддержки
жизненного цикла продукции. Методология функционального моделирования».
Моделирование должно выполняться в рамках стандартов, поддерживаемых
программными средствами моделирования ERWin 4.х и BPWin 4.х.
Для работы с БД должен использоваться язык запросов SQL в рамках
стандарта ANSI SQL-92.
Для взаимодействия пользователей и прикладным ПО должно осуществляться
посредством визуального графического интерфейса (GUI)
Все экранные формы графического интерфейса должны быть выполнены в
едином графическом дизайне, с одинаковым расположением основных
элементов управления и навигации.
36

37. Примеры формулировок задания на ВКР

Требования к функциям системы и ее подсистем
Подсистема сбора, обработки и загрузки данных должна осуществлять:
Ввод и редактирование информации с помощью экранных форм;
Обработку и преобразование извлечённых данных;
Поиск данных по наименованию документа, времени создания.
Подсистема хранения данных должна осуществлять:
Хранение оперативных данных системы, данных для формирования аналитических
отчетов, документов, справочников.
Система должна обеспечивать периодическое резервное копирование и сохранение
данных на дополнительных носителях информации.
Подсистема формирования и визуализации отчетности
Система должна иметь возможность вызова списка отчетов или конкретного
аналитического отчета с заранее установленными параметрами.
Время формирования отчета на Web-интерфейсе не должно превышать 30 секунд.
Размеры элементов интерактивных аналитических отчетов должны адаптироваться
к разрешению экрана устройства, на котором просматривается отчет.
37

38. Примеры формулировок задания на ВКР

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

39. Примеры формулировок задания на ВКР

Требования к лингвистическому обеспечению
Все обозначения, названия элементов управления АИС, тексты должны быть
изложены на русском языке без применения терминов, непонятных
пользователю.
Разработка системы должна вестись на языке программирования высокого
уровня PHP.
Требования к программному обеспечению
Системные программные средства свободно распространяемая операционная
система FreeBSD или Linux.
Программное обеспечение, распространяемое свободно:
База данных (СУБД) PostgreSQL или MySQL;
Apache HTTP Server версии 2.2.16 (или выше);
PHP версии 5.1 (или выше);
Система управления контентом с открытым кодом.
39

40. Примеры формулировок задания на ВКР

Требования к техническому обеспечению
Тип процессора: процессор типа Pentium IV (или эквивалент);
Базовая тактовая частота процессора: минимум: 1,6 ГГц;
Оперативная память: минимум: 256 МБ;
Дисковое пространство: минимум: 5 ГБ;
Операционная система: Windows XP или более поздних версий.
Браузеры, один из: Internet Explorer версии 9 или более поздней, Mozilla Firefox
версии 5 или более поздней, Google Chrome версии 13 или более поздней
Внутренняя сеть и средства коммуникации должны обладать как минимум
следующими характеристиками:
скорость передачи данных подключаемого канала к публичным сетям не менее 2
Мб/с;
оборудование узла должно оставаться работоспособным при кратковременных
отключениях электропитания (на время не менее 15 минут);
оборудование узла должно обеспечивать коммутируемое подключение всех
устройств со скоростью до 100 Мбит/с.
40

41. Список используемых источников

Маглинец Ю.А. Анализ требований к автоматизированным
информационным системам [Электронный ресурс] : [учебное
пособие] / Ю. А. Маглинец. - 2-е изд., испр. - Москва : ИНТУИТ,
2016. - 192 с. : ил. - (Основы информационных технологий). ISBN 978-5-94774-865-9.
Булуй Ю. И. Введение в программную инженерию и управление
жизненным циклом ПО. Программная инженерия. Программные
требования [Электронный ресурс] : Русский перевод SWEBOK
2004 с замечаниями и комментариями / Ю. И. Булуй, С. В.
Орлик. – Электрон. дан. – Москва, 2004-2005. – Режим
доступа : http://booksee.org/book/523016
Вигерс, Карл. Разработка требований к программному
обеспечению. Пер. с англ. – Москва : Издательско-торговый дом
«Русская Редакция», 2004. – 576с. : ил.
41