Меню
Главная
Авторизация/Регистрация
 
Главная arrow Информатика arrow Архитектура и проектирование программных систем

Уровни требований к программным системам

Можно выделить следующие уровни требований к ПС [20]: бизнес-требования, требования пользователей, функциональные и нефункциональные требования. К этому нужно еще добавить системные требования. Модель на рис. 4.3 иллюстрирует способ представления этих типов требований. Как и все модели, она не полная, но схематично показывает организацию требований. Овалы обозначают типы информации для требований, а прямоугольники - способ хранения информации (документы, диаграммы).

Бизнес-требования содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансирует проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга и т.п. В документе об образе и границах проекта объясняется, почему организации нужна такая система, т.е. описаны бизнес-цели, которые организация намерена достичь с ее помощью. Определение границ проекта представляет собой первый этап управления общими проблемами расползания границ.

Требования пользователей описывают цели и задачи, которые пользователям позволит решить система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие - отклик». В документе о вариантах использования указано, что клиенты смогут делать с помощью системы. Кто бы и когда бы ни предложил новые характеристики, варианты использования или функциональные требования, аналитик должен спросить: «Они попадают в указанные границы?» Если ответ «Да», то они соответствуют спецификациям. Если «Нет», то их и учитывать не надо. А если ответ такой: «Нет, но они должны там быть», то заказчик или тот, кто финансирует проект, должен решить, готов ли он раздвинуть границы проекта, чтобы принять новые требования.

Функциональные требования определяют функциональность программной системы, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Последние иногда именуют требованиями поведения, они содержат положения с традиционным «должен» или «должна». Например, «система должна по электронной почте отправлять пользователю подтверждение о заказе».

Системные требования обозначают высокоуровневые требования к продукту, который содержит многие подсистемы, т.е. к системе. Система - это совокупность программного обеспечения или подсистем ПО и оборудования. Люди - часть системы, поэтому определенные функции системы могут распространяться и на них.

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

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

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

Хотя в модели на рисунке показан поток требований в направлении сверху вниз, следует ожидать и циклов, и итераций между бизнес-требованиями, требованиями пользователей и функциональными требованиями.

В определении и управлении требованиями существует много проблем, связанных с трудностью получения правильных и законченных требований до окончательного выпуска программного продукта [4]. Во многих исследованиях отмечена корреляция проблем, возникающих с требованиями, с высоким процентом неудачных завершений ИТ-про-ектов. Более того, в некоторых работах указывается, что от 60 до 70% ИТ-проектов завершаются неудачей из-за слишком плохого сбора, анализа и управления требованиями. Отсутствие четко определенных и актуальных требований является наиболее веской причиной этих неудач.

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

По данным исследовательской организации Standish Group, наибольшее количество ошибок происходит на этапе сбора, анализа и документирования требований. Доля ошибок в различных артефактах при разработке программных систем представлена на рис. 4.5 [4]. Вследствие ошибок на разных этапах разработки программных систем приходится затрачивать 30-50% средств общего бюджета проекта на их исправление. Причем 70-85% общего числа исправлений связано именно с ошибками, допущенными на этапе сбора, анализа и документирования требований.

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

0% 10% 20% 30% 40% 50% 60% 70%

Рис. 4.4. Причины неудачной разработки программной системы

Процент редко выполняемого кода.

Процент кода, который был написан, но никогда не выполнялся.

Повышение прибыли из-за сокращения времени выхода на рынок на один месяц.

Процент потерь валовой прибыли, если компания промедлила на 6 месяцев с выход на рынок нового продукта.

Общие трудозатраты на проект разработки ПО, вызванные необходимостью переделки.

Неудачное завершение ИТ-проекта как результат плохого сбора, анализа и управления требованиями.

  • 1 — Требования
  • 2 Проектирование
  • 3 - Интерфейс
  • 4 — Данные 5-ПО
  • 6 - Человек
  • 7 - Документация
  • 8 - Другие

Рис. 4.5. Доля ошибок в различных артефактах при разработке

программных систем

 
Если Вы заметили ошибку в тексте выделите слово и нажмите Shift + Enter
< Пред   СОДЕРЖАНИЕ   След >
 

Популярные страницы