Сбор и анализ требований к ПО

Сбор и анализ требований к ПО Определение концепции продукта. Сбор требований. Анализ требований. Проектирование системы. Процесс работы с требованиями к продукту можно разделить на 4 этапа: Определение концепции продукта На этапе определения концепции продукта, проводится работа с его инвестором, целью которой является выработка единого видения будущего продукта. По окончанию этого этапа производится вывод о том, будет ли этот продукт разрабатываться или нет. Сбор требований На этапе сбора требований основная работа ведется с заказчиком системы и еѐ будущими пользователями. Цель этапа — точно определить функции продукта и способы его интеграции в существующие процессы. Качественное выполнение работ на этом этапе гарантирует то, что будущий продукт будет соответствовать ожиданиям заказчика. Четкая расстановка приоритетов обеспечивает реализацию наиболее востребованной функциональности и исключение второстепенной/невостребованной функциональности, что сэкономит бюджет и сроки. Анализ требований На этапе анализа требований проходит структуризация уже собранных ранее требований. Цель этапа — предоставить четкий список не дублируемых требований к системе, которые должны быть выделены из избыточных и частично дублирующихся сценариев и пользовательских историй, которые были полученных на предыдущем этапе. Правильно сгруппированные требования помогут обойтись минимальным количеством функционала для удовлетворения максимально большего количества целей, а это, в свою очередь, поможет сэкономить бюджет и не даст расползтись рамкам проекта. Целью всех предыдущих этапов был сбор информации о том, кому и зачем необходим будущий продукт. Этап проектирования — это первый этап, на котором группа разработки принимает проектные решения о том, какую функциональность будет нести продукт, чтобы удовлетворить пользователей. Проектирование системы Результатом этого этапа является законченное техническое задание к продукту. Оно должно содержать полное описание поведения будущего продукта и не содержать неоднозначностей и вопросов. На основе технического задания начинается моделирование работы продукта с конечными пользователями (используя макеты пользовательского интерфейса, к примеру) и производится тестирование технического задания. Это позволяет увеличить качество продукта и снизить его стоимость, так как стоимость внесения изменений в техническое задание всегда меньше, чем в конечный продукт. Интеграция в жизненный цикл разработки продукта Этап определения концепции продукта обычно выделяется в отдельный проект или является первым этапом в разработке продукта. На этапе определения концепции считается, что идея уже родилась, еѐ лишь надо развить и формализовать, а потому этот процесс может занимать от недели до месяца. Для проектов, с общей продолжительностью 6–12 месяцев, это срок обычно около 2–3 недель. После определения концепции проекта уже можно экспертно оценить необходимые ресурсы для выполнения проекта и срока, за который он будет выполнен, а также его прибыльность. Точность оценки полностью зависит от опыта людей, дающих оценку, но, как правило, не превышает 50%. Срок формирования концепции особенно критичен для продуктов, разрабатываемых под заказ, так как подписание контракта, как правило, происходит по завершении этой стадии. Место требований в жизненном цикле проекта, на примере каскадного процессов Место требований в жизненном цикле проекта, на примере итеративного процессов Анализ требований Это процесс сбора требований к программному обеспечению, их систематизации, документирования, анализа, выявления противоречий, неполноты, разрешения конфликтов. Полнота и качество анализа требований играют ключевую роль в успехе всего проекта. В рамках этой стадии происходит максимально эффективное взаимодействие нуждающегося в программном решении клиента и сотрудников компании-разработчика, в ходе обсуждения деталей проекта помогающих более четко сформулировать предъявляемые к ПО требования. Сбор требований – общение с клиентами и пользователями, чтобы определить, каковы их требования; анализ предметной области. Анализ требований – определение, являются ли собранные требования неясными, неполными, неоднозначными или противоречащими; решение этих проблем; выявление взаимосвязи требований. Документирование требований – требования могут быть задокументированы в различных формах, таких как простое описание, сценарии использования, пользовательские истории, или спецификации процессов Анализ требований включает три типа деятельности: 1. Разработки требований 2. Выявление 3. Анализ 4. Спецификация 5. Проверка 6. Управления требованиями Анализ требований включает в себя следующие фазы: Бизнес-требования Бизнес-требования представляют высший уровень абстракции в цепи требований: они определяют концепцию решения и границы проекта, в котором оно будет реализовываться. Пользовательские и функциональные требования к ПО должны находиться в соответствии с контекстом и целями, устанавливаемыми бизнестребованиями. Требования, не содействующие достижению бизнес-целей проекта, реализовываться не должны. Проект, в котором нет четко определенного и согласованного направления, можно смело назвать кандидатом на провал. Участники проекта могут, сами того не осознавая, решать прямо противоположные задачи, если у них разные бизнес-цели и приоритеты. Лица, заинтересованные в проекте, никогда не смогут договориться о составе требований, если они не выработали общего понимания бизнес-целей. Без четкого понимания с самого начала график и бюджет проекта скорее всего выйдут за намеченные рамки. Формулировка бизнес-требований Термин бизнес-требования (business requirements) относится к информации, которая в совокупности описывает потребность, которая инициирует один или больше проектов, призванных предоставить решение и получить требуемый конечный бизнес-результат. В основе бизнес-требований лежат бизнес-возможности, бизнес-цели, критерии успеха и положение о концепции Вопросы бизнес-требований должны решаться до окончательного определения функциональных и нефункциональных требований. Положение о рамках и ограничениях проекта сильно помогает в обсуждениях предлагаемых функций и целевых выпусков. Бизнес-требования являются отправной точкой для принятия решений о предложенных изменениях и улучшениях требований. Определение требуемых бизнеспреимуществ Бизнес-требования определяют контекст и позволяют измерять преимущества, которые организация ожидает получить от реализации проекта. Организации не должны инициировать проект без ясного понимания пользы, которую он принесет для бизнеса. Определяйте измеряемые ориентиры на основе бизнес-целей, после чего определяйте критерии успеха, который позволят оценивать, находитесь ли вы на пути достижения этих целей. Определение требуемых бизнеспреимуществ Бизнес-требования могут исходить от: • финансирующих проект заказчиков, • топ-менеджеров, • менеджеров по маркетингу •ответственных за концепцию продукта. Бизнес-аналитик должен обеспечить, чтобы бизнес-требования определяли правильные заинтересованные лица и организовать сбор, приоритизацию и разрешение конфликтов. Бизнес-преимущества должны представлять реальную пользу для кураторов и клиентов проекта. Два базовых элемента бизнестребований Концепция продукта Границы проекта Концепция продукта (product vision) сжато описывает конечный продукт, который достигнет заданных бизнесцелей. Этот продукт может полностью удовлетворять бизнес-требованиям или быть только частью решения. Концепция описывает, что продукт представляет собой сейчас и каким он станет впоследствии. Она обеспечивает контекст для принятия решений на протяжении жизненного цикла продукта и выстраивает работу всех заинтересованных лиц в одном направлении. Границы проекта (project scope) показывают , на какую часть конечной концепции продукта будет направлен текущий проект или итерация. В положении о границах определена черта между тем, что входит в проект и тем, что остается вовне. Концепция продукта гарантирует, что мы все знаем, куда идем. Границы проекта гарантируют, что мы говорим об одной и той же вещи в текущем проекте или спринте. Концепция решает задачу У команды могут быть ясные цели, создается спецификация, выполняется разработка и тестирование, но на протяжении проекта никто не проводит проверку на предмет соответствия целям. Заинтересованное лицо может предложить «блестящую» новую функцию, которую хочет реализовать. Команда добавляет ее, потому что это кажется разумным и интересным. Но несколько месяцев спустя оказывается, что несмотря на наличие массы крутых функций система не решает исходной задачи. Говоря о концепции, подразумевается весь продукт. Он будет изменяться относительно медленно при определении со временем стратегии продукта или развитии бизнес-целей. Концепция решает задачу Границы же относятся к определенному проекту или его итерации, в которых реализуются возможности продукта. Границы более динамичны, чем концепция, так как заинтересованные лица изменяют содержимое каждой версии в соответствии с ограничениями графика, бюджета, ресурсов и качества. Границы текущего выпуска должны быть четко определены, но границы будущих выпусков тем менее четко определены, чем более дальняя перспектива рассматривается. Задача команды состоит в управлении границами конкретного проекта разработки или улучшения как определенным подмножеством стратегической концепции продукта. Концепция продукта охватывает границы каждого запланированного выпуска и тем менее четко определена, чем более дальняя перспектива рассматривается Противоречивые бизнестребования Бизнес-требования, собранные из многих источников, могут быть противоречивыми. Противоречивые бизнес-требования Трения между заинтересованными лицами с разными целями и ограничениями ведут к конфликтующим бизнестребованиям. Лица, ответственные за принятие решений, должны разрешить эти конфликты до того, как аналитик создаст подробные требования к терминалу. Основное ударение должно быть сделано на предоставлении максимальных бизнес-преимуществ основным заинтересованными лицам. Легко отвлечься на внешние характеристики продукта, которые не соответствуют поставленным бизнес-целям. Лица, ответственные за принятие решений, не должны считать, что разрешением конфликтов между разными заинтересованными лицами будет заниматься команда разработчиков ПО. Документ о концепции и границах Документ о концепции и границах (vision and scope document) собирает бизнестребования в единый документ, который подготавливает основу для последующей разработки продукта. В некоторых организациях с этой же целью создают устав проекта или положение о бизнес-задачах. В организациях, создающих ПО на продажу часто создают документ основных рыночных требований (market requirements document, MRD). В нем более детально, чем в документе о концепции и границах, рассматриваются целевые сегменты рынка и вопросы коммерческого успеха продукта. Владельцем документа о концепции и границах считается куратор проекта, тот, кто финансирует проект, или имеет аналогичную ответственность. Документ о концепции и границах Бизнес-аналитик может вместе с этим человеком разрабатывать документ о концепции и границах. Информация, касающаяся бизнестребований, должна поступать от лиц, четко понимающих, почему они взялись за проект. Это может быть клиент или топ-менеджер организации, разрабатывающей продукт, ответственный за концепцию, менеджер по продукту, эксперт предметной области или специалисты отдела маркетинга. Шаблон документа о концепции и границах 1. Бизнестребования 1.1 Исходные данные 1.2 Возможности бизнеса 1.3 Бизнес-цели 1.4 Критерии успеха 1.5 Положение о концепции проекта 1.6 Бизнес-риски 1.7 Предположения и зависимости 2. Рамки и ограничения проекта 2.1 Основные функции 2.2 Объем первоначально запланированной версии 2.3 Объем последующих версий 2.4 Ограничения и исключения 3. Бизнесконтекст 3.1 Профили заинтересованных лиц 3.2 Приоритеты проекта 3.3 Особенности развертывания Документ концепции и границ Документ концепции и границ определяет границы на высоком уровне, а подробности границ представлены базовыми требованиями отдельных выпусков, определенных командой. Крупные новые проекты должны иметь завершенный документ концепции и границ и спецификацию требований. Каждая итерация, выпуск или проект по улучшению продукта может включать собственное положение о границах в документации требований к проекту, при этом создавать отдельный документ концепции и границ необязательно. 1. Бизнес-требования Проекты запускаются с полным убеждением, что новый продукт сделает мир для кого-то лучше и обеспечит прибыль. Бизнес-требования описывают основные преимущества, которые новая система даст ее заказчикам, покупателям и пользователям. Бизнес-требования непосредственно влияют на то, какие пользовательские требования будут реализованы и в какой последовательности. 1.1 Исходные данные Они суммируют обоснование и содержание нового продукта или изменения, которые нужно внести в существующий продукт. Здесь помещают общее описание предыстории или ситуации, в результате чего было принято решение о создании продукта. 1.2 Возможности бизнеса Для корпоративной информационной системы описывают бизнес-задачу, которая решается посредством этого продукта, или бизнес-процессы, для улучшения которых требуется продукт, а также среду, в которой система будет использоваться. Для коммерческого продукта описывают существующие рыночные возможности и рынок, на котором продукту придется конкурировать с другими продуктами. Этот раздел может содержать сравнительную оценку существующих продуктов и возможных решений, указывая, в чем заключается привлекательность продукта и его преимущества. Содержит: •задачи, которые не удается разрешить без предлагаемого решения. •соответствие тенденциям рынка, развитию технологий или корпоративной стратегии. технологии, •процессы • ресурсы, необходимые для удовлетворения клиента. 1.3 Бизнес-цели Суммирует важные преимущества бизнеса, предоставляемые продуктом, в количественном и измеряемом виде. Банальности («стать компанией мирового класса») и нечетко сформулированные улучшения («обеспечить высокий уровень сервиса для клиентов») нельзя считать ни полезными, ни поддающимися проверке. Финансовые цели Нефинансовые цели Освоить X% рынка за Y месяцев Достигнуть показателя удовлетворения покупателей, равного по крайней мере X, в течение Y месяцев со времени выпуска продукта Увеличить долю рынка в стране W с X% до Y% за Z месяцев Увеличить производительность обработки транзакций на X% и снизить уровень ошибок данных до величины не более Y% Достигнуть объема продаж X единиц или дохода в Y Разработать надежную платформу для семейства долларов за Z месяцев связанных продуктов Получить X% прибыли по инвестициям в течение Y месяцев Разработать специальную базовую технологическую основу для организации Достигнуть положительного потока денежных средств по этому продукту в течение Y месяцев Добиться признания продукта лучшим по надежности в опубликованных обзорах продуктов к определенной дате Сэкономить X долларов в год, которые в настоящий момент расходуются на обслуживание унаследованной системы Обеспечение выполнения определенных нормативов регулирующих органов Получить не более X звонков в службу обслуживания Уменьшить затраты на поддержку с X до Y долларов по каждой единице товара и Y звонков по гарантии за Z месяцев каждой единице товара в течение Z месяцев после выпуска продукта Увеличить валовую маржу для существующего бизнеса с X до Y% в течение одного года Уменьшить время выполнения заявки до X часов на Y% звонков в службу поддержки Примеры финансов ых и нефинансо вых бизнесцелей 1.4 Критерии успеха Установите факторы, которые максимально влияют на успех проекта — те, которые организация может контролировать, и те, которые находятся вне сферы ее влияния. Бизнес-цели иногда невозможно измерить, пока не завершиться проект. В других случаях достижение бизнес-целей может зависеть от других проектов. Критерии успеха указывают, находится ли проект на пути достижения бизнес-целей. Эти критерии могут определяться во время тестирования или сразу после выпуска продукта. Внимательно выбирайте критерии успеха. Убедитесь, что они оценивают то, что важно для бизнеса, а не просто то, что легко оценить. Критерий «Сократить затраты на производство продукта на 20%» легко оценить. Его также легко реализовать путем увольнения сотрудников или сокращения инвестиций в инновации. Но это могут быть не те результаты, которые подразумевались в целях. Пример модели бизнес-целей для системы контроля химикатов 1.5 Положение о концепции Положение о концепции проекта обобщает долгосрочные цели и назначение нового продукта. Она может быть несколько идеалистичной, но должна основываться на существующих или предполагаемых рыночных факторах, архитектуре предприятия, стратегическом направлении развития корпорации или ограничениях ресурсов. Шаблон для документа о концепции продукта: Для [целевая аудитория покупателей]; Который [положение о потребностях или возможностях]; Эта (этот) [имя продукта]; Является [категория продукта]; Который(ая) [основные функции, ключевое преимущество, основная причина [для покупки или использования]; В отличие от [основной конкурирующий продукт, текущая система или текущий бизнеспроцесс]; Наш продукт [положение об основном отличии и преимуществе нового продукта]. 1.6 Бизнес-риски В категорию рисков входят: •рыночная конкуренция, • временные факторы, • приемлемость для пользователей, • проблемы, связанные с реализацией, • возможные негативные факторы, влияющие на бизнес. Бизнес-риски отличаются от рисков проекта, которые обычно связаны с доступностью ресурсов и особенностями технологий. Данный раздел содержит: • оценку возможных потерь от каждого фактора риска, •вероятность его возникновения, •способность контролировать его, •все возможные действия по смягчению ситуации. 1.7 Предположения и зависимости Предположение (assumption) — это утверждение, которое предполагается верным в отсутствие знаний или доказательств иного. Бизнес-предположения тесно связаны с бизнес-требованиями. Неверные предположения могут не позволить достичь поставленных бизнес-целей. Например, куратор из руководства компании может поставить бизнес-цель увеличить доход на 100 тыс. долларов в месяц. Определяя такую цифру, куратор сделал определенные предположения, например что новый сайт будет привлекать 200 дополнительных уникальных посетителей в день и что каждый посетитель в среднем будет тратить 17 долларов. Если новый сайт не привлечет достаточно посетителей, тратящих достаточное количество денег, проект может не достичь своей бизнес-цели. Если окажется, что те или иные предположения не оправ дались, можете изменить границы или график проекта или запустить другие проекты, чтобы достичь другие цели. 1.7 Предположения и зависимости Рекомендуется задокументировать важнейшие зависимости проекта от внешних факторов — изменения отраслевых стандартов или предписаний регулирующих органов, других проектов, сторонних поставщиков или партнеров по разработке. Предположения и зависимости бизнеса могут превратиться в риски, которые должен регулярно отслеживать менеджер проекта. Нарушение зависимостей — популярная причина задержек проекта. Необходимо описать возможные последствия того, что предположения окажутся ошибочными или зависимости нарушены, чтобы заинтересованные лица могли понять, почему это так важно. 2. Рамки и ограничения проекта Границы проекта определяют концепцию и круг действия предложенного решения. В ограничениях указываются определенные возможности, которые не будут включены в продукт. Рамки и ограничения помогают установить реалистичные ожидания заинтересованных лиц, потому что иногда клиенты запрашивают функции, слишком дорогостоящие или выходящие за предполагаемые границы продукта. Рамки проекта могут представляться различными способами. На самом высоком уровне границы определяются, когда клиент решает, какие бизнес-цели преследовать. На низком уровне границы определяются на уровне функций, пользовательских историй, вариантов использования или событий и реакции на них. В конечном итоге границы определяются через набор функциональных требований, которые планируется реализовать в определенном выпуске или итерации. На каждом уровне границы не должны выходить за рамки более высокого уровня. Например, находящиеся в границах пользовательские требования должны соответствовать бизнес-целям, а функциональные требования — пользовательским требованиям в заданных границах. 2.1 Основные функции Описывают основные функции продукта или возможности пользователей, уделив основное внимание тому, что отличает продукт от предыдущей версии или конкурирующих продуктов. Показывают, как пользователи будут работать с этими функциями, чтобы убедиться, что список функций полон и не содержит ненужных функций, которые интересны, но не приносят пользы пользователям. Необходимо назначить каждой функции уникальное и постоянное название, чтобы ее можно было отслеживать в других компонентах системы. 2.2 Объем первоначально запланированной версии Обобщает основные запланированные функции, включенные в первоначальную версию продукта. Границы проекта обычно определяются как набор функций, но их можно также определять в терминах пользовательских историй, вариантов использования, потоков вариантов использования или внешних событий. Также можно описать характеристики качества, которые позволят продукту предоставлять предполагаемые преимущества различным классам пользователей. Всегда необходимо сосредоточиться на наиболее ценных функциях, имеющих максимально приемлемую стоимость, годных для самой широкой целевой аудитории, которые удастся создать как можно раньше. 2.3 Объем последующих версий Если вы ожидается поэтапная эволюция продукта или если используется итеративная модель разработки — создается план выпуска, в котором указывается, какие функции будут отложены и желательные сроки последующих выпусков. В последующих версиях можно реализовать дополнительные варианты использования и функции и расширить возможности первоначальных вариантов использования и функций. Чем на дольний срок планируется, тем более расплывчатыми будут границы проекта. Короткие циклы выпусков часто предоставляют удобные случаи для накопления знаний, основанных на отзывах клиентов. 2.4 Ограничения и исключения В данном разделе перечислены все возможности или характеристики, которых могут ожидать заинтересованные в проекте лица, но включение которых в продукт или в определенную версию не запланировано. Необходимо перечислить изъятые элементы, чтобы не забыть решения по границам проекта. Если пользователь запросил возможность доступа к системе с телефона, когда он не находится на рабочем месте, и эта функция была признанной не входящей в границы проекта, тогда четко запишите в соответствующем разделе: «Новая система не поддерживает доступа с мобильных устройств». 3. Бизнес-контекст В этом разделе представлены профили основных категорий заинтересованных лиц, приоритеты руководства в проекте, а также сводка некоторых обстоятельств, которые надо учесть при планировании развертывания решения. 3.1 Профили заинтересованных лиц Заинтересованными в проекте лицами (stakeholders) называются отдельные лица, группы или организации, которые активно вовлечены в проект, на которых влияет результат проекта и которые сами могут влиять на этот результат. Профили заинтересованных лиц описывают различные категории клиентов и других ключевых лиц, заинтересованных в этом проекте: различные группы клиентов, целевые рыночные сегменты и различные классы пользователей, входящих в эти сегменты. В профиль каждого заинтересованного в проекте лица включается следующая информация: •основная ценность или преимущество, которое продукт принесет заинтересованным лицам; •как продукт удовлетворит покупателей. Ценность для заинтересованных лиц представляют: повышенная производительность; меньшее количество переделок; снижение себестоимости; ускорение бизнес-процессов; автоматизация задач, ранее выполнявшихся вручную; возможность выполнять совершенно новые задачи; соответствие соответствующим стандартам и правилам; лучшая, по сравнению с текущими продуктами, легкость и простота использования; их самые важные для них функции и характеристики; все известные ограничения, которые должны быть соблюдены. Можно включить поименный список ключевых заинтересованных лиц для каждого профиля или структурную схему организации, показывающую отношения между заинтересованными лицами в организации. 3.2 Приоритеты проекта Чтобы принимать эффективные решения, заинтересованные лица должны договориться о приоритетах проекта. Один из подходов к этому заключается в рассмотрении пяти измерений: • функции (или объем), • качество, • график, •затраты, •кадры. В любом проекте каждое из измерений относится к одной из трех категорий: •ограничение — сдерживающий фактор, в рамках которого должен оперировать менеджер проекта; •ведущий фактор — важный фактор успеха, ограниченно гибкий при изменениях; •степень свободы — возможность для менеджера проекта до определенной степени менять измерение и балансировать относительно других измерений. Задача менеджера проекта — скорректировать те факторы, которые представляют собой степени свободы для достижения ключевых факторов успеха проекта в рамках, налагаемых ограничениями Пример Представьте себе, что отдел маркетинга неожиданно требует создать продукт на месяц раньше срока. Какова будет ваша реакция? Возможные варианты ответов: •Вы отложите реализацию определенных требований до более поздней версии. •Сократите запланированный цикл тестирования системы. •Оплатите сверхурочную работу ваших специалистов или пригласите специалистов по контракту для ускорения разработки. •Привлечете ресурсы других проектов для разрешения ситуации. •Ваши действия в подобных ситуациях зависят от приоритетов проекта. В реальности при возникновении изменения вам нужно поговорить с ключевыми заинтересованными лицами, чтобы определить ответные действия. Например, отдел маркетинга может потребовать добавить новые функции или сократить длительность проекта, возможно в обмен на отказ от реализации некоторых функций. 3.3 Особенности развертывания Необходимо перечислить информацию и действия, необходимые для обеспечения эффективного развертывания решения в рабочую среду. Описывается доступ, который потребуется пользователями для работы с системой, в частности, находятся ли они далеко в разных часовых поясах или недалеко друг от друга. Указывается, когда пользователям в разных местах нужен доступ к системе. Если требуются изменения инфраструктуры, чтобы обеспечить потребности ПО в мощностях, доступе к сети, хранилищу данных и миграции данных, опишите эти изменения. Фиксируется вся информация, которая потребуется тем, кто будет готовить бизнес-процессы обучения и модификации в связи с развертыванием нового решения.