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

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. Способы организации представления и группировки требований

6

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

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

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

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

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

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

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

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

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

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

12. Схема Тонких Артёма Петровича. Уровни требований

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

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

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

14. Модель FURPS+

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

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

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

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

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

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

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

18. Компоненты информационных систем

18

19. ГОСТ 34.602-89

ГОСТ 34.602-89. Информационная
технология. Комплекс стандартов на
автоматизированные системы.
Техническое задание на создание
автоматизированной системы

20. ГОСТ 34.602-89

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

21. 2.6. Раздел "Требования к системе" состоит из следующих подразделов:

2.6. Раздел "Требования к системе"
состоит из следующих подразделов:
1) требования к системе в целом;
2) требования к функциям (задачам),
выполняемым системой;
3) требования к видам обеспечения.

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

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

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

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

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

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

требования к структуре и функционированию
системы

26.

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

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

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

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

требования к надежности

29.

1) состав и количественные значения показателей
надёжности для системы в целом или ее
подсистем;
2) перечень аварийных ситуаций, по которым должны
быть регламентированы требования к надежности,
и значения соответствующих показателей;
3) требования к надёжности технических средств и
программного обеспечения;
4) требования к методам оценки и контроля
показателей надёжности на разных стадиях
создания системы в соответствии с действующими
нормативно-техническими документами

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

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

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

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

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

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

33. Требования к функциям (задачам), выполняемым системой

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

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

35. Функциональные требования

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

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

37. Виды обеспечения

Математическое
Информационное
Лингвистическое
Программное
Техническое
Метрологическое
Организационное
Методическое
Иное

38. Математическое обеспечение. Требования

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

39. Информационное обеспечение Требования

1)
к составу, структуре и способам организации данных в системе;
2)
к информационному обмену между компонентами системы;
3)
к информационной совместимости со смежными системами;
4)
по использованию общесоюзных и зарегистрированных
республиканских, отраслевых классификаторов, унифицированных
документов и классификаторов, действующих на данном предприятии;
5)
по применению систем управления базами данных;
6)
к структуре процесса сбора, обработки, передачи данных в системе
и представлению данных;
7)
к защите данных от разрушений при авариях и сбоях в электропитании
системы;
8)
к контролю, хранению, обновлению и восстановлению данных;
9)
к процедуре придания юридической силы документам,
продуцируемым техническими средствами АС (в соответствии с ГОСТ
6.10.4).

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

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

41. Лингвистическое обеспечение. Требования

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

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

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

43. Программное обеспечение. Требования

1) к независимости программных средств от
используемых СВТ и операционной среды;
2) к качеству программных средств, а также к
способам его обеспечения и контроля;
ТЕСТИРОВАНИЕ
3) по необходимости согласования вновь
разрабатываемых программных средств с фондом
алгоритмов и программ.

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

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

45. Организационное обеспечение. Требования

1) к структуре и функциям подразделений,
участвующих в функционировании системы или
обеспечивающих эксплуатацию;
2) к организации функционирования системы и
порядку взаимодействия персонала АС и
персонала объекта автоматизации;
3) к защите от ошибочных действий персонала
системы

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

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

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

47

48. ГОСТ 19.201-78

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

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

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

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

50

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тонких Артём Петрович. Анализ требований к
автоматизированным информационным системам
[Электронный ресурс] : [учебное пособие] / Артём Петрович
Тонких. - 2-е изд., испр. - Москва : ИНТУИТ, 2016. - 192 с. : ил. (Основы информационных технологий).
Тонких Артём Петрович. Введение в программную инженерию и
управление жизненным циклом ПО. Программная инженерия.
Программные требования [Электронный ресурс] : Русский
перевод SWEBOK 2004 с замечаниями и комментариями /
Артём Петрович Тонких. – Электрон. дан. – Москва, 20042005.
Тонких Артём Петрович. Разработка требований к
программному обеспечению. Пер. с англ. – Москва :
Издательско-торговый дом «Русская Редакция», 2004. – 576с. :
ил.
61

62. Диаграмма потоков данных - DFD

62

63. Пример несовпадения временной последовательности работ и направления движения документа

63

64. Пример бизнес-процессов верхнего уровня

64

65. Дерево бизнес-процессов

65

66. Сеть бизнес-процессов

66

67. Диаграмма потоков работ - WFD

67