Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 31
Текст из файла (страница 31)
редине панели, с которыми полыюватель будет взаимодействовать. Если для представления информации применяется система окон, можно задать высокоуровневое графическое описание данных, которые необходимо отобразить на экране. Детали проектирования формального графического интерфейса пользователя (СШ), такие как определение данных, цвета и шрифтов, можно оставить на потом. На рис.
13.2 пред. ставлеи пример фрагмента спецификации прецедента. Прецедент: перераспределение товаров на складе 1. Заведующий дает команду перераспределить предметы па складе. 2. Заведующему предлагается окно иа рнс. ххх. 3. Товары можно упорядочить различными способами, которые представлены в меню. ° Упорядочитьпо алфавиту ° Упорядочить по значению индекса ° Упорядочить по срокам хранения 4.
Таблица "Откуда" позволяет выбрать режим рассмотрения (можно рассматривать все помещения склада или только те помещения, где есть ухазаииый товар) Мюс. ез.2. Саеци(еикацая ярецедеяюа ярокзводамого вр)чяую вере)зовя)еедвеекия аю. варов ка складе Рабочий пример. Прецеденты системы НОЕ1$ Название Описание Ахтар(ы) Создание обычной осветительной Жилец создает обычную осветительную сцену Жилец, лампы сцены Инициирование чрезвычайных действий Жилец инициирует чрезвычайные действия Жилец Команда разработчиков системы НОЫ3 решила воспользоваться методом прецедентов для описания высокоуровневых системных функций НОЫ$.
Команда провела сеанс мозгового штурма для определения важных прецедентов, которые заслуживают дальнейшей разработки на более поздних этапах. Это "исследование модели прецедентов" выявило 20 прецедентов, которые следует уточнить в ходе дальнейших действий; некоторые из них приводятся ниже. Глава 13. Применение прецедентов 153 Актер(ы) Описание Название Жилец включает/выключает лампу(ы) или задает желаемый уровень яркости света Изменение или задание действий для определенной клавиши/переключателя Провайдер услуг компании Ьпшепапопз осуществляет удаленное программиро- вание, основываясь на запросах жильца Домовладелец устанавливает специальный режим на время длительного отсутствия Домовладелец программирует основан- ную на времени последовательность ав- томатического возникновения освети- тельных событий Жилец, лампы Управление освещением Домовладелец/программист Переключение программы Удаленное программирование Службы компании (.пшепабопз Домовладелеп/программист Продолжительное отсутствие Домовладелец/программист Залзнне временной после- довательности Заключение Прецеденты являются структурированной и разумно формальной нотацией для фиксации очень важного подмножества информации о требованиях: как система взаимодействует с пользователем при предоставлении своих функциональных возможностей.
Во многих приложениях это подмножество составляет львиную долю рабочей нагрузки, по. этому прецеденты можно применять для выражения болыней части требований к снсте. ме. Каждый выявленный прецедент определяет требуемое поведение системы с точки зрения определенного класса пользователей. Поэтому данный метод очень полезен в выявлении потребностей пользователей и помогает команде разработчиков представить зти потребности в понятной пользователям форлге.
Поскольку прецеденты можно применять позднее в процессе проектирования и тестирования, они обеспечияают целостное представление и нить согласованных действий по. выявлению требований, анализу, проектированию и тестированию. Такил~ образом, данный метод на раннелг этапе создает активы проекта, которые можно повторно использовать. Кроме того, благодаря согласованности представления и поддержке, обеспечиваемой ()М1. и различными вспомогательными средствами разработки приложений, прецеденты можно использовать для автоматизации различных действий с требованиями. Прецеденты настолько важны, что мы будем прилгенять их, начиная с этого момента и далее, в качестве неотъемлемой составной части деятельности команды по управлению требованиями.
Глава 14 Обыгрывание ролей . членовньле положения ~' И:;С помощью обыгрывания ролей команда разработчиков может почувство.'1 ;: фйть мир,пользователя, поставив себя на его место.' ° т;.В. некоторых''случаях обыгрывание ролей можно заменить просмотроМ, , '-: сценария,.н,тогда сценарий становится "живой" раскадровкой. 1;И 'Часто:используемые в'обьектно ориентированном моделировании СКС-', карточки (С!эы-Кегропг)ЬШгу.Со11аЬогаг)оп) являются одним из средств; с:,„'.,'обыгрывания ролей. Итак, в части 2 мы уже обсудили множество методов выявления потребностей заинтересованных лиц по отношению к создаваемой системе. Мы гюгоеорили о ией с глазу на глаз (интервьюирование); обсудили ее в групповом режиме (совещания); иредсяиитли свои идеи (мозговой штурм) и подумалн о том, как акторы лзагсиадейсэюуют с ией (прецеденты).
Все это хорошо, но мы еще не опробовали ее. В данной главе обсуждается метод обыгрывания ролей, который позволяет команде разработчиков прочувствовать мир пользователя, побывав в его роли. Концепция, лежащая в основе данного метода, достаточно проста: хотя, наблюдая и задавая вопросы, мы повышаем уровсиь своего понимания, наивно налагать, чта носредслюом одного иаблю. деиия разработчик/аналитик мазсет получить истинна глубокое тюиимание решаемой иро.
блемм или тРеболаиий к систгме, хотаРал иРизааиа данную пРоблему Решиэгк Это одна из основных причин возникновения синдрома "да, но...". Как учит социология, каждый из нас видит мир через свой собственный концептуальный фильтр. Наш жизненный опыт и предубеждения невозможно отделить от производимых нами наблюдений. Например, мы можем наблюдать другую культуру и принимать участие в некой ритуальной церемонии так часто, как нам вздумается, но вряд ли нам удастся гюилтк что это значит для представителей этой культуры! Применительно к нашей задаче выявления требований это означает следующее. ° Мы должны понимать, что многие пользователи пе могут описать процедуры, которые они выполняют, или потребности, которые необходимо учесть.
Зачастую это не входит в их задачу, и их никогда прежде не спрашивали об этом. Кроме того, это гораздо сложнее, чем кажется! Например, попытайтесь описать процедуру, с помощью которой вы зашнуровываете туфли. 1бб Часть 2. Понимание потребностей пользователей ° Многие пользователи опасаются признаться, что они нс следуют предписанной процедуре; следовательно, то, что они вам говорят, может являться (а л1ожет и ис являться) тем, что они делают в действительности. ° Некоторые пользоватсли применяют исстандартныс или уникальные способы выполнения рабочих действий, которые могут маскировать реальные проблемы от паолюдатсля. ° Ни один разработчик пс в состоянии предвиден все вопросы, которые необходимо за- дать, и ни один пользователь ие знает, какие вопросы должен задать разработчик.
Обыгрывание ролей может помочь при решении этих проблем. Оно ие требует значительных затрат времени и средств. Обычно достаточно часа или половины дня, чтобы вес стало ясно. Как играть роль Как правило, разработчик, аналитик или любой шеи команды занимает место пользовате.
ля и выполняет его обычные действия. Рассмотрич в качестве прил~ера проблему ввода заказов па покупку. В главе 4 мы выяснили, что неправильные заказы иа покупку вносят основной вклад в стоимость остатков и, тем самым, снижают рентабельность. Рассматривая существукг щий процесс оформления заказов на покупку, мы ожидаем найти рззличныс источники ошибок.
Существует по крайней мере два пути выявить основные причины. 1. Использовать описанный раисе метод построения диаграммы в виде "рыбного скелета" совместно с интервьюированием пользователей и проанализировать некорректные заказы. Распределить ошибки по типам и учесть наиболее типичные при проектировании новой системы. Это обеспечит количественное понимание проблемы и, возможно, будет весьма эффективно.
Однако это нс позволит вам "ощутить" проблему, что могло бы изменить как ваше восприятие, так и стратегию решения. Для этого существует более простой способ. 2. Разработчик/аналитик может "прочувствовать" проблемы и неточности, присущие существующей системе ввода заказов иа покупку, просто заняв месию ояераяк4эа и яоимяшешксь ввести несколько заказов. Полученный в течение часа опыт навсегда изменит понимание командой сути проблемы. Как мы убедились, впечатления, полученные при исполнении роли, остаются с нами навсегда. Наш взгляд на мир изменился под влиянием мно. жества сыгранных ролей, среди которых "сварка сложных швов тем способом, как это должен делать робот", "смешивание фармацевтических составляющих в ламинарном потоке", "выявление телерекламы по чстгярсм сжатым экранным изображениям и сжатому ауднотреку", "использование несовершенного инструментально.
го средства управления требованиями" н др. Мы каждый раз учились чему-нибудь н проявляли гораздо больше сочувствия к пользователю, чем до этого! Глава 14. Обыгрывание ролей 157 Методы, аналогичные обыгрыванию ролей Конечно, обыгрывание ролей применимо не во всех ситуациях. Во многих случаях роль пользователя минимальна, а решаемая проблема является скорее алгоритмической, чем функциональной. В других случаях это просто не практикуется.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
