Выявление требований Модель выявления требований Основные

Выявление требований

Модель выявления требований

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

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

Основные источники получения информации о потребностях пользователей Маркетинговые исследования и опросы пользователей Опрос потенциальных пользователей продукта позволяет проверить, насколько четко вы понимаете требования, выявлением которых вы занимаетесь, но чтобы избежать ошибок необходимо: критически изучить перечень вопросов проконсультироваться с экспертом по планированию и управлению опросами, дабы убедиться, что вы задаете нужные вопросы нужным людям Повторное использование требований в разных проектах Если необходимая клиенту функциональность аналогична уже реализованной в другом продукте, подумайте, готовы ли клиенты гибко пересмотреть свои требования для использования существующих компонентов: требования к безопасности, определяющие порядок доступа к приложениям, и требования, соответствующие постановлениям правительства

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

Основные способы выявления требований Интервью Групповые семинары

Интервью Создать атмосферу, благоприятную для тщательного рассмотрения всех аспектов разрабатываемого программного обеспечения: использовать лексику соответствующей предметной области объяснить пользователям, что обсуждение возможной функциональности – это еще не обязательство включить ее в продукт

Методики проведения интервью Активную роль играет аналитик Аналитик задает вопросы разного типа: например, типа «Почему? » , вопросы, допускающие несколько вариантов ответа Активную роль играет респондент Аналитик - новичок, которого обучает опытный пользователь. Аналитик задает массу вопросов, а пользователь управляет беседой, выбирая важную, с его точки зрения, тему для обсуждения. Метод исключений Что мешает пользователю успешно выполнить задачу? Как система должна реагировать на различные, ошибочные условия? Вопросы, начинающиеся со слов: «Что еще могло бы. . . » , «Что произойдет, когда. . . » , «Вам когда-нибудь требовались. . . » , «Где вы получаете. . . » , «Почему вы делаете (или не делаете). . . » и «А кто-нибудь когда- либо. . . » . При разработке следующей версии системы или модернизации существующей системы, попросите пользователей припомнить три вещи, которые раздражают их сейчас больше всего. Этот вопрос поможет вам понять, почему же систему следует менять. При этом также становится ясно, чего же ждут пользователи от новой системы. Как и при любой модификации, неудовлетворенность настоящим дает отличную пищу для принятия нового. Использование бесконтекстных вопросов, узкоспециализированных вопросов и вопросов, допускающих разные толкования, чтобы выявить информацию о бизнес-проблемах и их возможных решениях. Реакция пользователей на такие вопросы, как «Какой уровень точности необходим в продукте? » или «Почему вы не согласны с предложенным ответом? » , иногда более информативна, чем информация, получаемая в ответах на вопросы типа «да/нет» или «А/В/С» .

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

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

Проведение совместных семинаров Совместные семинары по выявлению позволяют выявить нужды пользователей и составить наброски документов с требованиями упрощают сбор информации о требованиях эффективно наладить связи между пользователями и разработчиками

Основная задача ответственного за мероприятие сотрудника Создать условия для успешного проведения семинара Составить план семинара Осуществить выбор участников Следить за ходом обсуждения Назначить секретаря, чтобы он фиксировал все идеи, возникающие в ходе обсуждения Однако при проведении семинаров существует и множество опасностей: совместное обсуждение может перейти в бесполезные споры участники могут увлечься обсуждением несущественных вопросов

Приемы успешного ведения семинара Определите основные правила Участники должны договориться об основных правилах проведения семинаров. Например, таких: своевременно начинать и заканчивать семинар; не опаздывать после перерывов; не проводить несколько обсуждений одновременно; следить, чтобы каждый принимал участие в работе; комментировать и критиковать решение, а не личность. Придерживайтесь границ проекта Чтобы удостовериться, что предлагаемые пользовательские требования не выходят за текущие границы проекта, используйте задокументированный образ и границы проекта. Следите, чтоб на каждом семинаре уровень обобщения соответствовал выбранным целям. Периодически участники могут углубляться в обсуждения несущественных деталей. На это уходит масса времени, которое на начальном этапе работы следует потратить на прояснение пользовательских требований – время деталей наступит позже. Задача организатора – по мере необходимости возвращать участников к теме обсуждения. Пользователи легко переходят к обсуждению того, где в отчете или диалоговом окне следует разместить элементы, даже еще до того, как разработчики согласятся с поставленными задачами. Если вы включите данные детали в требования, то тем самым ограничите процесс разработки. Хотя предварительные наброски интерфейса полезны на любом этапе, особенно для иллюстрации возможных способов реализации требований, к детальной разработке пользовательского интерфейса следует приступать позднее, после определения основных требований.

