Главная » UML » Типы требований

0

Традиционно, требования представляются как подробное текстовое описание, относящееся к одной из перечисленных выше категорий, и выражаются в форме "Система должна…". Для эффективного управления всеми требованиями необходимо иметь полное понимание нужд пользователей и других заинтересованных сторон, которым должна удовлетворять разрабатываемая система. Это понимание позволяет команде разработчиков ответить не только на вопрос что?, но и на вопрос почему? ("Почему система должна работать с 99,3%-ной точностью?"). Зная ответы на эти вопросы, команда сможет лучше интерпретировать требования ("Значит ли это, что в процессе текущего техобслуживания система также должна работать с 99,3%-ной точностью?"), а также принимать решения относительно оптимизации процесса разработки ("Если можно получить 92%-ную точность при выполнении половинного объема работ, то будет ли это приемлемым компромиссом?").

Заинтересованные стороны: требования против нужд

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

 

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

Исходя из сказанного, можно заключить, что команда разработчиков должна понять специфические нужды ключевых заинтересованных сторон. Но как понять эти нужды? Одним из необходимых условий является сбор в процессе всего жизненного цикла запросов заинтересованных сторон (необработанных данных, используемых для вычисления нужд). На ранних стадиях проекта можно использовать интервью, вопросники и семинары; позднее понадобятся запросы о внесении изменений, отчеты о дефектах и запросы на улучшение. Часто эти запросы могут быть неоднозначными и расплывчатыми — и зачастую формулируются как нужды (например, "Нужно упростить методы, которые я использую для информирования о состоянии проекта" или "Мне нужно повысить мою эффективность" или "Нам нужно увеличение производительности системы"). Запросы заинтересованных сторон образуют крайне важную среду, в которой формируется понимание их действительных нужд, и вносят существенный вклад в требования к конечному продукту. Именно этот вклад дает нам ключевую часть головоломки, позволяющую ответить на вопросы что? и почему?, касающиеся поведения системы.

Свойства системы

Интересно отметить, что при первоначальном опросе заинтересованных сторон относительно их нужд и требований они, как правило, не упоминают ни одну из категорий, определенных выше. Обычно заинтересованные стороны не говорят ни о своих действительных нуждах (например, "Если связь между мной и Джо не улучшится, то это будет угрожать нашей работе"), ни о действительных требованиях к системе (например, "Должна существовать возможность присоединения RTF-файла к сообщению электронной почты" или "С каждым механизмом автомобиля должна быть связана электронная система контроля, которая…"). Довольно часто приходится начинать работ)" с абстракциями, подобными "Мне нужно автоматическое уведомление о поступлении электронной почты" или "Я хочу автомобиль с такой-то функцией".

Такие типы абстракции — высокоуровневые выражения поведения системы — мы будем называть свойствами. С технической точки зрения свойство можно рассматривать как "предоставляемую системой услугу, которая прямо удовлетворяет нуждам пользователя". Довольно часто свойства определены неоднозначно, что может вызывать конфликты между ними (например, свойства "Я хочу такую-то функцию" и "Я хочу снизить эксплуатационные требования"). В то же время не следует забывать, что все эти свойства являются отражением нужд пользователей. Просто в процессе рассмотрения заинтересованная сторона преобразовала действительное требование ("улучшение связи между мной и Джо") в требование к поведению системы ("автоматизированное уведомление о поступлении электронной почты"). Таким образом, могло произойти некоторое смещение от формулировки что? ("улучшение связи") к формулировке каким образом? ("автоматическое уведомление о поступлении электронной почты").

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

 

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

Программные требования

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

Задание программных требований с помощью прецедентов

В главе 6, Процесс, управляемый прецедентами, уже рассказывалось о моделирова1 нии прецедентов, мощном методе выражения поведения системы с помощью цепочки взаимодействий пользователя с системой, доступных пониманию пользователей и разработчиков. Модель прецедентов — это модель системы и поведения, ожидаемого от этой системы. Она состоит из группы акторов, представляющих внешние объекты, которые взаимодействуют с системой, и прецедентов, определяющих, как акторы используют эту систему. Следует помнить, что модель прецедентов — это эффективный способ подробного выражения программных требований.

По теме:

  • Комментарии