Условия или возможности, которыми должна обладать система или

Условия или возможности, необходимые пользователю для решения проблем или достижения целей;

Слайд

Слайд

Таблица 1.1 Причины провалов проектов

• Неполнота требований 13.1%

• Недостаточное привлечение пользователей 12.4%

Недостаток в ресурсах 10.6%

• Нереалистические ожидания 9.9%

Недостаток поддержки от руководства 9.3%

Изменение требований/спецификаций 8.7%

Недостаточное планирование 8.1%

Потеря необходимости 7.5%

Перечисленные проблемы можно разделить на три основных категории:

• Требования – плохо организованы, плохо написаны; слабо связаны с запросами и потребностями заинтересованных сторон (stakeholders); очень быстро изменяются, или изменяются без необходимости; нереалистические ожидания.

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

• Искусство управления – выражается во влиянии на первые две категории.

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

С точки зрения разработчиков проблемная область достаточно туманна, поэтому ее принято изображать в виде облака. Из этого облака проблем выявляются потребности в программном продукте.

Анализ проблемы — это процесс осознания реальных проблем и потребностей пользователя и предложения решений для удовлетворения этих потребностей.

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

Формулировка потребностей может быть разбита на следующие этапы:

1. Выделение 1-2-3 основных проблемы;

2. Определение причин возникновения проблем, оценить степень их влияния и выделить наиболее существенные из проблем, влекущие появление остальных;

3. Определить ограничения на возможные решения.

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

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

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

IEEE Standard Glossary of Software Engineering Terminology (1990) определяет требования как:

системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;

Дата добавления: 2014-01-20