Приемы успешного ведения семинара Фиксируйте темы для дальнейшего обсуждения На семинаре всплывает масса случайных, но важных сведений: атрибуты качества, бизнес- правила, идеи по разработке пользовательского интерфейса, ограничения и т. п. Их необходимо фиксировать по ходу семинара на карточках, плакатах, доске или иным удобным способом. Главное при этом – их доступность всем участникам семинара. Действуя подобным образом, вы не потеряете эти сведения и продемонстрируете уважение участнику, высказавшему их. Не отвлекайтесь на обсуждение деталей, не относящихся к теме дискуссии, если только они не окажутся важными, например бизнес- правилом, которое ограничивает варианты использования. Ограничивайте некоторые дискуссии по времени Организатор семинара имеет право ограничить время обсуждения каждой темы, скажем, первоначально – 30 минут на каждый вариант использования. Возможно, некоторые дискуссии придется завершить позднее, но жесткие временные рамки помогают не тратить времени больше, чем запланировано. В противном случае времени может не хватить на обсуждение всех запланированных тем. Хорошей практикой является подведение ведущим итогов обсуждения каждой темы в последние 3 -5 минут, выделенного на обсуждение времени, даже если обсуждение еще не закончено. В подобном резюме фиксируются все нерешенные вопросы, а также необходимость дальнейшего обсуждения. При таком подходе все запланированные темы будут обсуждены, а при наличии резерва времени в конце семинара можно будет вернуться к обсуждению спорных тем.

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

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

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

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

Специфика выявления атрибутов качества Дизайнеры и программисты должны определить наилучший способ удовлетворения требования для каждого атрибута качества и производительности. Хотя атрибуты качества относятся к нефункциональным требованиям, они помогают сформулировать функциональные требования, определить направления разработки или техническую информацию, которые позволяют реализовать продукт желаемого качества. Иначе говоря, при разумном подходе, атрибуты качества могут стать источником других требований и служить основой для принятия решений относительно дизайна разрабатываемой системы. В приведенной ниже таблице перечислены некоторые категории технической информации, которые могут быть выведены с помощью атрибутов качества. Типы атрибутов качества Категория технической информации Целостность, способность к взаимодействию, устойчивость к Функциональное требование сбоям, легкость и простота использования, безопасность Доступность, эффективность, гибкость, производительность, Архитектура системы надежность Способность к взаимодействию, легкость и простота Ограничения дизайна использования Гибкость, легкость в эксплуатации, мобильность, надежность, Руководство по дизайну возможность повторного использования, тестируемость, легкость и простота использования Мобильность Ограничение реализации

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

Анализ требований

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

Анализ требований

Анализ осуществимости требований Прежде чем подвергать выявленные требования подробному анализу, желательно проанализировать осуществимость этих требований. Увы, требование может быть безупречным со всех сторон, но, в тоже время, быть неосуществимым, т. е. нереализуемым при известных условиях и ограничениях создаваемого продукта и операционной среды, в том числе и при оговоренных сроках и объеме финансирования. Естественно не следует тратить ресурсы на подробный анализ и проработку подобных требований - их необходимо отсекать на начальных стадиях анализа. Проанализируйте, насколько реально реализовать каждое требование при разумных затратах и с приемлемой производительностью в предполагаемой среде. Рассмотрите риски, связанные с реализацией каждого требования, включая конфликты с другими требованиями, зависимость от внешних факторов и препятствия технического характера. При анализе осуществимости требований ключевую роль играют разработчики. Именно их мнение будет решающим принятии решения об отклонении неосуществимых требований. Анализ осуществимости требований - не одноразовая акция и должен осуществляться на каждой итерации разработки требований для всех имеющихся требований, в том числе и для тех, для которых такой анализ уже проводился. Это обусловлено тем, что по мере выявления и разработки требований определяются и уточняются характеристики операционной среды, ограничения дизайна и реализации, требования к внешнему интерфейсу, требования к производительности и атрибуты качества, т. е. по существу уточняются условия и ограничения создаваемого продукта и операционной среды. Естественно, при изменении этих условий и ограничений оценка осуществимости также подлежит пересмотру.

