Разработка требований к программному обеспечению

Beschreibung

Эта книга - подробное руководство по разработке качественных требований к программному обеспечению. Здесь описаны десятки проверенных на практике приемов выявления, формулирования, разработки, проверки, утверждения и тестирования требований, которые помогут разработчикам, менеджерам и маркетологам создать эффективное ПО. Настоящее издание дополнено новыми приемами, посвященными разработке требований в проектах гибкой разработки (agile). Основная аудитория - бизнес-аналитики и разработчики, а также дизайнеры, программисты, тестировщики и другие члены команды, задача которых понять и удовлетворить чаяния клиентов, а также маркетологи, менеджеры по продуктам и менеджеры проекта, которые должны проникнуться "духом" и особенностями продукта, чтобы сделать его в полной мере конкурентоспособным. Книга состоит из 32 глав, 3 приложений и словаря терминов.

Rezensionen ( 0 )
Once a month we give presents to the most active reader.
Post more reviews and get a reward!
Zitate (48)
48 Zitate Um ein Zitat hinzuzufügen, müssen Sie sich .
Потратив на это
достаточно времени, вы можете быть уверены, что свели к минимуму риск
переделки продукта, создания негодного ПО или срыва сроков сдачи про-
екта. Эта книга научит вас, как объединить усилия нужных людей для раз-
работки качественных требований к нужному продукту
Многие ис-
следования показывают, что на ошибки, внесенные на этапе сбора требова-
ний, приходится от 40 до 50% всех дефектов, обнаруженных в программном
продукте (Davis
Так как требования пред-
ставляют собой основу для действий и разработчиков и менеджеров проек-
та, все заинтересованные в проекте лица должны быть вовлечены в создание
этого документа
Требования это спецификация того, что должно быть реализовано.
В них описано поведение системы, свойства системы или ее атрибуты.
Они могут служить ограничениями в процессе разработки системы.
Это определение учитывает самые разные типы информации, которые в со-
вокупности называются требованиями. Требования охватывают как видение
пользователя, так и внешнее поведение системы, а также представление раз-
работчика о некоторых внутренних характеристиках. Они включают как по-
ведение системы в определенных условиях, так и свойства, которые делают
систему полезной и даже доставляющей удовольствие конечным операторам.
Внимание! Не рассчитывайте, что все заинтересованные лица вашего проекта раз-
деляют общее представление о том, что же такое требования. Задайте определения с
самого начала, чтобы вы все говорили на одном языке
Требования к ПО включают измерение времени. Они могут относиться к
настоящему времени — в этом случае они описывают текущие функции си-
стемы. Или могут относиться к ближайшему (высокоприоритетные), сред-
нему (средреприоритетные) или гипотетическому (низкоприоритетные)
будущему. Они могут даже относиться к прошлому времени, когда описыва-
ют запросы, которые были ранее определены, а затем отброшены. Не стоит
тратить время на споры является ли что-то требованием или нет, даже если
вы знаете, что оно скорее всего не будет реализовано по какой-то серьезной
причине. Это требование и точка
Такое соотношение между тремя уровнями требований жизненно важно для
успеха проекта
Можно создать продукт, обладающий всей требуемой функционально-
стью, но пользователи могут невзлюбить его за то, что тот не соответству-
ет их (обычно невысказанным) ожиданиям по качеству
Важно понимать ценность письменной фиксации жизненно важных тре-
бований в доступной для совместного использования форме, а не сведений,
передающихся от человека к человеку изустно. Однажды я работал над про-
ектом, в котором часто менялись команды разработчиков. Основной заказ-
чик был недоволен тем, что из каждой новой команды к нему приходили со
словами: «Нам надо поговорить о требованиях». Его реакция на этот запрос
звучала так: «Я уже рассказал вашим предшественникам о моих требовани-
ях. Так что просто займитесь созданием системы!» К сожалению, никто не
потрудился задокументировать никаких требований, поэтому каждой новой
SR3_ch_01.indd 13 SR3_ch_01.indd 1330.04.2014 12:06:2630.04.2014 12:06:2614 Часть I Требования к ПО: что, почему и кто
команде приходилось начинать с нуля. По крайней мере безответственно за-
являть, что у вас «есть требование», если на самом деле у вас несколько со-
общений электронной почты и голосовой почты, ряд записок-наклеек, про-
токолы совещаний и туманные воспоминания о разговорах с заказчиком.
Аналитик должен выработать осмотрительный подход для определения, на-
сколько полной должна быть документация требований в том или ином про-
екте
выявление пробелов в требованиях или излишних требований, не соот-
• ветствующих заданным рамкам
Анализ требований (analyzing requirements) подразумевает получение более
обширного и точного понимания всех требований и представление наборов
требований в различном виде. Далее перечислены основные действия:
• анализ информации, полученной от пользователей, чтобы отделить их
задачи от функциональных и нефункциональных требований, бизнес-
правил, предполагаемых решений и другой информации;
• разложение высокоуровневых требований до нужного уровня детализации;
• выведение функциональных требований из информации других требова-
ний;
• понимание относительной важности атрибутов качества;
• распределение требований по компонентам ПО, определенным в систем-
SR3_ch_01.indd 17 SR3_ch_01.indd 1730.04.2014 12:06:2730.04.2014 12:06:2718 Часть I Требования к ПО: что, почему и кто
ной архитектуре;
согласование приоритетов реализации;
• выявление пробелов в требованиях или излишних требований, не соот-
• ветствующих заданным рамкам
Документирование требований предусматривает представление и хранение
совокупного знания о требованиях постоянным и хорошо организованным
способом. К ключевому действию относится:
• преобразование собранных потребностей пользователей в письменные
требования и диаграммы, пригодные для понимания, анализа и использо-
вания целевой аудиторией
Итерация — ключевое условия успеха разработки. При планировании
нужно предусмотреть не один цикл проверки требований для поступатель-
ного уточнения деталей высокоуровневых требований и подтверждения пра-
вильности пользователями. На это может уходить много времени, и подоб-
ная деятельность может быть не очень захватывающей, но это неизбежная
процедура разрешения всех неясностей при определении новой программ-
ной системы.
Внимание! Вы никогда не сможете создать идеальные требования. С практической
точки зрения цель разработки требований — накопить общее понимание требований,
достаточно хорошее для создания очередной порции продукта — будь то один или
сто процентов, чтобы продолжить работу при разумном уровне риска. Основной риск
заключается в наличии большого объема незапланированных недоделок, потому что
команда недостаточно глубоко разобралась с требованиями к очередному этапу рабо-
ты перед началом проектирования и разработки
Самая сложная часть построения систем ПО — решить точно, что
же создавать. Никакая другая часть концептуальной работы не явля-
SR3_ch_01.indd 19 SR3_ch_01.indd 1930.04.2014 12:06:2730.04.2014 12:06:2720 Часть I Требования к ПО: что, почему и кто
ется такой трудной, как выяснение деталей технических требований,
в том числе и взаимодействие с людьми, механизмами и иными систе-
мами ПО. Никакая другая часть работы так не портит результат,
если она выполнена плохо. Никакая другая часть не дает более труд-
ные для исправления ошибки
Зачастую невозможно — или не нужно — полностью определить требо-
вания до начала проектирования и реализации. В этом случае действуйте
итеративно и постепенно: разрабатывайте одну порцию требований за раз
и обязательно дожидайтесь ответной реакции заказчика, прежде чем при-
ступать к следующему циклу. Это суть разработки по гибкой методологии —
выяснение ровно такого объема требований, чтобы выполнить разумную
приоритизацию и планирование выпуска, чтобы команда могла максимально
быстро начинать создавать ценное ПО. Это не может служить оправданием
написания кода до изучения требований перед следующим шагом. Итерации
при кодировании стоят гораздо дороже, чем при разработке концепций
Люди иногда предпочитают не тратить время на написание требований,
но этот этап не самый сложный. Самое трудное — выявить эти требования.
Первоначально написание требований представляет собой процесс выясне-
ния, разработки и расшифровки данных. Четкое понимание требований к
продукту дает вам уверенность, что ваша команда работает над теми пробле-
мами, над которыми нужно, и создает лучшее их решение. Не зная, что собой
представляют требования, вы не сможете определить момент окончания про-
екта, установить, достигнуты ли цели, или выбрать компромиссное решение,
когда придется корректировать границы проекта. Вместо того, чтобы отка-
зываться от затрат времени на создание требований, откажитесь от потерь
денег из-за недостаточного внимания к требованиям в проекте
Многие люди ошибочно считают, что время, которое тратится на обсуждение
требований, просто отсрочивает выпуск продукта. Они предполагают, что ра-
бота с требованиями не повышает рентабельность проекта. На самом деле,
затраты на получение хороших требований практически всегда возвращают-
ся с излишком
Наибольшая инвестиция — это время, которое ваша
команда тратит на сбор, документирование, просмотр и управление требова-
ниями. Возможные выгоды таковы:
• меньше дефектов в требованиях и в готовом продукте;
• меньше переделок;
• быстрее разработка и поставка готового продукта
меньше ненужных и неиспользуемых функций;
• ниже стоимость модификации;
• меньше недопонимания;
• меньше расползание границ проекта;
• меньше беспорядок в проекте;
• выше удовлетворение заказчиков и членов команды;
• продукты, которые делают то, что от них ожидается.
Даже если вы не можете количественно оценить все преимущества, они
все равно реальны
Я знаю проект, в котором на финальном этапе выявления требований при
проверке правильности потока процессов аналитик поинтересовался у за-
интересованного лица: «Вы уверены в правильности шагов вычисления
налога в этом потоке?» На что получил такой ответ: «Ну, я не знаю. Я не
занимаюсь налогами — для этого есть отдел по налогам». На протяжении
многих месяцев работы над проектом никто из команды не разговаривал
ни с одним сотрудником отдела по налогам. В команде даже не догады-
вались, что такой отдел вообще существует. При встрече с сотрудниками
SR3_ch_02.indd 30 SR3_ch_02.indd 3030.04.2014 12:07:5930.04.2014 12:07:59Требования с точки зрения клиента Глава 2 31
отдела по налогам аналитик обнаружил длинный список пропущенных
требований, связанных с несоответствием реализации налоговой функ-
циональности и требований регулирующих органов. В результате проект
был задержан на несколько месяцев. Подобных неприятностей можно из-
бежать, если заранее ознакомиться со структурной схемой организации и
выявить всех заинтересованных лиц, на работу которых может повлиять
новая система
Клиенты, предоставляющие бизнес-требования, иногда пытаются гово-
рить от имени реальных пользователей, но обычно они слишком далеки от
реальной работы, чтобы описать их точные требования. В случае с информа-
ционными системами или разработкой нестандартного приложения бизнес-
требования должен определять тот, кто в конечном итоге отвечает за пользу
для бизнеса, ожидаемую от продукта. Пользовательские требования должны
определять те, кто будет стучать по клавишам, касаться экрана и получать
результаты работы продукта. В случае серьезного рассогласования между за-
казчиками, оплачивающими проект, и конечными пользователями крупных
проблем не избежать
Возможны конфликты между заинтересованными лицами проекта.
Бизнес-требования иногда отражают организационную стратегию или бюд-
жетные ограничения, которые не всегда понятны пользователям. И те, раз-
драженные тем, что менеджмент насильно внедряет новую информационную
систему, не всегда хотят общаться с разработчиками ПО, считая последних
предвестниками неблагоприятного будущего. Таких пользователей иногда
называют «группами неудачников» (Gause и Weinberg, 1989). Избежать та-
ких трений помогает ясное и полное обсуждение целей и ограничений про-
екта, которое может убедить пользователей и избежать споров и обид
Клиент обязан
1. Ознакомить аналитиков и разработчиков с особенностями вашего бизнеса
2. Потратить столько времени, сколько необходимо на уточнение требований
3. Точно и конкретно описать требования к системе
4. Принимать своевременные решения относительно требований
5. Уважать определенную разработчиком оценку стоимости и возможности
реализации ваших требований
6. Определять реалистичные приоритеты требований совместно с разработчиками
7. Проверять требования и оценивать прототипы
8. Определить критерии приемки
9. Своевременно сообщать об изменениях требований
10. Уважительно относиться к процессам создания требований
Внимание! Не предполагайте, что участники проекта интуитивно знают, как сотруд-
ничать при формулировании требований. Потратьте время и обсудите, каким образом
организовать взаимодействие наиболее эффективно. Хорошо записать, как вы хотите
решать и управлять вопросами требований в проекте. Это послужит ценным сред-
ством коммуникации в проекте
В спецификацию требований к программному обеспечению рекомендуется
включить маркеры «требует прояснения» (to be determined, TBD), указы-
вающие на необходимость дополнительных исследований, анализа и инфор-
мации. Однако иногда такие маркеры используют в случаях, когда конкрет-
ное требование трудно определить точно и никто не хочет с ним возиться.
Попытайтесь прояснить цель каждого требования, чтобы аналитик мог точно
выразить его. Это самый лучший способ гарантировать, что продукт будет
отвечать вашим потребностям
Они мо-
гут не осознавать цену, которую пришлось заплатить при работе в случайной
и неструктурированной среде в прошлом. Цена обычно выражается в неожи-
данных переделках, которые приводят к задержкам выпуска и низкому каче-
ству ПО. Подобные переделки скрыты в ежедневной работе участников про-
екта, поэтому они не считают их серьезной проблемой с эффективностью
Выразите затраты в единицах, понятных в организации, — это могут
быть деньги, недовольство клиентов или потерянные бизнес-возможности.
Менеджеры разработки не всегда понимают, насколько плохо недостатки
требований сказываются на производительности их команд. Поэтому пока-
жите им, как плохие требования замедляют проектирование и ведут к излиш-
ним и недешевым корректировкам курса
Цена обычно выражается в неожи-
данных переделках, которые приводят к задержкам выпуска и низкому каче-
ству ПО. Подобные переделки скрыты в ежедневной работе участников про-
екта, поэтому они не считают их серьезной проблемой с эффективностью
Пытаясь привлечь на свою сторону разработчиков, менеджеров и кли-
ентов, позаботьтесь, чтобы все поняли, сквозь какие неприятности при-
шлось пройти организации и ее клиентам из-за проблем с требованиями.
Представьте конкретные примеры, если люди не испытывали неприятности
лично. Выразите затраты в единицах, понятных в организации, — это могут
быть деньги, недовольство клиентов или потерянные бизнес-возможности.
Менеджеры разработки не всегда понимают, насколько плохо недостатки
требований сказываются на производительности их команд. Поэтому пока-
жите им, как плохие требования замедляют проектирование и ведут к излиш-
ним и недешевым корректировкам курса
Причиной сопротивления изменениям процессов или культуры может
быть страх, неуверенность или недостаток знаний. Если вы сумеете опреде-
лить источник сопротивления, у вас появится возможность бороться с ним
путем увещеваний, объяснений и просвещения. Покажите людям, что их уча-
стие принесет пользу не только им лично, но от этого выиграют все
В выработке соглашения участвует много сторон:
• клиенты должны подтвердить, что требования удовлетворяют их потреб-
ности;
• разработчики подтверждают, что они понимают требования и в состоянии
их реализовать;
• тестировщики подтверждают, что требования поддаются проверке;
• руководство подтверждает, что требования соответствуют их бизнес-целям
Утверждение требований — опера-
ция, которая закрывает прения на определенном этапе создания требований.
Тем не менее, участникам необходимо подтвердить свои слова подписями
Гораздо важнее ритуала подписи концепция создания базового (baseline) со-
глашения о требованиях — снимка такого соглашения на какой-то момент
времени (Wiegers, 2006). Базовое соглашение о требованиях является на-
бором проверенных и согласованных требований, которые служат основой
для дальнейшей разработки. Использует ваша команда формальный процесс
подписи или другие средства достижения соглашения о требованиях, текст
под подписью на странице подтверждения требований должен звучать при-
мерно так:
«Подтверждаю, что настоящий набор требований наилучшим образом
представляет наше понимание требований к этому проекту на данный мо-
мент и что описанная система удовлетворит наши потребности. Я согласен
вносить в будущем изменения в это базовое соглашение в соответствии с про-
цессом изменения требований, определенным в проекте. Я понимаю, что из-
менения могут потребовать переоценки стоимости, ресурсов и сроков сдачи
проекта
После определения базового соглашения о требованиях аналитик должен
разместить требования в системе управления версиями. Это позволит коман-
де при необходимости контролируемым образом изменять границы требова-
SR3_ch_02.indd 44 SR3_ch_02.indd 4430.04.2014 12:07:5930.04.2014 12:07:59Требования с точки зрения клиента Глава 2 45
ний, включая анализ влияния каждого предлагаемого изменения на график
и другие факторы успеха. Скрепив начальные операции по формулированию
требований явным соглашением, вы сплотите клиентов и разработчиков на
пути к успеху проекта
В такой ситуации лучше двигаться вперед, но осторожно, предполагая что у
вас нет одобрения упорствующих заинтересованных лиц. Задокументируйте
тот факт, что определенные заинтересованные лица не завизировали требо-
вания, в своем списке рисков вместе с возможным влиянием от пропуска или
неверности некоторых требований. Работу с этими лицами нужно рассма-
тривать как часть процедур по управлению рисками. В позитивном ключе
упомяните, что вы в курсе, что они пока не одобрили требования, но проект
движется вперед с этими требованиями в качестве базовых, чтобы не задер-
живать работу. Сообщите им, что если они хотят что-то изменить, для этого
есть соответствующий процесс. В сущности, вы действуете так, как будто за-
интересованное лицо согласилось с требованиями, но вы четко отслеживаете
отношения
Пятый подраздел разработки требований — управление требованиями.
К управлению требованиями относятся приемы работы с уже готовыми тре-
бованиями. Эти приемы включают управление версиями и определение ба-
SR3_ch_03.indd 52 SR3_ch_03.indd 5230.04.2014 12:10:0730.04.2014 12:10:07Рекомендуемые приемы формирования требований Глава 3 53
зовых требований, управление изменениями, отслеживание состояния тре-
бований и отслеживание связей требований с другими элементами системы.
Управление требованиями — это деятельность низкой интенсивности, про-
исходящая на всем протяжении проекта
Но даже если вы спланируете традиционный этап «выявления
требований» в начале проекта, после чего требования используются для про-
ектирования, нужно рассчитывать на выполнение небольшого объема работ
с требованиями на протяжении всего проекта
В проектах гибкой разработки (agile) планируется выпускать функцио-
нальность каждые несколько недель (Larman, 2004). В таких проектах работа
над требованиями выполняется часто, но небольшими объемам, как показано
на рис. 3-3 точечной линией. Работа начинается с выявления пользователь-
ских требований в форме пользовательских историй, которые описывают
основные задачи, которые пользователи хотят решить с помощью систе-
SR3_ch_03.indd 53 SR3_ch_03.indd 5330.04.2014 12:10:0730.04.2014 12:10:0754 Часть I Требования к ПО: что, почему и кто
мы. В этом подходе из историй нужно извлечь достаточно информации,
чтобы можно было оценить объем и определить приоритеты разработки.
Приоритизация пользовательских требований позволяет определить, ка-
кие из них назначить на те или иные этапы разработки, которые называ-
ются итерациями или спринтами. Более подробно выделенные на ту или
иную итерацию требования изучаются, когда разработка подойдет к этой
итерации.
Независимо от используемой в проекте модели, надо при каждом выпуске
или итерации задавать себе вопрос, какие из действий, описанных на рис. 3-2,
позволят увеличить ценность и снизить риск. По завершении шага 17 для
любой части требований можно приступать к построению соответствующей
части системы. Повторите шаги с 8 по 17 со следующим набором требований,
который ляжет в основу следующего выпуска или итерации
Определение классов пользователей и их характеристик Чтобы не упу-
стить из виду потребности отдельных пользователей, выделите их в группы.
Например, по частоте работы с ПО, используемым функциям, уровню приви-
легий и опыту работы. Опишите их обязанности, местоположение и личные
характеристики, способные повлиять на архитектуру продукта. Создайте ар-
хетипы пользователей — описания выдуманных людей, которые будут пред-
ставлять конкретные классы пользователей. Подробнее см. главу
Определение источников требований Чтобы гарантировать, что все за-
интересованные лица понимают, зачем нужно то или иное требование, вы-
явите источники всех требований. Это может быть вариант использования
или другая информация от пользователей, системное требование высокого
уровня или бизнес-правило. Указав всех лиц, заинтересованных в каждом
требовании, вы будете знать, к кому обратиться при поступлении запроса
на изменение. Источники требований устанавливают на основе связей или
определяют для этой цели атрибут требования. Подробнее об атрибутах тре-
бований см. главу
Анализ влияния изменений требований Анализ влияния изменений —
важный элемент процесса внесения изменений, который помогает совету по
управлению изменениями принимать обоснованные решения. Оцените, как
каждое предлагаемое изменение требований повлияет на проект. На основе
матрицы связей выявите другие требования, элементы архитектуры, исхо-
дный код и сценарии тестирования, которые, возможно, придется изменить.
Определите, что необходимо для реализации изменений, и оцените затраты
на реализацию. Подробнее см. главу
Ведение журнала изменений требований Ведите хронологию изменений
требований. Иногда нужно вернуться к предыдущей версии требования или
узнать, как требование пришло в текущее состояние. Фиксируйте даты из-
менения требований, сами коррективы, их причины, а также лиц, вносивших
изменения. Автоматизировать эти задачи позволяет утилита управления
версиями или коммерческая утилита управления требованиями
Отслеживание проблем с требованиями Когда занятые люди работают над
сложным проектом, легко упустить многие возникающие проблемы, в том
числе вопросы требований, нуждающиеся в разрешении, незаполненные про-
белы и проблемы, возникающие при рецензировании требований. Средства
отслеживания дефектов могут обеспечить, чтобы эти вещи не остались
без внимания. Назначьте по одному ответственному на каждую проблему.
Отслеживайте состояние проблем с требованиями, чтобы быть в курсе обще-
го состояния дел с требованиями. Подробнее см. главу
Использование средств управления требованиями Коммерческие утили-
ты управления требованиями позволяют хранить различные типы требова-
ний в базе данных. Эти средства помогают автоматизировать многие задачи
по управлению требованиями, описанные ниже. Подробнее см. главу
Планы реализации проекта должны быть основаны на требованиях Раз-
рабатывайте планы и графики работы над проектом постепенно, по мере про-
яснения границ и подробных требований. Начните с оценки затрат, необхо-
димых на реализацию функциональных требований, определенных на основе
первоначальных концепции продукта и границах проекта. Первые графики и
оценка затрат, построенные на основе нечетких требований, окажутся край-
не неточными, однако по мере детализации требований их следует уточнить.
В проектах гибкой разработки поэтапная природа итераций подразумевает,
что планирование включает корректировку границ проекта, чтобы они соот-
ветствовали ограничениям времени и ресурсов. Подробнее см. главы 19 и
Пересмотр обязательств по проекту при изменении требований Команда
проекта принимает обязательство предоставить определенные наборы требова-
ний в рамках определенного бюджета и за определенное время. Добавляя в про-
ект новые требования, оцените, удается ли выполнить текущие обязательства с
имеющимися ресурсами. Если нет, обсудите реалии проекта с менеджерами и
согласуйте новые, более реалистичные обязательства (Wiegers, 2007; Fisher, Ury
и Patton, 2011). Может также потребоваться повторно согласовывать обязатель-
ства по мере того, как требования будут развиваться от состояния неопределен-
ности при начальной оценке до ясных и четких проверенных требований
• Вернитесь к проблемам с требованиями, которые вы определили, вы-
полняя задания раздела «Что теперь?» главы 1. Выберите описанные
в этой главе приемы, которые помогут вам решить все эти проблемы.
Сгруппируйте приемы по их влиянию на вашу организацию (силь-
ное, среднее и слабое). Определите, какие препятствия в организации
или культуре способны помешать вам воспользоваться тем или иным
приемом. Кто поможет вам устранить эти препятствия? Можете ли вы
выбрать одно действие, чтобы работать эффективнее, чем раньше?
• Определите, как бы вы оценивали приемы, которые считаете наиболее
ценными. Позволят ли они уменьшить число некорректных требова-
ний, выявляемых на поздних стадиях работы над проектом, умень-
шить объем ненужных доработок, точнее следовать графику проекта
или предоставят какие-то другие преимущества?
• Перечислите все приемы формулирования требований, определенные
на первом этапе. Укажите, насколько члены вашей команды овладели
на сегодняшний момент тем или иным приемом: эксперты, опытные
специалисты, новички или не знакомые с данным приемом. Если ква-
лификация членов команды ниже, чем опытных специалистов, попро-
сите одного из них изучить данный прием и поделиться полученными
знаниями с остальными членами команды
Wer möchte dieses Buch lesen? 1
Anonymer Nutzer
Wer hat dieses Buch zu Ende gelesen? 1
Людмила
Top