Глава 9 Требования

В качестве причин неудачной разработки программных продуктов чаще всего на­зывают две, имеющие прямое отношение к требованиям: недостаток ясных, оп­ределенных и измеримых требований, а также ограниченный контроль за требова­ниями во время разработки. Возможно, существует и третья, связанная с требования­ми причина неудач проектов, которая еще недостаточно хорошо осознана — недоста­ток ясных требований в отношении практичности, ПИ, согласованности, комплекта­ции, пользовательских и деловых потребностей и ожиданий.

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

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

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

В этой главе рассматриваются следующие вопросы.

• Ключевые возможности системы.

• Подход к сбору требований.

• Требования к ПИ.

• Требования по практичности.

• Как сделать требования наглядными и измеримыми.

  • Требования для обсуждаемого проекта.

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

Ключевые возможности системы

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

Теперь, когда читатель получил общее представление о том, какие виды информа­ции необходимы, предстоит понять, где искать требования для ПИ и практичности. Как правило, подобные требования не записываются за исключением случаев пред­ставления требований на очень абстрактном уровне. Поэтому ориентированная на пользователей бригада разработчиков продукта формирует требования, пользуясь многими источниками, к которым относятся текущие бизнес–процессы, пользователи и системы (рис. 9.1).

Вопрос: Как вы можете осознать необходимость и достаточность требований, ес­ли вы плохо осведомлены о них?

Существующая документация. В качестве источников явных и неявных требований выступают прецеденты (Use Case), функциональные требования, функ­циональные спецификации и справочники по деловой деятельности. Примеры дру­гих источников информации— презентации, проводимые заказчиками, стратегиче­ские документы и документы описания бизнес–процессов .

Требования к ПИ приложений обычно представлены на очень высоком уровне и в них недостает специфики. Обычно требования к ПИ продукта включают такие формулировки.

• Следует обеспечить GUI-интерфейс.

• ПИ должен соответствовать платформе ОС и корпоративному стилю.

• Интерфейс должен быть простым в изучении и легким в использовании.

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

Рис. 9.1. Требования в процессе ориентированной на пользователя разработки продукта

Задачи пользователей и деловые процедуры. Задачи конечных пользователей требуют хорошего описания вместе с выяснением распределения частоты их выполнения. Например, использование правила "80/20" помогает сосредоточить внимание на классификации и выявлении приоритетности задач. 20% задач включают те, которые выполняются редко или которые имеют небольшое значение для пользователей, организации или заказчиков; 80% задач составляют задачи, которые выполняются более часто, наиболее подвержены ошибкам, обходятся дороже и\или оказывают наибольшее влияние на деятельность организации, пользователей и заказчиков. Обладая подобной информацией, можно использовать подход, направленный на оптимизацию системы для достижения наилучших результатов, а это по­зволяет избежать построения некоей усредненной системы, нацеленной на усреднение результаты применительно ко всем категориям задач и пользователей.

Экран

1

Экран

2

Экран

3

Экран

4

Экран

5

Рис. 9.2. Требования с точки зрения бизнеса, пользователей и системы

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

Более подробно задачи пользователей рассматриваются в главе 10.

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

Более подробно модели пользователей рассматриваются в главе 10.

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

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

• Эффективность работы пользователей в существующей среде.

• Удовлетворенность пользователей системой.

• Отношение пользователей (нравится или не нравится) к существующей системе.

• Что требуется пользователям взамен того, что им доступно.

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

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

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

Оценка конкурирующих продуктов. Наряду с существующими используемыми продуктами к другим источникам данных по возможностям, ПИ, информационной поддержке и практичности относятся реальные конкурирующие и анало­гичные продукты. Конкурирующие и аналогичные продукты рассматривают с исполь­зованием методов, применяемых для оценки существующих продуктов.

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

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

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

Возможности ПИ. Чтобы удовлетворить потребности пользователей, организаций и заказчиков, требования к программному ПИ должны быть конкретными. Ниже приведены примеры возможностей ПИ, общие для графических и Web-ориентированных интерфейсов, а также интерфейсов портативных устройств.

• Поддержка графики (окна, пиктограммы, графические элементы управления и

т.д.)

• Меню (строка меню и выпадающие меню, всплывающие меню, каскадные меню, панели инструментов).

• Представления (компоновка, схема и т.д.).

• Средства навигации (схема web-узла, путеводители типа "хлебных крошек" в т.д). ("Хлебные крошки"— специально встраиваемые в программу отладочные операторы, служащие путеводной нитью для поиска причин аномального поведения программы при отладке— как спасительные хлебные крошки в сказке братьев Гримм, где герои блуждали по лесу. — Прим. ред.)

• Клавиши быстрого выбора команд ("горячие клавиши") и ускоряющие клавиши (клавиша, которая соответствует подчеркнутой букве в строке меню ила диалога. — Прим. ред.).

• Средства манипулирования (Переместить, Копировать и другие команды).

• Специальные операции (Сохранить, Печать, Копировать в буфер, Отменить/Пов­торить и т.д.).

• Минимализм (в отношении продукта и информации).

• Настройка (клавиатура, мышь, последовательное раскрытие информации и

т.д.).

• Альтернативные устройства ввода и вывода.

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

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

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

• Анимационная графика, которая служит для сообщений, сигналов и других целей.

• Слышимая информация, используемая для сообщений, сигналов и прочих целей.

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

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

• Печатные справочники и рабочая поддержка.

• Аудиторные занятия, интерактивные руководства.

• Помощь, "мастер–программы", карточки-шпаргалки, приглашения, контекст­ные окна указателя.

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

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

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