Наиболее распространенные проблемы, из-за которых «проваливаются» проекты отнюдь не технические. В таблице 1 приводятся основные причины провалов проектов. Таблица заполнена на основании данных опроса, проведенного Стэндиш Групп (Standish Group) в 1995-96 годах, и показывает процентное соотношение причин, приведших к «смерти» проектов. Точками отмечены причины связанные непосредственно с требованиями.

Слайд

Таблица 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) определяет требования как:

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

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

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

3. документированное представление условий или возможностей для

пунктов 1 и 2.

Requirement – требование, условие или возможности, необходимые для решения задания, достижения цели или соответствия стандарту, контракту, спецификации (спрос, потребность).

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

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

Модель процесса определения требований - это схема процессов ЖЦ, которые выполняются от начала проекта и до тех пор, пока не будут определены и согласованы требования.

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

Качество и процесс улучшения требований - это процесс проверки характеристик и атрибутов качества (надежность, реактивность и др.), которыми должна обладать система и ПО, методы их достижения на процессах ЖЦ.

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

Основные задачи управления требованиями это:

• разработка атрибутов требований,

• управление вариантами требований,

• управление рисками, возникающими при неточном определении требований,

• контроль статуса требований, измерение усилий при формировании требований;

• реализация требований на этапах ЖЦ.

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

Управление требованиями (Requirements management) Комплекс мероприятий, направленных на поддержание жизнеспособности спецификации требований. Необходимость управления требованиями продиктована тем, что в процессе работы над проектом требования могут уточняться и меняться. Иными словами, это систематический подход к получению, огранизации и документированию требований и процесс, который устанавливает и поддерживает соглашение между заинтересованными лицами.

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

Виды требований:

Бизне-требования - определяют назначение ПО в документах о видении и границах проекта.

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

Требования пользователей (user requirements) описывают цели и задачи, которые пользователям позволит решить система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.

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

Термином системные требования (system requirements) обозначают высокоуровневые требования к продукту, которые содержат многие подсистемы, то есть система (IEEE, 1998с). Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространяться и на людей.

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

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

Источники требований

• Законодательство (конституция, законы, распоряжения)

• Нормативное обеспечение организации (регламенты, положения, уставы, приказы)

• Текущая организация деятельности объекта автоматизации

• Модели деятельности (диаграммы бизнес-процессов)

• Представления и ожидания потребителей и пользователей системы

• Журналы использования существующих программно-аппаратных систем

• Конкурирующие программные продукты

Параметры качества требования

Полнота

Каждое требование должно полно описывать функциональность, которую следует реализовать в продукте. То есть оно должно содержать всю информацию, необходимую для разработчиков, чтобы им удалось создать этот фрагмент функциональности. Если вы понимаете, что данных определенного рода не хватает, используйте пометку «TBD» (to be determined — необходимо определить) на полях как стандартный флаг для выделения такого места. Восполните все пробелы в каждом фрагменте требований, прежде чем приступать к конструированию этой функции.

Корректность

Каждое требование должно точно описывать желаемую функциональность. Для соблюдения корректности необходима связь с источниками требований, например с пожеланиями пользователей или высокоуровневыми системными. Требования к ПО, которые конфликтуют с родительскими требованиями, нельзя считать корректными. Однако основная оценка здесь— за представителями пользователей, вот почему им или их непосредственным заместителям необходимо предоставлять требования для просмотра.

Осуществимость

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

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

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

Необходимость

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

Назначение приоритетов

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

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

Недвусмысленность

Все читатели требований должны интерпретировать их одинаково, но естественный язык зачастую грешит многозначностью. Пишите документацию просто, кратко и точно, применяя лексику, понятную пользователям. «Ясность»— цель качества требований, связанная с точностью: читатели должны четко понимать каждое положение. Занесите

все специальные и запутанные термины в словарь.

Проверяемость

Реализованость требований может быть определена через один из четырех возможных методов: осмотр, демонстрация, тест или анализ

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

Фаза разработки требований может быть разбита на:

- выявление требований (сбор, понимание, рассмотрение, и выяснение потребностей заинтересованных лиц);

- анализ (проверка целостности, законченности);

- спецификация (документирование требований);

- проверка правильности.

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

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

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

1. Огляд стандартних процесів життєвого циклу програмного забезпечення у контексті вимог.

2. Відношення цих процесів до інших процесів розробки та супроводження програмного забезпечення.

3. Процеси вивчення концепції – ідентифікація ідей та потреб замовника, формулювання потенційних підходів, вивчення здійсненності, оформлення ідей та потреб.

4. Загальний зміст декларації ідей та потреб замовника.

В основі діяльності по створенню та використанню ПЗ лежить поняття його ЖЦ. ЖЦ являєтся моделлю створення та використання ПЗ, що відображає його різноманітні стани, починаючи з моменту виникнення необхідності в даному програмному забезпеченні і закінчуючи моментом його повного виходу із вживання всіх користувачів.

Традиційно виділяють наступні основні етапи ЖЦ ПЗ:

• Аналіз вимог;

• Проектування;

• Кодування (программирование);

• Тестування і відладка;

• Експлуатація і супроводження.

ЖЦ, як правило, носить ітераційний характер: реалізовані етапи, починаючи з самих ранніх, циклічно повторюються у відповідності зі змінами вимог і зовнішніми умовами, введенням обмежень і т.д. На кожному етапі ЖЦ породжується визначений набір документів і технічних рішень, при цьому для кожного етапі висхідними являются документи і рішення, що отримані на попередньому етапі. Кожний етап завершується верифікацією породжених документів і рішень з метою перевірки їх відповідності висхідним.

Головна особливість індустрії ПЗ полягає в концентрації складності на початкових етапах ЖЦ (аналіз, проектування) при віносно невисокій складності і труємкості послідуючих етапів. Більш того, невирішені питання і помилки, допущені на етапах аналіза і проектування, породжують на послідуючих етапах вачкі, часто нерозв’язані проблеми і, в кінцевому рахунку, приводять до неуспіху всього проекту.