Лекция № 2.

Тема: «Обследование, работа с требованиями»

Вопросы:

1.Типы требований

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

Особенности интерпретации требований

Требования — это «нечто такое, что определяет выбор дизайна» (Lawrence, 1997).

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

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

Определение термина «требование» в словаре

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

1. Типы требований

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

1.1. Бизнес-требования (business requirements) описывают, почему организации нужна такая система, то есть цели, которые организация намерена достичь с ее помощью. Основное их содержание — бизнес-цели организации или клиента, заказывающих систему.

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

Записывать бизнес-требования в форме документа о концепции и границах (vision and scope document).

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

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

К отличным способам представления этого вида требований относятся варианты использования (Kulak и Guiney, 2004), пользовательские истории (Cohn,2004) и таблицы «событие — отклик».

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

1.3. Функциональные требования (functional requirements) определяют, каким должно быть поведение продукта в тех или иных условиях.

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

Функциональные требования описываются в форме традиционных утверждений со словами «должен» или «должна».

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

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

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

1.4. Термин системные требования (system requirements) описывает требования к продукту, который содержит многие компоненты или подсистемы (ISO/IEC/IEEE 2011).

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

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

1.5. Бизнес-правила

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

1.6. Атрибуты качества (quality attributes) еще называют параметрам качества, требованиями по уровню обслуживания и т.п. Они представляют собой описание различных измерений характеристик продукта, которые важны для пользователей или для разработчиков и тех, кто будет обслуживать систему, таких как производительность, доступность и переносимость.

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

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

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

1.8. Характеристика (feature) — это набор логически связанных функциональных требований, которые представляют ценность для пользователя и удовлетворяют бизнес-цели.

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

Рис. 1-2 иллюстрирует дерево функций (feature tree) — модель анализа, которая показывает, как функцию можно разложить на иерархию более мелких функций, которые связаны с конкретными пользовательскими требованиями и ведут к определению наборов функциональных требований (Beatty и Chen, 2012)

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

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

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

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

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

На рис. 1-1 были показаны три главных документа требований: документ концепции и границ, документ пользовательских требований и спецификация программных требований. Не всегда обязательно создавать эти три отдельных документа в каждом проекте. Часто имеет смысл объединять часть информации, особенно в небольших проектах.

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

Если ответ положительный, требование должно присутствовать в спецификации.

В противном случае требования в спецификации быть не должно, по крайней мере, в текущем выпуске или итерации.

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

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