Определение приоритетов требований также весьма важный процесс, поскольку приоритеты - это наиболее естественный способ разрешения борьбы между конкурирующими требованиями за ограниченные ресурсы. Правильное определение относительного приоритета каждой возможности позволяет так планировать разработку, чтобы обеспечивать наибольшую ценность при наименьших затратах. Даже одного человека достаточно сложно заставить решить, какие из его требований приоритетнее. Согласовать же мнения нескольких пользователей с различными ожиданиями и мнения разработчиков еще труднее. Люди по природе склонны отстаивать свои интересы и не жаждут жертвовать собственными нуждами ради чужой выгоды. Поэтому для определения приоритетов необходимо воспользоваться аналитическим методом, изложенным в разделе 2. 7. Приоритеты полезны не только как средство, упрощающее планирование разработки. Само обсуждение приоритетов помогает не только определить последовательность реализации требований, но и прояснять ожидания пользователей. И пользователи, и разработчики должны внести вклад в определение приоритетов требований. Пользователям больше всего нужны функции, наиболее ценные для бизнеса или обеспечения удобства работы. Однако, когда разработчики обрисуют затраты, трудоемкость, технический риск или компромиссы, связанные с каждым требованием, пользователи могут передумать и прийти к выводу, что это требование не так важно, как они считали изначально. Разработчики же иногда решают на ранних стадиях реализовать некоторые функции с низким приоритетом из-за их влияния на архитектуру системы.

Моделирование требований - это ключевой процесс анализа требований, заключающийся в построении различных моделей требований на основе исходных текстовых данных, полученных при выявлении требований. В отличие от подробной информации, представленной в тестовом описании требований, графические модели анализа отображают требования на высоком уровне абстракции. При этом, зачастую представление требований несколькими способами позволяет выявить их особенности и проблемы, не заметные при представлении одним определенным способом. Высокоуровневые модели позволяют выявить некорректные, несогласованные, отсутствующие и избыточные требования. К таким моделям относятся диаграммы потоков данных, диаграммы «сущность – связь» , диаграммы перехода состояний, называемые также автоматами (state charts), карты диалогов, диаграммы классов, диаграммы последовательностей, диаграммы взаимодействий, таблицы решений и деревья решений. Выбор конкретных моделей определяется спецификой проекта, а также наличием соответствующих инструментальных средств, поскольку построение моделей без соответствующей инструментальной поддержки приводит к неоправданным затратам ресурсов и чревато ошибками. Для помощи в выявлении требований полезно использовать такую простую модель анализа, как контекстные диаграммы, которые отображают место разрабатываемой системы (или ее части) в соответствующей среде. Поскольку контекстная диаграмма наглядно определяет границы и интерфейсы между разрабатываемой системой (или ее частью) и сущностями, внешними для этой системы, например пользователями, устройствами и прочими информационными системами, ее полезно использовать для визуализации образа и границ проекта в ходе выявления требований. Во всех сомнительных и спорных ситуациях полезно прибегнуть к практике создания прототипов – частичных, упрощенных или предварительных версий продукта, которые делают рассматриваемые концепции и возможности более осязаемыми. Оценка прототипа поможет всем заинтересованным лицам достичь взаимопонимания по решаемой проблеме.

