анализ требований. Приложение 1. Анализ требований по Вигерсу. Приложение 1 анализ требований (по Вигерсу)
 Скачать 1.62 Mb.
|
|
Полнота и корректность спецификации требований. Чтобы требования точно определяли потребности клиента, применяйте метод вариантов использования, чтобы выявить требования, концентрируясь на пользовательских задачах. Составляйте конкретные сценарии использования, пишите варианты тестирования на основе требований и просите клиентов разрабатывать свои критерии принятия. Создавайте прототипы, чтобы требования были понятны пользователям, и чтобы получать от них конкретные отзывы. Привлеките представителей клиентов к экспертизе спецификации требований и моделей анализа. Требования для суперсовременных продуктов. Легко ошибиться в оценке реакции ранка на продукты, первые в своем роде. Уделите большое внимание исследованию рынка, создавайте прототипы и используйте фокус-группы пользователей, чтобы получать раннюю и частую обратную реакцию относительно вашего продукта. Определение нефункциональных требований. Поскольку основное внимание, естественно, обращено к функциональности продукта, легко упустить нефункциональные требования. Запрашивайте клиентов о качественных характеристиках, таких, как производительность, легкость и простота использования, целостность и надежность. Документируйте эти нефункциональные требования и критерии их принятия как можно точнее в спецификации требований к ПО. Единство мнений клиентов относительно требований к продукту. Если различные клиенты вашего продукта не достигли соглашения относительно того, что именно вы должны разрабатывать, кто-то их них останется недоволен результатом. Определите основных клиентов и используйте сторонников продукта для получения адекватного представительства и вовлечения клиентов. Удостоверьтесь, что вы полагаетесь на правильно выбранных людей, которые имеют полномочия для принятия решений. Не сформулированные требования. У клиентов часто есть скрытые ожидания, о которых они не сообщают, и поэтому те не документируются. Постарайтесь выявить любые допущения, которые может делать клиент. Используйте вопросы в свободной форме, чтобы поощрить клиентов больше делиться своими мыслями, пожеланиями, идеями, информацией и сомнениями. Использование существующего продукта в качестве базовой версии. Разработка требований считается не важной в проектах следующего поколения или при переделке предыдущих проектов. Разработчикам иногда рекомендуют использовать существующий продукт в качестве источника требований, со списком изменений и дополнений. Это вынуждает их собирать требования через инженерный анализ текущего проекта. Однако это не эффективный и не полный способ выявления требований, поэтому не удивляйтесь, если у новой системы проявятся некоторые недостатки исходной системы. Документируйте требования, извлекаемые таким способом, и просите клиентов проверить их, чтобы убедиться, что они верны и до сих пор актуальны. Решения, предлагаемые в качестве потребностей. Предлагаемые пользователями решения могут скрывать их действительные нужды, вести к повтору неэффективных бизнес-процессов и заставлять разработчиков принимать плохие конструкторские решения. Задача аналитика — докопаться до потребности клиента, скрытой предлагаемым решением. Анализ требований Определение приоритетов требований. Удостоверьтесь, что каждое функциональное требование, функция или вариант использования получило приоритет и приписано к конкретной версии или итерации системы. Оцените приоритет каждого нового требования по отношению к объему оставшейся работы, чтобы иметь возможность принимать разумные решения о компромиссах. Технически сложные функции. Оцените осуществимость каждого требования, чтобы определить те из них, реализация которых может занять больше времени, чем ожидается. Нам всегда кажется, что успех — рядом, за углом, поэтому трассируйте статус проекта, чтобы следить за требованиями, реализация которых отстает от графика. Старайтесь исправлять ситуацию как можно раньше. Незнакомые технологии, методы, языки, инструменты или аппаратное обеспечение. Не нужно недооценивать кривую обучения работе с новыми методами, необходимыми для удовлетворения некоторых требований. Выявляйте эти рискованные требования в начале проекта и выделяйте достаточное время на фальстарты, обучение, эксперименты и прототипирование. Спецификация требований Понимание требований. Различия в интерпретации требований разработчиками и клиентами ведут к расхождениям в ожиданиях, когда произведенный продукт не способен удовлетворить нужды клиентов. Формальная экспертиза документации требований разработчиками, тестировщиками и клиентами уменьшают этот риск. Подготовленные, опытные аналитики требований могут задать клиентам верные вопросы и составить высококачественные спецификации. Модели и прототипы, представляющие требования с разных точек зрения, также позволяют выявить неясные, неопределенные требования. Спешка, заставляющая пропускать пометки «TBD». Полезно выделять области спецификации требований, которые требуют доработки специальными пометками, например «TBD», но рискованно начинать конструирование, пока они не сняты. Записывайте имя человека, отвечающего за разрешение каждой неясности и планируемые сроки разрешения. Неоднозначная терминология. Создайте словарь для определения бизнес- или технических терминов, которые могут быть истолкованы разными читателями по-разному. В частности, определите любые термины, имеющие как общее, так и техническое или узкоспециальное значения. Создайте словарь данных, где определяются элементы и структуры данных. Экспертиза спецификации требований поможет участникам выработать общее понимание ключевых терминов и концепций. Включение дизайна в требования. Описание дизайна в спецификации требований налагает ненужные ограничения на возможности, доступные разработчикам. А те сдерживают создание оптимальных конструкций. Удостоверьтесь, что требования описывают, что необходимо сделать для решения бизнес-проблемы, а не то, как это должно быть сделано. Утверждение требований Неутвержденные требования. Перспектива утверждения длинной спецификации требований пугает, как и мысль о написании вариантов тестирования в самом начале процесса разработки. Тем не менее, если вы подтвердите корректность и качество требований до начала конструирования, то сможете избежать значительной и дорогой переделки на более поздних стадиях проекта. Выделите время и ресурсы на эти действия в план проекта. Обяжите представителей клиентов участвовать в проверке требований, потому что только они могут судить, удовлетворят ли сформулированные требования их нужды. Также проводите пошаговые, неформальные экспертизы, чтобы выявлять проблемы как можно раньше и дешевле. Качество проверки. Если проверяющие не знают, как проводить экспертизу документации требований и какие действия эффективны при проверке, они могут упустить серьезные дефекты. Обучайте всех членов команды, которые будут участвовать в экспертизе. Пригласите человека с опытом проверки из вашей или сторонней организации для наблюдения и, возможно, координации ваших первых опытов, чтобы тренировать участников. Управление требованиями Изменение требований. Вы можете уменьшить расползание границ проекта, используя документ о его образе и границах в качестве контрольных точек для утверждения изменений. Объединение выявления требований с существенным участием пользователей может сократить расползание требований примерно вполовину. Методы контроля качества, определяющие ошибки в требованиях на ранних стадиях, сокращают количество последующих модификаций. Чтобы уменьшить влияние изменения требований, отложите реализацию тех из них, которые, скорее всего, изменятся, пока они не будут определены, а также проектируйте систему, закладывая возможность легкой модернизации. Процесс изменения требований. Риск, связанный с тем, как происходит изменение требований, зависит и от отсутствия определенного процесса изменений, использования неэффективных механизмов изменений и внесения коррективов без учета этого процесса. Развитие культуры и дисциплины управления изменениями требует времени. Очень важно, чтобы при изменении требований применялся анализ воздействия предлагаемых изменений, решения принимал совет по управлению изменениями и использовалось инструментальное средство для поддержки определенной процедуры. Нереализованные требования. Матрица трассируемых требований помогает избежать пропуска каких-либо требований во время проектирования, конструирования или тестирования. Увеличение объема проекта. Если требования изначально плохо определены, дальнейшее их выявление может увеличить объем проекта. Реализация нечетко определенных областей продукта потребует больше усилий, чем ожидалось. Ресурсы проекта, распределенные в соответствии с начальным неполным требованиям, могут оказаться недостаточными для удовлетворения полного спектра нужд пользователя. Для смягчения этого риска планируйте жизненный цикл, состоящий из поэтапных или разработанных средствами инкрементального моделирования версий. Реализуйте базовую функциональность в первом выпуске и наращивайте способности системы далее. Управление риском — ваш друг Менеджер проекта может использовать управление риском, чтобы выяснить условия, которые могут повлечь неблагоприятные последствия для проекта. Представьте себе менеджера нового проекта, озабоченного привлечением нужных пользователей в выявление требований. Если он умен, то сообразит, что это условие представляет собой элемент риска, и внесет его в список, оценив его вероятность и влияние, основываясь на предыдущем опыте. Если по прошествии некоторого времени пользователи все еще не вовлечены в работу над проектом, риск возрастет и, может быть, даже уже угрожает успеху проекта. Мне удавалось убеждать менеджеров отложить проект, когда не удавалось привлечь достаточно представителей пользователей, приводя такой аргумент; мы не должны впустую тратить деньги компании на заранее обреченный проект. Периодическое трассирование рисков позволяет менеджеру проекта знать масштабы угрозы от выявленных областей риска. Сообщайте о недостаточно контролируемом риске вышестоящему руководству, которое может принять решение исправить его либо продолжать работу, несмотря на риск. Управление риском помогает вам держать глаза открытыми и принимать обоснованные решения, даже если вам не удается контролировать каждую неприятность, с которой может столкнуться ваш проект. |