Практикум 1: Учебный проект: "Разработка ис предприятия оптовой торговли лекарственными препаратами"

Процесс включает в себя следующие этапы:

1. 
   Достижение соглашения об определении проблемы
   
2. 
   Выделение основных причин
   
3. 
   Выявление заинтересованных лиц и пользователей
   
4. 
   Определение границ системы, предлагаемой в качестве решения
   
5. 
   Выявление ограничений.
   

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

Выявление потребностей сопряжено с выполнением следующих задач:

• 
  интервьюирование и анкетирование;
  
• 
  совещания, посвященные требованиям;
  
• 
  мозговой штурм;
  
• 
  применение "раскадровок";
  
• 
  анализ прецедентов;
  
• 
  обыгрывание ролей;
  
• 
  создание прототипов.
  

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

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

Управление масштабом проекта

Управление масштабом проекта осуществляется с целью выявления реальных рамок проекта. При этом решаются следующие основные задачи:

• 
  Оценка приоритетов требований.
  
• 
  Оценка трудоёмкости выполнения требований.
  
• 
  Оценка рисков.
  

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

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

Требования в области решений делятся на две группы: функциональные требования и нефункциональные.

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

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

В процессе создания системы осуществляются два вида контроля её правильности: верификация и валидация.

Как минимум, подлежит верификации:

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