Поиск упущенных требований Пропуск каких-либо важных данных – самый распространенный недостаток требований. Обнаружить их в процессе повторного просмотра требований очень трудно, поскольку они просто невидимы! Предлагаемые далее приемы позволяют выявить упущенные требования. И в тоже время следует заметить, что не стоит тратить слишком много времени на выявление требований, пытаясь не упустить ни одно из них – все равно вы никогда не выявите их все сразу! Раскладывайте требования высокого уровня на простейшие составляющие - это позволит понять, чего же именно просят пользователи. Из-за неясности требований высокого уровня, предоставляющих пользователям слишком большую свободу интерпретации, возможно несовпадение представлений пользователей о продукте и тем, что создает разработчик. Вот некоторые неточные и расплывчатые термины, которых следует избегать: обеспечивать поддержку, предоставлять возможность, разрешать, обрабатывать и управлять. Конечно, наличие какого-либо из этих терминов в формулировке требования отнюдь не означает, что это требование неверно, но служит сигналом для проверки необходимости дальнейшей детализации требования. Убедитесь, что все классы пользователей предоставили вам информацию и для каждого варианта использования определена, по крайней мере, одна роль. Подробно документируйте, на каких функциональных требованиях основаны требования к системе, варианты использования, списки откликов на события и бизнес-правила. Это позволит вам быть уверенным, что аналитик описал всю необходимую функциональность. Для выявления недостающих требований проверяйте граничные значения. Предположим, в одном требовании указано: «Если стоимость заказа меньше $100, стоимость доставки будет равна $5. 95» , а в другом – «Если стоимость заказа превышает $100, стоимость доставки составляет 5% от общей стоимости заказа» . А как быть, если стоимость заказа составляет ровно $100? Это не оговорено, значит, отсутствует соответствующее требование. Используйте разнообразные формы представления информации о требованиях. Трудно прочитать большой объем текста и заметить, что чего-то не хватает. Модели анализа визуально представляют требования высокого уровня абстракции – лес, а не отдельные деревья. Рассматривая модель, вы можете заметить, что от одного блока к другому должна идти стрелка, которой нет, – это тоже недостающее требование. Подобного рода ошибку легче заметить на рисунке, чем в длинном списке требований, который сливается перед глазами.

Матрица CRUDL Одним из точных и продуктивных способов поиска недостающих требований является создание так называемой матрицы CRUD (Create, Read, Update, Delete – создание, чтение, обновление, удаление). Данная матрица позволяет соотнести действия системы с элементами данных (отдельными или их совокупностями), в результате вы получаете представление о том, где и как каждый элемент данных создается, считывается, обновляется и удаляется. Некоторые авторы добавляют к названию матрицы букву L (CRUDL), указывая, что элементы данных можно еще и перечислять (List). Например, при помощи этого инструмента легко проверить полноту и непротиворечивость вариантов использования, построив соответствующую матрицу, где строки – это имеющиеся варианты использования, а столбцы – элементы данных. На пересечении строк и столбцов необходимо расставить пометки операций, выполняемых вариантом использования с элементами данных: C – создание, R – чтение, U – обновление, D – удаление, L – перечисление. Наличие пустых столбцов означает либо отсутствие необходимых вариантов использования, либо ненужность соответствующего элемента данных. Наличие пустых строк означает либо ненужность соответствующих вариантов использования, либо отсутствие необходимых элементов данных. Если в столбце отсутствует признак создания элемента данных, то это явно указывает на неполноту вариантов использования. Если в столбце отсутствует признак удаления элемента данных, то следует разобраться, действительно ли этот элемент не подлежит удалению. Если в столбце отсутствуют признаки использования элемента данных (RUL), то следует разобраться, действительно ли необходим этот элемент данных. Для составления соответствующих матриц CRUDL необходимо использовать словарь данных. При этом анализ матриц позволяет проверить полноту словаря данных и уточнить его при необходимости. Полезной особенностью матриц CRUDL является и то, что их можно начинать составлять не дожидаясь завершения выявления требований и пополнять на каждой итерации. Причем анализ матриц на каждой итерации способен подсказать направления выявления недостающих данных.

Документирование требований

Итог разработки требований – задокументированное соглашение между клиентами и разработчиками о создаваемом продукте. Способов представления требований несколько: документация, в которой используется четко структурированный и аккуратно используемый естественный язык; графические модели, иллюстрирующие процессы трансформации, состояния системы и их изменения, взаимодействия данных, а также логические потоки, классы объектов и отношения между ними; формальные спецификации, где требования определены с помощью математически точных, формальных логических языков. Последний метод обеспечивает наивысшую степень точности, однако немногие разработчики – и еще меньше клиентов – знакомы с ним, поэтому они не могут, используя этот метод, проверить спецификации на наличие ошибок. Несмотря на недостатки, наиболее практичным подходом остается структурированный естественный язык, дополненный графическими моделями.