Определение и анализ требований к ПО (начало)

Особенности интерпретации требований.
IEEE Standard Glossary of Software Engineering Terminology (1990) определяет требования как:
Условия или возможности, необходимые пользователю для решения проблем или достижения целей;
Условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;
Определения

Документированное представление условий или возможностей для пунктов 1 и 2.
Это определение охватывает требования как пользователей (внешнее поведение системы), так и разработчиков (некоторые скрытые параметры).
Термин пользователи следует распространить не на всех заинтересованных лиц, так как не все, кто заинтересован в проекте — пользователи.
Определения

Требования — это спецификация того, что должно быть реализовано. В них описано поведение системы, свойства системы или ее атрибуты. Они могут быть ограничены процессом разработки системы.
Главное правило:
требования должны быть документированы!!!
Определения

Существуют три уровня требований к ПО:
Бизнес-требования;
Требования пользователей;
Функциональные требования, системные требования.
В дополнение, каждая система имеет свои нефункциональные требования.
Уровни требований

Уровни требований

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

Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Функциональные требования описывают требуемое поведение системы в определенных условиях. Иногда их называют требованиями поведения (behavioral requirements), они содержат положения с глаголами «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.
Уровни требований

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

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

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

Каких требований не должно быть?
Спецификация требований не должна сожержать деталей дизайна или реализации (кроме известных ограничений), данных о планировании проекта или сведений о тестировании.
Уровни требований

Разработка и управление требованиями
Разработка требований подразумевает следующие виды деятельности:
извлечение (elicitation);
анализ (analysis);
документирование (specification);
утверждение (validation).
В эти виды входят все действия, включающие сбор, оценку и документирование требований для ПО или ПО-содержащих продуктов

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

Разработка и управление требованиями

Разрыв ожиданий
Без адекватного участия клиента в конце проекта неизбежно возникает разрыв ожиданий (expectation gap) — пробел между тем, что клиенту реально нужно, и тем, что предоставили разработчики, основываясь на том, что они знали в начале проекта.
Наилучший способ минимизации разрыва ожиданий — организация частых точек контакта с представителями клиента. Эти точки могут принимать форму интервью, собеседований, просмотра требований, откликов клиентов на небольшие расширения функциональности исполняемого ПО.
Каждая точка контакта предоставляет возможность закрыть разрыв ожиданий: создаваемое разработчиком ближе к тому, что требуется клиенту.

Разрыв ожиданий

Достижение соглашения о требованиях
Достижение соглашения о требованиях к продукту или его части, которую планируется построить, — основа сотрудничества клиентов и разработчиков.
В выработке соглашения участвует много сторон:
клиенты должны подтвердить, что требования удовлетворяют их потребности;
разработчики подтверждают, что они понимают требования и в состоянии их реализовать;
тестировщики подтверждают, что требования поддаются проверке;
руководство подтверждает, что требования соответствуют их бизнес-целям.

Итеративный процесс формулирования требований

Итеративный процесс формулирования требований