анализ требований. Приложение 1. Анализ требований по Вигерсу. Приложение 1 анализ требований (по Вигерсу)
 Скачать 1.62 Mb.
|
|
— Варианты использования, которые непонятны пользователям. Если пользователи не видят связи описания вариантов использования со своими бизнес-процессами или задачами, то вариант использования следует подкорректировать. Составляйте варианты использования с точки зрения клиентов, а не системы и попросите клиентов проверить их. Возможно, вам не нужны излишне сложнее полные варианты использования. — Новые бизнес-процессы. Пользователям будет трудно придумывать новые варианты использования, если ПО создается для поддержки процесса, которого еще нет. В этом случае сбор информации по требованиям может оказаться не моделированием бизнес-процесса, а изобретением такового. Рискованно ожидать, что с помощью новой информационной системы будет создан эффективный бизнес-процесс. Выполните модернизацию бизнес-процесса, прежде чем браться за полное описание новой информационной системы. — Слишком частое упоминание слов расширить и включить. Начиная работу с вариантами использования, необходимо изменить отношение аналитиков, пользователей и разработчиков к требованиям. Тонкости взаимоотношений, определяемых словами расширить и включить, могут запутать кого угодно. Лучше избегать их, пока вы не освоите способ с применением вариантов использования. Таблицы «событие — реакция» Есть еще один способ систематизации и документации пользовательских требований: определить внешние события, на которые система должна реагировать. Событием (event) называется какое-либо изменение или действие в среде пользователя, вызывающее реакцию системы ПО (McMenamin и Palmer, 1984; Wiley, 2000). В таблице «событие-реакция» (event-response table) [ее также называют таблицей событий (event table) или списком событий (event list)] перечислены все такие события и ожидаемое поведение системы, которое должно последовать, как реакция на каждое событие. Существует несколько типов системных событий: — взаимодействие пользователя с ПО, как когда он, например, вызывает вариант использования [иногда называется бизнес-событием (business event)]. Последовательность событий и реакций соответствует этапам взаимодействия для этого варианта использования, В отличие от вариантов использования, в таблице «событие — реакция» не описываются цели пользователя при работе с системой и не приводятся причины, по которым эта последовательность событий и реакций имеет значение для пользователя; — контрольный сигнал, чтение данных или прерывание, полученное от внешнего аппаратного устройства, например при изменении положения выключателя, изменении напряжения или перемещении мыши пользователем; — событие инициируется в определенный момент времени (скажем, автоматический запуск экспорта данных в полночь) или когда истекает предварительно заданный период времени с момента определенного события (например, система фиксирует температуру, считываемую сенсором каждые 10 секунд). Рисунок «Примеры системных событий и реакций»  Таблицы «событие — реакция» особенно хороши для управления системами, работающими в режиме реального времени. Таблица, приведенная ниже, представляет собой простую таблицу «событие — реакция», в которой частично описано поведение очистителей ветрового стекла автомобиля. Обратите внимание, что ожидаемая реакция зависит не только от события, но и от состояния, в котором находится система во время события. Например, результаты событий 4 и 5.1 различаются из-за того, были ли включены «дворники» в момент, когда пользователь настроил управление «дворниками» на периодический режим. Реакция может просто изменить некоторую внутреннюю системную информацию (события 4 и 7.1 в таблице) или привести к результату, заметному извне (большинство других событий). Таблица «событие — реакция» для автомобильных дворников  Информация в таблице «событие — реакция» фиксируется на уровне пользовательских требований. Если в таблице определены и названы все возможные комбинации событий, состояний и реакций (включая условия исключений), таблица также может служить частью функциональных требований для этого фрагмента системы. Однако аналитик должен добавить дополнительные функциональные и нефункциональные требования в спецификацию требований к ПО. Например, сколько «взмахов» в минуту делают «дворники» в быстром и медленном режиме очищения? В быстром или медленном режиме выполняется периодическая очистка? Является ли периодический режим непрерывно изменяющимся или он работает дискретно? Каковы максимальный и минимальный интервал времени при работе в периодическом режиме? Если вы закончите работу на уровне пользовательских требований, разработчику самому придется выяснять эту информацию. Помните, ваша цель — сформулировать требования настолько точно, чтобы разработчик знал, что строить. Обратите внимание, что события, перечисленные в таблице «событие — реакция» записаны на важнейшем уровне (описывается суть события), а не на уровне реализации (описываются особенности реализации). В таблице ничего не говорится о том, как выглядит элемент управления «дворниками» или о том, как пользователь управляет ими. Дизайнер может реализовать эти требования как угодно — от традиционных элементов управления «дворниками», как в современных автомобилях, до системы распознавания голоса, реагирующей на произносимые команды: «включить дворники», «выключить дворники», «быстрая очистка», «очистить один раз» и т.д. Записывая пользовательские требования на важнейшем уровне, вы избежите введения ненужных ограничений дизайна. Однако следует фиксировать все известные ограничения по дизайну, чтобы заставить разработчика думать. Шаблон спецификации требований к ПО Каждая организация, специализирующаяся на разработке ПО, должна принять один или несколько стандартных шаблонов спецификации требований к ПО для использования в проектах. Доступны различные шаблоны спецификации (Davis, 1993; Robertson и Robertson, 1999; Leifingwell и Widrig, 2000). Многие применяют шаблоны, созданные на основе того, что описан в IEEE Standard 830-1998, «IEEE Recommended Practice for Software Requirements Specifications». Он годится для самых разных проектов, однако в нем встречаются ограничения и неясные места. Если вы беретесь за проекты различных типов и размеров, от конструирования новой объемной системы до небольших улучшений уже работающих систем, заведите для проектов каждого крупного класса отдельный шаблон спецификации. Рисунок «Шаблон для спецификации требований к ПО»  На рисунке «Шаблон для спецификации требований к ПО» показан шаблон спецификации требований к ПО, созданный на основе стандарта IEEE 830. В нем предлагается множество примеров дополнительных требований к продукту, которые вы можете включить в свою спецификацию. Если какой-то раздел вашего шаблона не годится для конкретного проекта, не удаляйте его заголовок, но укажите, что он неприменим. В этом случае у пользователя не возникнет подозрения, что что-то важное было пропущено по невнимательности. Если вам постоянно приходится пропускать одни и те же разделы, это означает, что шаблон следует настроить. Создайте оглавление и журнал изменений спецификации требований к ПО, где указаны дата изменения, сотрудник, внесший изменение, и ее причина. Иногда фрагмент информации логически подходит для нескольких разделов шаблона. Гораздо важнее аккуратно и последовательно фиксировать информацию, чем горячо обсуждать, где следует хранить каждый элемент. Шаблон спецификации требований к ПО и шаблон документа об образе и границах в некоторых местах перекрываются (например, общие элементы есть в границах проекта, в описании особенностей продукта и в разделах операционной среды). Причина кроется в том, что вы создали только один документ, касающийся требований. Если вы используете оба шаблона, измените их таким образом, чтобы ликвидировать избыточность, при необходимости объединив разделы. Возможно, соответствующие разделы спецификации требований к ПО пригодятся для детализации определенного прогноза или высокоуровневой информации, содержащихся в документе об образе и границах проекта. Если же вы решите вырезать и вставить фрагменты из документа в другой, то возможна опасность того, что в обоих появятся ненужные повторы, В следующих разделах этой главы рассказано, какую информацию следует включать в каждый раздел спецификации требований к ПО. Вы можете объединить материал с помощью ссылки на другие документы (например, об образе и границах проекта или спецификацию интерфейса), а не дублировать его в спецификации требований к ПО. Пользовательские интерфейсы и спецификация требований к ПО Включение элементов пользовательского интерфейса в спецификацию имеет как преимущества, так и недостатки. Отрицательным моментом можно считать то, что изображения и архитектура пользовательского интерфейса отображают решения (дизайн), а не требования. Откладывая согласование решений в спецификации требований к ПО до завершения разработки пользовательского интерфейса, вы можете заставить нервничать людей, которые и так обеспокоены тем, что на работу над требованиями затрачено слишком много времени. Включение элементов пользовательского интерфейса в требования может сместить приоритеты, и описание функциональности окажется неполной. Макет экрана не заменит пользовательских и функциональных требований. Не следует ожидать, что разработчики смогут сделать вывод о базовой функциональности и взаимосвязи данных по моментальным снимкам экрана. У одной компании, создающей ПО для Интернета, постоянно возникали одни и те же проблемы из-за того, что разработчики непосредственно переходили к работе над визуальным дизайном сразу же после подписания контракта. У них не было ясного представления о том, как пользователи будут работать с Web-сайтом, поэтому им приходилось тратить массу времени на последующие исправления. Из положительных сторон следует отметить, что изучение возможных пользовательских интерфейсов (таких, как рабочий прототип) делает требования более осязаемыми и для пользователей, и для разработчиков. Изображения пользовательского интерфейса помогают при планировании и оценке проекта. Подсчет элементов графического интерфейса пользователя (graphical user interface, GUI) или числа функциональных точек* (function points), связанных с каждым экраном, позволяет оценить размер проекта и, следовательно, затраты на реализацию. «Золотая середина» подразумевает включение концептуальных изображений — набросков — в спецификацию требований к ПО без обязательного точного соблюдения этих моделей при реализации. При этом улучшается взаимодействие специалистов без ненужных ограничений для разработчиков. Например, предварительный набросок сложного диалогового окна может проиллюстрировать назначение части требований, однако опытный визуальный дизайнер сумеет превратить его в диалоговое окно с вкладками для удобства работы пользователя. * Функциональной точкой называется количество обнаруженных пользователем функций приложения независимо от того, как они сконструированы. Вы можете оценить функциональные точки, исходя из требований пользователя, по числу внешних логических файлов и элементов вводимых данных, выводимых данных и запросов. Моделирование требований Опыт показывает, что модели анализа должны дополнять, а не заменять спецификации требований на естественном языке (т.е. требования в текстовом представлении). К моделям визуального представления относятся: — диаграммы потоков данных (data flow diagrams, DFD); — диаграммы «сущность — связь» (entity-relationship diagrams, ERD); — диаграммы перехода состояний (state-transition diagrams, STD), называемые также диаграммами состояний; — карты диалогов (dialog maps); — диаграммы вариантов использования; — диаграммы классов; — диаграммы взаимодействия. Системы обозначений (нотации) обеспечивают общий, стандартный для всей индустрии язык, которые пользуются участники проекта. Конечно, вы можете специально разработать диаграммы, чтобы дополнить возможности устного и письменного общения в рамках проекта, однако не факт, что пользователи интерпретируют их одинаково. В то же время нельзя не признать ценность нестандартных приемов моделирования. Одна команда применяла средство для составления графика моделирования временных требований для встроенного ПО, причем за единицу измерения были приняты миллисекунды, а не дни или недели. Эти модели годятся для разработки и изучения требований, а также для построения ПО. Будете ли вы использовать их для анализа или для дизайна, зависит от временных рамок и целей моделирования. Применение этих диаграмм для анализа требований позволит вам смоделировать предметную область или создать концептуальные представления новой системы. Они отображают логические аспекты компонентов данных предметной области, транзакции и преобразования, объекты реального мира и изменения состояния системы. Вы можете создавать модели на основании текстовых требований, чтобы отобразить их с различных точек зрения, или вывести детализированные функциональные требования из моделей высокого уровня, созданных на основе предоставленной пользователями информации. В процессе разработки модели демонстрируют, как вы намерены реализовать систему: ту базу данных, которую вы планируете создать, классы объектов, которые вы будете иллюстрировать примерами, и модули кода, которые вы собираетесь разрабатывать. Ловушка. Не следует полагать, что разработчики смогут просто преобразовать модели анализа в код, не разобрав подробно весь процесс. Поскольку в обоих типах диаграмм используются одни и те же системы обозначений, ясно назовите каждый из них моделью анализа (концепция) или моделью дизайна (то, что вы планируете создать). Приемы моделирования анализа, описанные в этой главе, поддерживаются различными коммерческими инструментами автоматизированного проектирования ПО (computer-aided software engineering, CASE). Использование этих инструментов обеспечивает некоторое преимущество перед обычными средствами рисования. Во-первых, они легко позволяют улучшить качество диаграмм при повторных просмотрах требований. Вам не удастся создать отличную модель с первого раза, поэтому итерацию можно назвать ключом к успеху при моделировании систем (Wiegers, 1996a). Кроме того, инструменты автоматизированного проектирования ПО «знают» правила для каждого метода моделирования, который они поддерживают. Они способны определить синтаксические ошибки и несоответствия, которые специалистам, проверяющим диаграммы, не всегда удается обнаружить. Эти инструменты связывают различные диаграммы друг с другом и с их общими определениями данных в словаре данных, а также позволяют поддерживать модели в согласованном состоянии и в соответствии с функциональными требованиям в спецификации требований к ПО. Редкий случай, когда команде необходимо создать полный набор моделей анализа для всей системы. При моделировании сосредоточьтесь на наиболее сложных и опасных участках системы, а также на тех, где наиболее вероятны неясности и неопределенности. Элементы системы, от которых зависит ее безопасность и защита, а также элементы, влияющие на выполнение критически важных задач, можно смело назвать кандидатами на моделирование, так как последствие дефектов в них окажутся особенно тяжелыми. Варианты прототипов Создание прототипов ПО делает требования более реальными, приближает варианты использования к «жизни» и закрывает пробелы в вашем понимании требований. Прототипы предоставляют пользователям экспериментальную модель или первоначальный срез новой системы, стимулируя их мышление и катализируя обсуждение требований. Обсуждение прототипов на ранних стадиях процесса разработки помогает заинтересованным в проекте лицам прийти к общему пониманию требований к системе, что уменьшает риск недовольства заказчиков. Если вы не исправите эти проблемы, разница в ожиданиях между видением продукта пользователями и пониманием разработчиков гарантирована. Трудно точно представить поведение нового ПО при чтении текстовой документации или изучении аналитических моделей. Пользователи более готовы экспериментировать с прототипом (что весело), чем читать спецификацию требований к программному обеспечению (что скучно). Услышав от пользователей «узнаю, когда увижу», подумайте, как вы можете помочь им наглядно представить свои нужды. Однако если ни один из участников не представляет себе, что же должны создать разработчики, проект обречен. Прототип (prototype) имеет множество значений, поэтому ожидания участников процесса прототипирования могут весьма различаться. Прототип самолета действительно летает — ведь это первый вариант настоящего самолета. Напротив, прототип ПО — это только часть или образец реальной системы — он может в принципе не делать ничего полезного. Прототипы ПО могут быть действующими моделями или статичными образцами; детализированным изображением экрана или его эскизами; наглядной демонстрацией или примерами реальной функциональности; имитацией или подражанием. Назначение приоритетов требований Для каждого продукта, на разработку которого выделены ограниченные ресурсы, необходимо определить относительные приоритеты возможностей. Расстановка приоритетов помогает менеджеру проекта разрешать конфликты, планировать выпуски и принимать необходимые компромиссы. Зачем определять приоритеты требований Когда ожидания клиентов высоки, а сроки поджимают, вам нужно, чтобы в продукте были реализованы самые ценные функции как можно раньше. Приоритеты — это способ разрешения борьбы между конкурирующими требованиями за ограниченные ресурсы. Определение относительного приоритета каждой возможности позволяет вам так планировать разработку, чтобы обеспечивать наибольшую ценность при наименьших затратах. Определение приоритетов наиболее критично для работы в очень строгих временных рамках или при применении инкрементальной модели с жесткими, фиксированными сроками выпуска каждой версии продукта. При экстремальном программировании клиенты выбирают, какие рассказы пользователей (user stories) они желают видеть в каждом двух- или трехнедельном выпуске, а разработчики оценивают, сколько из этих рассказов они могут вместить в каждый выпуск. Менеджер проекта должен сбалансировать желаемый объем проекта и ограничения, определяемые сроком, бюджетом, людскими ресурсами и качеством. Один из способов достижения этого — убрать (или отложить до более поздней версии) требования с низким приоритетом, когда принимаются новые, более важные требования или изменяются другие условия проекта. Если клиенты не классифицируют свои требования по важности и срочности, менеджерам проектов приходится делать это своими силами. Неудивительно, что клиентам не всегда нравится результат; поэтому они должны указывать, какие требования необходимы с самого начала, а какие могут подождать. Определяйте приоритеты на ранних стадиях проекта, когда больше шансов на успешный результат, и периодически возвращайтесь к ним. Достаточно сложно заставить даже одного клиента решить, какие из его требований приоритетнее. Согласовать мнения нескольких клиентов с различными ожиданиями еще труднее. Люди по природе склонны отстаивать свои интересы и не жаждут жертвовать собственными нуждами ради чужой выгоды. Тем не менее участие в определении приоритетов требований — одна из обязанностей клиента в отношениях «клиент — разработчик». И клиенты, и разработчики должны внести вклад в определение приоритетов требований. Клиентам больше всего нужны функции, наиболее ценные для бизнеса или удобства работы. Однако, когда разработчики обрисуют затраты, трудоемкость, технический риск или компромиссы, связанные с каждым требованием, клиенты могут передумать и прийти к выводу, что это требование не так важно, как они считали изначально. Разработчики же иногда решают на ранних стадиях реализовать некоторые функции с низким приоритетом из-за их влияния на архитектуру системы. Шкала приоритетов |