ПЗ-4_Проектный_практикум. Занятие 4 Разработка требований к информационной системе

• Название: Занятие 4 Разработка требований к информационной системе
• Дата: 29.03.2022
• Размер: 73 Kb.
• Имя файла: ПЗ-4_Проектный_практикум .doc
• Тип: Занятие; #426563

Практическое занятие 4

Разработка требований к информационной системе

Цель работы: составить и проанализировать требования к информационной системе.

Порядок выполнения работы

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

Примечание.

На стадии «Формирование требований к ИС» разрабатывают отчет по ГОСТ 7.32 и заявку на разработку ИС согласно ГОСТ Р 59795-2021 Приложение А.

Диаграмма вариантов использования

Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования.

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

Вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой.

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

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

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

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

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



Рисунок 1 – Пример фрагметнт диаграммы вариантов использования

3. 
   Составить системные требования, которые должны включать:
   

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

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

• 
  Требования по взаимодействию и интеграции с другими системами. Например, использование общей базы данных, возможность получения данных из баз данных определённых систем и т.д.
  

4. 
   Подготовить отчет по работе.