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


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

Разработка

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

Практические приемы сбора требований и управления ими при разработке программного продукта

Карл И. Вигерс

Дважды лауреат Software Development Productivity Award

ш Microsoft

Посвящается Крис

Software

Requirements

Second Edition

Practical techniques for gathering and managering requirements throughout the development cycle

Karl E. Wiegers

Two-timewinner of the Software

Deve/opment Productivity Award

MJ&vsaft* Press

Разработка

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

Практические приемы сбора требований и управления ими при разработке программного продукта

Карл И. Вигерс

Дважды лауреат Software Development Productivity Award

Москва 2004

М . Р ШШ Щ Н Ц

УДК 004.45

ББК 32.973.26-018.2

В41

Вигерс Карл

В41 Разработка требований к программному обеспечению/Пер, с англ. — М.: Издательсш-торговыйдом «Русская Редакция», 2004.—576с.:ил.

ISBN 5-7502-0240-2

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

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

Книга состоит из 23 глав, 4 приложений, словаря терминов и библиографического списка.

УДК 004.45 ББК 32.973.26-018.2

Подготовлено к изданию по лицензионному договору с Microsoft Corporation, Редмонд, Вашингтон, США.

Microsoft, Microsoft Press, Visual Basic и Windows являются товарными знаками или охраняемыми товарными знаками корпорации Microsoft в США и/или других странах. Все

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

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

 

©

Оригинальное издание на английском

 

 

языке, KarlWiegers, 2003

 

©

Перевод на русский язык, Microsoft

 

 

Corporation, 2004

ISBN 0-7356-1879-8(англ.)

© Оформление и подготовкак изданию.

 

издательско-торговыйдом "Русская

ISBN 5-7502-0240-2

 

Редакция.., 2004

Содержание

Предисловие

xiii

Что дает эта книга

xiv

Кому предназначена эта книга

xv

Краткий обзор

xv

Примеры из практики

xvi

От принципов - к практике

xvii

Благодарности

xvii

Часть I. Требования к продукту: что, почему и кто

Глава 1. Особенности разработки требований кПО

2

Оговоренныетребования кПО

('

Особенности интерпретациитребований

G

Уровни требований

/

Каких требований не должно быть

11

Разработка и управление требованиями

12

Разработка требований

12

Управлениетребованиями

13

Каждый проект имеет требования

14

Когда плохие требования появляются у хорошихлюдей

16

Недостаточное вовлечение пользователей

17

«Разрастание» требований пользователей

17

Двусмысленность требований

18

«Золочение» продукта

18

Минимальнаяспецификация

19

Пропуск классов пользователей

19

Небрежное планирование

20

studfiles.net

Карл Вигерс. Разработка требований к программному обеспечению | Жизнь - это движение! А тестирование

Ссылка на OZON.

Эта книга рассказывает нам о том, как именно собирать и обрабатывать тербования к программному обеспечению. Когда я ехала домой пару дней назад, моя коллега, увидев книгу, открыла ее на странице "Содержание" и сказала - "Ого! Как много тем тут раскрыто"...

Я задумалась над этими словами и поняла - очень емкое высказывание  Действительно, в книге раскрыто очень и очень много тем. Поэтому для начинающего аналитика она вообще mast-have, а для продвинутого - есть что почерпнуть.

Я выписывала оттуда интересные мысли и цитаты, все ссылки:

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

Говоря это, я вспоминаю, как готовилась поступать в МГТУ им. Баумана. Физика шла у меня не очень хорошо, поэтому я занималась с репетиторами из института. Первый репетитор говорил хорошо, объяснял доступно... Поэтому, сидя рядом с ним, я все занятие кивала, "конечно, понятно". А потом приходила домой и не могла решить сама ни одной (!) задачи. И куда девалось "все просто и понятно"?

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

Так что могу на собственном опыте гордо сказать - все. что звучит легко, просто, понятно и красиво, перестает таким быть до первого столкновения на практике. Поэтому просто прочитать книгу / посетить тренинг - мало. Надо что-то сделать. Самому. Иначе - никак.

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

А еще в конце книги есть приложения. Некоторые показывают на примере кратенько все то, что проходилось в предыдущих главах. Но меня особенно заинтересовало приложение А. "Самостоятельная оценка применяемых вами приемов работы с требованиями". Это такой тест, который, во-первых, показывает ваше текущее положение дел (правда, там не даны ответы, как оценивать, но долго ли умеючи? Поделить общее число баллов, которых 100, на 4 - и вот вам 4 категории, плохо, неплохо, хорошо, отлично)

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

Вот например, как вы считаете, какой ответ лучше:

  • Мы записываем требования на структурированном естественном языке с последовательным уровнем детализации, в соответствии со стандартным шаблоном спецификации требований к ПО. Иногда мы дополняем эти требования графическими моделями анализа с применением стандартных пояснений.
  • Мы храним свои требования в базе данных или коммерческом инструментальном средстве управления требованиями, а модели анализа - в коммерческом инструментальном средстве. Вместе с каждым требованием хранятся несколько его атрибутов.
Меня до сих пор терзает подозрение, что это какой-то прикол... Он, видимо, из серии "автоматизация - наше все". Если есть инструмент, то все, что перечислено в 3-ем пункте, уже не нужно? о_О

В целом ответы под номером 4 более-менее лучше выглядят, но данный пример меня поражает. И я понимаю, что 100 баллов в этом тесте никогда не наберу  По другим вопросам меня тоже мои немаксимальные ответы в принципе устраивают...

Из ложки дегтя - читала издание 2004 года. Не могу сказать что там прям уж "очепятка на очепятке и очепяткой погоняет", но их много. Надо было, наверное, помечать и выписывать, сделать доброе дело. Хотя я не в курсе, может, было переиздание, которое вычитали? В целом, конечно, не столь важно, 540 страниц - это вам не шуточки, хотя опечатки все-таки удручают...

Резюмируя - книга рекомендуется всем. кто собирается писать требования. И даже тем, кто собирается их тестировать. "Врага надо знать в лицо"

Шучу, требования нам не враг, а очень даже друг, что не раз обосновывается в этой книге, хотя я и предвижу холивары на тему "а нам и без них хорошо, у нас Заказчик такой". Бывает, да. Но, согласитесь, находить баги на этапе требований приятнее, так как исправляются они быстрее и дешевле!

okiseleva.blogspot.ru

Как стать настоящим аналитиком требований. Часть 1. Великими аналитиками рождаются или становятся?

«Великих аналитиков взращивают, а не обучают. Для работы аналитиком требуется множество личностных черт, а не знаний каких-либо технологий. Стандартного обучающего курса или описания обязанностей такого специалиста не существует. В аналитики приходят из разных профессий, и, скорее всего, у всех новичков есть пробелы в знаниях и навыках» Вигерс Карл «Разработка требований к программному обеспечению», 2004 Карл Вигерс написал свою книгу практически 10 лет назад, но ситуация не изменилась – настоящих аналитиков единицы. Эта серия статей – для тех, кто собирается стать профессиональным аналитиком требований. Информация собрана из личного опыта, книги Карла И. Вигерс «Разработка требований к программному обеспечению», а так же из опыта других аналитиков из сети Интернет. Дорогие хабравчане, я призываю комментировать мои статьи и, тем самым, исправлять ситуацию малочисленности хороших аналитиков, давая советы и рекомендации новичкам в этом непростом деле. Давайте определимся – кто такой аналитик требований, какими навыками должен обладать человек, который хочет заниматься анализом требований. Среди участников любого проекта по разработке программного обеспечения обязательно есть человек, явно или неявно выполняющий роль аналитика требований. Являясь, по сути, разработчиком ПО, он осваивает обязанности аналитика и работает с пользователями, собирая, анализируя и документируя требования. Однако не все разработчики умеют правильно формулировать требования к ПО и общаться с клиентом. Обучение позволяет повысить профессиональные навыки сотрудников, выполняющих роли аналитика, но не может компенсировать нехватку навыков межличностного общения и заинтересованности в деле. Какая основная задача стоит перед аналитиком требований? Самая важная задача аналитика отразить мнения заинтересованных сторон и лиц в спецификации требований и передать информацию другим лицам, участвующих в проекте. Аналитик помогает участникам проекта прояснить, действительно ли пожелания, которые они высказывают вслух, — это то, что им на самом деле нужно. Аналитик обучает, задает вопросы, слушает, организует и учится. Основные факторы успеха — терпение и искреннее желание работать с людьми. В основе мастерства Аналитика лежат личностные навыки, без развития которых вы не состоитесь в этой профессии. Будьте готовы к тому, что вам придется постоянно чему-то учиться. И по мере освоения нового вы будете понимать, что знаете слишком мало. Выбрав профессию аналитика, вы выбираете определенный стиль мышления, общения, развития и самой жизни в целом. Без наличия некоторых навыков и желания их развивать лучше вообще уйти из этой профессии. Какими же навыками должен обладать Аналитик?
Умение слушать
Активное слушание подразумевает устранение помех, сохранение вежливой позы и зрительный контакт, а также повторение основных моментов для закрепления их понимания. Вам нужно моментально схватывать, что говорят люди, и уметь читать между строк, что бы обнаружить вещи, о которых они стесняются говорить. Важно не только то, что вам говорят, но и то, как вам это говорят.
Умение опрашивать и задавать вопросы
Большая часть информации о требованиях извлекается из беседы с людьми, и поэтому аналитик должен уметь общаться с разными людьми и группами. Встречаются разные собеседники: кто-то желает рассказать все, что знает и даже не по теме, кто-то отвечает только на конкретные вопросы, кто-то выдает желаемое за действительное. И только с помощью правильных вопросов из огромного потока информации можно выявить существенные требования.
Навыки создания комфортных условий общения
Умение организовать дружескую атмосферу — один из необходимых навыков аналитика. Конечно, данный навык не так важен, как первые два. Но в комфортных условиях всегда лучше работается.
Умение наблюдать
Наблюдая за тем, как пользователь выполняет свои обязанности или работает с имеющимся приложением, опытный аналитик выявит моменты, о которых пользователь даже не упомянул. Наблюдательность помогает направить дискуссию в новое русло, чтобы выявить дополнительные требования, о которых никто ничего не сказал.
Стрессоустойчивость
В процессе работы появляется огромное количество информации (часто противоречивой) и данных, которые могут в один момент коренным образом изменить понимание и направление анализа и проектирования. Аналитик должен быть к этому готов, уметь сориентироваться в новых условиях, не поддаваться панике.
Умение анализировать и обрабатывать информацию
Аналитик имеет дело с большим объемом беспорядочной информации, собранной на первом этапе. Способность обрабатывать большой объем информации и анализировать его позволит структурировать данные и выстроить ясную и четкую картинку.
Умение решать проблемы и разрешать конфликты
В проекте может работать большое количество заинтересованных лиц и участников проекта, каждый из которых имеет свой взгляд и видение. Аналитик должен обладать умением выслушать все стороны, обобщить информацию, принять оптимальное решение и убедить стороны в его правильности.
Умение вести переговоры
Аналитик должен уметь организовать людей с разными интересами для совместной работы, и уверенно чувствовать себя в разговорах с сотрудниками, занимающими разные должности в организации. Подумайте, как сложно иметь дело с сотрудниками из виртуальных групп, различающихся по географическому, временному, культурному или языковому признаку.
Умение работать в команде
Результат работы Аналитика используют многие участники проекта. Он должен уметь работать в команде, доверять своим коллегам и осознавать ответственность перед ними, выполняя свою часть работы.
Творческий подход
Аналитик — не просто стенографист, записывающий все высказывания клиентов. Аналитики изобретают требования. Они предлагают инновационные функции продуктов, новые рыночные возможности и возможности для бизнеса и думают, как удивить и удовлетворить своих клиентов. Отличный аналитик творчески подходит к делу: рассказывая о системе, ему удается удивить клиента — тот даже не всегда подозревает, что такая функциональность возможна
Знание предметной области
Аналитику, разбирающемуся в бизнесе, легче общаться с клиентами и понимать их, ему удается выявить невысказанные предположения и неявные требования. Он может предложить варианты совершенствования бизнес-процессов, а также ценную функциональность, о которой пользователи даже не думали. Аналитик должен уметь применять разные средства сбора информации и представлять эту информацию различными способами на нормальном и понятном языке. Обладать одновременно развитыми коммуникационными навыками, знанием психологии межличностного общения, техническими знаниями, знаниями предметной области, бизнеса и личными качествами, подходящими для этой работы. Для людей, которые любят решать сложные задачи и хотят стать профессиональными аналитиками – нет ничего невозможного! Главное понять, что Ваше призвание – быть переводчиком с невнятного на точный язык, с языка хотелок на язык функциональности, с языка «а вот если бы» на язык «это делается так»! Жду комментарии тех, кто уже состоялся как аналитик, и может поделиться своими наблюдениями, и тех, кто сталкивается с аналитиками по роду своей деятельности, и может поделиться своими огорчениями или восхищением от взаимодействия с ними. Встретимся в следующий раз на обсуждении темы «Различные методы для создания и выявления требований».

habrahabr.ru

Карл Вигерс, Джой Битти - Разработка требований к программному обеспечению, издание третье [2014, PDF, RUS] скачать через торрент бесплатно

Разработка требований к программному обеспечению, издание третьеSoftware Requirements, Third Edition

Год: 2014Автор: Карл Вигерс и Джой Битти / Karl Wiegers and Joy BeattyЖанр: Тестирование ПОИздательство: Русская редакцияISBN: 978-5-7502-0433-5Язык: РусскийФормат: PDFКачество: Изначально компьютерное (eBook)Количество страниц: 737Описание:Эта книга — подробное руководство по разработке качественных требований к программному обеспечению. Здесь описаны десятки проверенных на практике приемов выявления, формулирования, разработки, проверки, утверждения и тестирования требований, которые помогут разработчикам, менеджерам и маркетологам создать эффективное ПО. Настоящее издание дополнено новыми приемами, посвященными разработке требований в проектах гибкой разработки (agile).Основная аудитория — бизнес-аналитики и разработчики, а также дизайнеры, программисты, тестировщики и другие члены команды, задача которых понять и удовлетворить чаяния клиентов, а также маркетологи, менеджеры по продуктам и менеджеры проекта, которые должны проникнуться «духом» и особенностями продукта, чтобы сделать его в полной мере конкурентоспособным.Книга состоит из 32 глав, 3 приложений и словаря терминов.

Введение......................................................................................................... XIVЧАСТЬ I Требования к ПО: что, почему и кто .................................................1Глава 1 Основы разработки требований к ПО .............................................2Определение требований к ПО ............................................................................................4Особенности интерпретации требований ..................................................................5Уровни и типы требований ..............................................................................................6Три уровня требований .................................................................................................. 12Требования к продукту и требования к проекту ................................................... 14Разработка и управление требованиями ........................................................................ 16Разработка требований .................................................................................................. 16Управление требованиями ............................................................................................ 18Каждый проект имеет требования .................................................................................... 19Когда плохие требования появляются у хороших людей ........................................ 20Недостаточное вовлечение пользователей ............................................................. 21Небрежное планирование ............................................................................................. 22«Разрастание» требований пользователей .............................................................. 22Двусмысленные требования ........................................................................................ 22Требования-«бантики» ................................................................................................... 23Пропущенные классы пользователей ....................................................................... 23Выгоды от высококачественного процесса разработки требований .................... 24Глава 2 Требования с точки зрения клиента ............................................ 26Разрыв ожиданий ................................................................................................................... 28Кто же клиент? ........................................................................................................................ 29Сотрудничество клиентов и разработчиков ................................................................. 31Билль о правах клиента ПО ......................................................................................... 33Билль об обязанностях клиента ПО ......................................................................... 36Создание культуры уважения к требованиям .............................................................. 40Определение ответственных за принятие решений ................................................... 42Достижение соглашения о требованиях ......................................................................... 43Базовое соглашение о требованиях ........................................................................... 44Что если не удается достичь соглашения? .............................................................. 45Согласование требований в проектах гибкой разработки ................................. 45Глава 3 Рекомендуемые приемы формулирования требований ........... 48Каркас процесса создания требований ........................................................................... 51Выявление требований ......................................................................................................... 54Анализ требований................................................................................................................. 56Спецификации требований................................................................................................. 58Проверка требований ............................................................................................................ 59Управление требованиями .................................................................................................. 60Обучение ................................................................................................................................... 62Управление проектом ............................................................................................................ 64Начинаем применять новые приемы ............................................................................... 66Глава 4 Бизнес-аналитик ............................................................................ 69Роль бизнес-аналитика ......................................................................................................... 70Задачи аналитика ................................................................................................................... 72Навыки, необходимые аналитику ..................................................................................... 73Знания, необходимые аналитику ...................................................................................... 77Становление аналитика ........................................................................................................ 78Бывший пользователь .................................................................................................... 78Бывший разработчик или тестировщик .................................................................. 79Бывший (или текущий) менеджер проекта ............................................................ 80Специалист предметной области ............................................................................... 80Молодой специалист ...................................................................................................... 81Роль аналитика в проектах гибкой разработки ........................................................... 82Создание дружной команды ............................................................................................... 83ЧАСТЬ II Разработка требований ............................................................... 85Глава 5 Определение бизнес-требований ................................................ 86Формулировка бизнес-требований .................................................................................. 87Определение требуемых бизнес-преимуществ...................................................... 87Концепция продукта и границы проекта ................................................................. 88Противоречивые бизнес-требования ........................................................................ 89Документ о концепции и границах ................................................................................... 911. Бизнес-требования ...................................................................................................... 932. Рамки и ограничения проекта ................................................................................. 993. Бизнес-контекст ......................................................................................................... 101Способы представления границ проекта ..................................................................... 103Контекстная диаграмма ............................................................................................... 104Карта экосистемы .......................................................................................................... 105Дерево функций ............................................................................................................. 106Список событий .............................................................................................................. 107Не упускайте границы из вида......................................................................................... 108Использование бизнес-целей для принятия решенийо границах проекта ......................................................................................................... 109Оценка эффекта от изменения границ проекта................................................... 110Концепция и границы в проектах гибкой разработки ............................................. 110Применение бизнес-целей для определения момента завершения проекта ......... 111Глава 6 Как отобрать пользователей для работы над проектом ........ 113Классы пользователей ........................................................................................................ 114Классификация пользователей ................................................................................. 115Определение классов пользователей ...................................................................... 118Архетипы пользователей .................................................................................................. 121Представители пользователей ......................................................................................... 122Сторонник продукта ............................................................................................................ 124Сторонники продукта, приглашенные со стороны ............................................ 125Чего следует ожидать от сторонника продукта ................................................... 126На что способны несколько сторонников продукта .......................................... 127Как «продать» идею о необходимости привлечениясторонника продукта .................................................................................................... 129В какие ловушки можно угодить, привлекая сторонников продукта ......... 130Представительство пользователей в проектах гибкой разработки ..................... 131Разрешение противоречивых требований ................................................................... 133Глава 7 Выявление требований ............................................................... 135Методы выявления требований ...................................................................................... 137Интервью .......................................................................................................................... 137Семинары .......................................................................................................................... 139Фокус-группы ................................................................................................................. 142Наблюдение ..................................................................................................................... 143Опросные листы ............................................................................................................. 145Анализ системных интерфейсов ............................................................................... 145Анализ пользовательского интерфейса ................................................................. 146Анализ документов ........................................................................................................ 146Планирование выявления требований в проекте ..................................................... 147Подготовка к выявлению требований ........................................................................... 149Выявление требований ....................................................................................................... 152Действия после выявления требований ....................................................................... 154Организация и рассылка протоколов ..................................................................... 154Документирование открытых проблем .................................................................. 155Классификация предоставляемойклиентом информации .................................... 155Как понять, что сбор требований завершен ................................................................ 159Несколько советов о том, как собирать информацию ............................................. 160Подразумеваемые и неявные требования .................................................................... 161Поиск упущенных требований ........................................................................................ 163Глава 8 Как понять требования пользователей ..................................... 165Варианты использования и сценарии использования ............................................ 167Подход с применением варианта использования продукта .................................. 171Варианты использования и сценарии использования ...................................... 173Предварительные и выходные условия ................................................................. 175Определение вариантов использования ................................................................ 183Анализ вариантов использования ............................................................................ 185Проверка вариантов использования ....................................................................... 187Варианты использования и функциональные требования ............................. 188Каких подводных рифов следует опасаться при способес применением вариантов использования............................................................. 190Преимущества требований, основанных на вариантах использования ............ 192Глава 9 Игра по правилам ......................................................................... 194Классификация бизнес-правил ....................................................................................... 197Факты ................................................................................................................................. 198Ограничения .................................................................................................................... 198Активаторы операций ................................................................................................... 200Выводы .............................................................................................................................. 202Вычисления ...................................................................................................................... 202Атомарные бизнес-правила ........................................................................................ 203Документирование бизнес-правил ................................................................................. 204Выявление бизнес-правил ................................................................................................. 206Бизнес-правила и требования .......................................................................................... 208Сводим все воедино ............................................................................................................. 210Глава 10 Документирование требований ............................................... 212Спецификация требований к ПО ................................................................................... 215Требования к именованию .......................................................................................... 218Когда информации недостаточно ............................................................................. 221Пользовательские интерфейсы и спецификация требований к ПО ............ 221Шаблон спецификации требований к ПО ................................................................... 2231. Введение........................................................................................................................ 2252. Общее описание ......................................................................................................... 2263. Функции системы...................................................................................................... 2274. Требования к данным ............................................................................................... 2285. Требования к внешним интерфейсам ................................................................. 2296. Атрибуты качества .................................................................................................... 2317. Требования по интернационализации и локализации ................................. 2338. [Остальные требования] ......................................................................................... 233Приложение A. Словарь терминов .......................................................................... 233Приложение Б. Модели анализа............................................................................... 234Спецификация требований в проектах гибкой разработки .................................. 234Глава 11 Пишем идеальные требования ................................................ 237Характеристики превосходных требований ............................................................... 238Характеристики отдельных положений спецификации требований .......... 238Характеристики наборов требований ..................................................................... 240Принципы создания требований .................................................................................... 242Системная или пользовательская точка зрения ................................................. 243Язык и стиль .................................................................................................................... 244Уровень детализации .................................................................................................... 247Способы представления .............................................................................................. 248Предотвращение неопределенности ....................................................................... 249Предотвращение неполноты ...................................................................................... 253Примеры требований: до и после .................................................................................... 255Глава 12 Лучше один раз увидеть, чем 1024 раза услышать ............... 260Моделирование требований ............................................................................................. 261От желания клиента к модели анализа ......................................................................... 263Выбор правильного представления ............................................................................... 265Диаграмма потоков данных .............................................................................................. 267Диаграммы swimlane ........................................................................................................... 272Диаграмма переходов состояний и таблица состояний .......................................... 274Карта диалоговых окон....................................................................................................... 277Таблицы и деревья решений ............................................................................................. 281Таблицы событий и реакций ............................................................................................. 283Несколько слов об UML-диаграммах ........................................................................... 287Моделирование в проектах гибкой разработки ......................................................... 288Последнее напоминание .................................................................................................... 288Глава 13 Определение требований к данным ........................................ 290Моделирование отношений данных .............................................................................. 291Словарь данных..................................................................................................................... 294Анализ данных ....................................................................................................................... 298Спецификация отчетов ...................................................................................................... 300Сбор требований к отчетности .................................................................................. 300Особенности определения отчетов .......................................................................... 301Шаблон спецификации отчета .................................................................................. 303Панели мониторинга ........................................................................................................... 305Глава 14 Обратная сторона функциональности: атрибуты качества ПО .. 309Атрибуты качества ПО ....................................................................................................... 311Изучение атрибутов качества .......................................................................................... 312Определение требований по качеству ........................................................................... 317Внешние атрибуты качества ...................................................................................... 317Внутренние атрибуты качества ................................................................................. 333Определение требований по качеству с помощью языка Planguage .................. 340Компромиссы для атрибутов............................................................................................ 342Реализация требований к атрибутам качества ........................................................... 344Ограничения .......................................................................................................................... 345Атрибуты качества в проектах гибкой разработки ................................................... 347Глава 15 Прототипы как средство снижения риска .............................. 350Что такое прототип и для чего он нужен...................................................................... 351Модели и экспериментальные образцы........................................................................ 353Одноразовые и эволюционные прототипы ................................................................. 354Бумажные и электронные прототипы ........................................................................... 358Работа с прототипами ......................................................................................................... 360Оценка прототипа ................................................................................................................ 363Риски создания прототипов.............................................................................................. 365Подталкивание к выпуску прототипа ..................................................................... 365Отвлечение на детали ................................................................................................... 366Нереалистичные ожидания производительности .............................................. 367Слишком много усилий на создание прототипов ............................................... 367Факторы успеха использования прототипов.............................................................. 367Глава 16 Сначала о главном: определение приоритетов требований .... 370Зачем определять приоритеты требований ................................................................. 371Некоторые практические соображения определения приоритетов ................... 372Игры, в которые люди играют с приоритетами ......................................................... 374Некоторые приемы определения приоритетов .......................................................... 376Включать или не включать ......................................................................................... 376Попарное сравнение и ранжирование .................................................................... 377Трехуровневая шкала приоритетов ......................................................................... 377Схема классификации приоритетов MoSCoW ................................................... 379100 долларов .................................................................................................................... 380Определение приоритетов на основе ценности, стоимости и риска .................. 381Глава 17 Утверждение требований .......................................................... 389Утверждение и верификация ........................................................................................... 391Рецензирование требований ............................................................................................. 392Процесс экспертизы ...................................................................................................... 394Контрольные списки дефектов ................................................................................. 400Советы по рецензированию требований ................................................................ 401Сложности рецензирования требований ............................................................... 402Прототипы требований ...................................................................................................... 404Тестирование требований .................................................................................................. 405Утверждение требований с применением критериев приемки ............................ 410Критерии приемки ......................................................................................................... 410Приемочные тесты ......................................................................................................... 411Глава 18 Повторное использование требований ................................... 414Зачем нужно повторное использование требований? ............................................. 415Виды повторного использования требований ............................................................ 416Объем повторного использования ........................................................................... 417Объем изменений ........................................................................................................... 418Механизм повторного использования .................................................................... 418Типы информации требований, поддающихся повторномуиспользованию ...................................................................................................................... 420Популярные сценарии повторного использования .................................................. 421Семейства продуктов .................................................................................................... 421Реинжиниринг и замена системы ............................................................................. 422Другие возможности повторного использования............................................... 422Схемы требований ................................................................................................................ 424Средства, облегчающие повторное использование .................................................. 425Как сделать требования повторно используемыми.................................................. 426Препятствия и факторы успеха повторного использования требований......... 428Препятствия для повторного использования ...................................................... 429Факторы успеха повторного использования........................................................ 430Глава 19 От разработки требований — к следующим этапам ............. 433Оценка объема работ по реализации требований ..................................................... 434От требований — к планам проекта ............................................................................... 438Оценка размера проекта и объема усилий на основе требований ................ 438Требования и график .................................................................................................... 441От требований — к дизайну и коду ................................................................................ 442Архитектура и выделение ресурсов ......................................................................... 442Дизайн ПО ........................................................................................................................ 444Дизайн пользовательского интерфейса ................................................................. 445От требований — к тестированию................................................................................... 447От требований — к успеху ................................................................................................. 450ЧАСТЬ III Требования в проектах определенных классов ..................... 453Глава 20 Проекты гибкой разработки (agile) .......................................... 454Ограничения водопадной модели ................................................................................... 455Гибкий подход к разработке.............................................................................................. 456Особенность гибкой разработки в применении к требованиям .......................... 457Вовлечение клиентов .................................................................................................... 457Подробнее о документации ........................................................................................ 458Резерв проекта и расстановка приоритетов .......................................................... 458Планирование времени ................................................................................................ 459Эпики, пользовательские истории и функции .................................................... 460Расчет на неизбежные изменения ............................................................................ 461Адаптация приемов работы с требованиями для проектов гибкой разработки ...... 462Переход к гибкой разработке: что дальше? ................................................................. 463Глава 21 Проекты по доработке или замене систем ............................. 465Ожидаемые затруднения ................................................................................................... 466Работа с требованиями при наличии существующей системы ............................ 467Расстановка приоритетов на основе бизнес-целей ................................................... 469Осторожно с пробелами .............................................................................................. 470Сохранение уровня производительности .............................................................. 470Когда старых версий требований нет ............................................................................ 471Какие требования нужно определять ..................................................................... 472Как собирать требования к существующей системе .......................................... 474Продвижение новой системы ........................................................................................... 475Уместны ли итерации .......................................................................................................... 477Глава 22 Проекты с серийным продуктом .............................................. 478Требования к выбору тиражируемых решений ......................................................... 479Разработка пользовательских требований ............................................................ 480Работа с бизнес-правилами ........................................................................................ 480Определение потребностей в данных ..................................................................... 481Определение требований по качеству .................................................................... 481Оценка решений ............................................................................................................. 482Требования к внедрению серийных решений ............................................................. 484Требования к конфигурированию ............................................................................ 485Требования по интеграции .......................................................................................... 486Требования по расширению ....................................................................................... 486Требования к данным .................................................................................................... 486Изменение бизнес-процессов .................................................................................... 487Обычные сложности с пакетными решениями .......................................................... 487Глава 23 Проекты, выполняемые сторонними организациями ........... 489Необходимый уровень детализации требований ...................................................... 490Взаимодействие заказчика и подрядчика .................................................................... 492Управление изменениями .................................................................................................. 494Критерии приемки ............................................................................................................... 495Глава 24 Проекты автоматизации бизнес-процессов ........................... 496Моделирование бизнес-процессов ................................................................................. 497Использование текущих процессов для вывода требований ......................... 498Проектирование в первую очередь будущих процессов .................................. 500Моделирование метрик бизнес-производительности ............................................. 501Приемы, рекомендуемые к использованию в проектах автоматизациибизнес-процессов ................................................................................................................. 502Глава 25 Проекты бизнес-аналитики ....................................................... 504Общие сведения о проектах бизнес-аналитики ......................................................... 505Разработка требований в проектах бизнес-аналитики ............................................ 507Приоритизация работы на основе решений ......................................................... 508Определение, как будет использоваться информация ..................................... 508Определение потребностей в данных ..................................................................... 511Определение аналитических операций преобразования данных ................. 513Эволюционная природа аналитики ............................................................................... 515Глава 26 Проекты встроенных и других систем реального времени .. 517Системные требования, архитектура и назначение ................................................. 518Моделирование систем реального времени ................................................................ 520Контекстная диаграмма ............................................................................................... 520Диаграмма переходов состояний .............................................................................. 521Таблица событий и реакций ....................................................................................... 522Архитектурная диаграмма .......................................................................................... 523Создание прототипов .................................................................................................... 525Интерфейсы............................................................................................................................ 525Требования к временным характеристикам ................................................................ 526Атрибуты качества для встроенных систем ................................................................ 528Проблемы встроенных систем ......................................................................................... 534ЧАСТЬ IV Управление требованиями ....................................................... 535Глава 27 Приемы управления требованиями к ПО ................................ 536Процесс управления требованиями ............................................................................... 537Базовое соглашение о требованиях ................................................................................ 538Управление версиями требований.................................................................................. 540Атрибуты требований ......................................................................................................... 542Отслеживание состояния требований .......................................................................... 544Разрешение проблем с требованиями ........................................................................... 546Определение усилий, необходимых для управления требованиями ................. 548Управление требованиями в проектах гибкой разработки .................................... 549Почему нужно управлять требованиями ..................................................................... 551Глава 28 Изменения случаются ............................................................... 552Почему нужно управлять требованиями ..................................................................... 553Управление незапланированным ростом объема ...................................................... 554Политика управления изменениями ............................................................................. 555Основные понятия процесса управления изменениями ........................................ 556Описание процесса управления изменениями .......................................................... 5571. Назначение и границы ............................................................................................. 5582. Роли и ответственность ........................................................................................... 5583. Состояние запроса на изменение ......................................................................... 5594. Входные критерии ..................................................................................................... 5605. Задачи ........................................................................................................................... 5606. Выходные критерии .................................................................................................. 5617. Отчет о состоянии контроля изменений ........................................................... 561Приложение. Атрибуты запросов на изменение ................................................. 561Совет по управлению изменениями .............................................................................. 562Состав совета по управлению изменениями ........................................................ 563Устав совета по управлению изменениями ........................................................... 563Пересмотр обязательств .............................................................................................. 565Средства управления изменениями ............................................................................... 565Измерение активности изменений ................................................................................. 566Анализ влияния изменений .............................................................................................. 568Процедура анализа влияния изменения ................................................................ 568Шаблон отчета об анализе влияния изменения .................................................. 571Управление изменениями в проектах гибкой разработки ..................................... 572Глава 29 Связи в цепи требований .......................................................... 575Отслеживание связей требований .................................................................................. 575Мотивация для отслеживаемости требований .......................................................... 578Матрица отслеживаемости требований ........................................................................ 580Средства отслеживания требований .............................................................................. 583Процедура отслеживания требований .......................................................................... 584Осуществимость и необходимость отслеживания требований ............................ 586Глава 30 Инструментальные средства разработки требований.......... 589Средства разработки требований .................................................................................... 591Средства выявления требований .............................................................................. 591Средства создания прототипов ................................................................................. 592Средства моделирования ............................................................................................ 592Средства управления требованиями ............................................................................. 593Преимущества использования средств управления требованиями ............. 593Возможности средств управления требованиями .............................................. 595Выбор и реализация средства управления требованиями ..................................... 598Выбор инструментального средства ........................................................................ 598Настройка средств и процессов ................................................................................ 599Освоение средств пользователями .......................................................................... 601ЧАСТЬ V Реализация процесса построения требований ....................... 605Глава 31 Совершенствование процессов работы с требованиями .... 606Как требования связаны с другими составляющими проекта .............................. 607Требования и различные группы заинтересованных лиц ...................................... 610Как добиться готовности к изменениям ....................................................................... 611Основы совершенствования процессов разработки ПО ........................................ 613Анализ первопричин ........................................................................................................... 615Цикл совершенствования технологических процессов .......................................... 617Оценка текущих приемов ............................................................................................ 617Планирование действий по совершенствованию ............................................... 618Создание, проба и реализация новых технологических процессов ............. 620Оценка результатов ....................................................................................................... 620Документы процесса разработки и управления требованиями ........................... 622Документы процесса разработки требований ...................................................... 623Документы процесса управления требованиями................................................ 624Достигнута ли цель? ............................................................................................................ 625Дорожная карта совершенствования работы с требованиями ............................. 628Глава 32 Требования к ПО и управление рисками ................................. 630Основы управления рисками при создании ПО ....................................................... 631Составляющие управления рисками ...................................................................... 632Документирование рисков проекта ......................................................................... 633Планирование управления рисками ....................................................................... 635Риск, связанный с требованиями .................................................................................... 636Выявление требований ................................................................................................ 637Анализ требований ........................................................................................................ 639Спецификация требований ........................................................................................ 639Утверждение требований ............................................................................................ 640Управление требованиями .......................................................................................... 640Управление рисками — ваш друг .................................................................................... 641Приложение А ................................................................................................ 643Приложение Б ............................................................................................... 651Приложение В ............................................................................................... 678Словарь терминов ........................................................................................ 707Об авторах ..................................................................................................... 718

rutorka.net

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

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

Определение приоритетов — критически важная стратегия в проектах гибкой разработки и в других проектах, где продукты разрабатываются как последовательность фиксированных ограниченных во времени итераций. Проектные команды могут пополнять резерв своего продукта пользовательскими историями, функциями, бизнес-процессами и историями дефектов (то есть тех, что ожидают исправления). Клиенты расставляют приоритеты этих историй в резерве проекта и отбирают те, что должны реализовываться в каждой итерации разработки. Разработчики оценивают усилия, необходимые для реализации каждой истории и прикидывают, сколько историй можно разместить в той или иной итерации, основываясь на эмпирически определенной производительности. При появлении новых историй клиенты могут переоценивать приоритеты в резерве проекта, таким образом динамически корректируя объем будущих итераций. Это надо делать во всех проектах, чтобы гарантировать, что команда всегда работает над теми функциями, которые позволят максимально быстро предоставить пользователям полезное ПО.

Использование текущих процессов для вывода требований

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

  1. Как всегда при разработке ПО нужно начинать с понимания бизнес-целей, чтобы можно было привязать каждую к одному или нескольким процессам.
  2. Используйте структурные схемы организации для выявления всех задействованных организаций и возможных классов пользователей будущего программного решения.
  3. Определите все необходимые бизнес-процессы, предусматривающие участие этих классов пользователей.
  4. Задокументируйте все существующие бизнес-процессы, используя диаграммы потоков, диаграммы действий или swimlane-диаграммы. Любая из этих трех моделей является практичным вариантом представления задач пользователей. Пользователи могут быстро прочитать их и указать неправильные шаги, роли или логику принятия решений (Beatty и Chen, 2012). Вам нужно самому принять решение об уровне детализации моделирования существующих процессов, чтобы получить достаточно информации для выполнения следующих шагов этого списка.
  5. Проанализируйте существующие процессы для определения самых больших возможностей оптимизации за счет использования автоматизации. Если это неочевидно, нужно собрать информацию о том, сколько времени занимает выполнение определенных шагов или целых процессов. Это моделирование можно выполнить с помощью модели ключевых индикаторов производительности (key performance indicator model, KPIM), описанной далее в этой главе. Этот шаг помогает выявить возможности и, если программное решение окажется уместным, задать границы той части проекта, которая связана с разработкой ПО. Обязательно убедитесь, что устраняются настоящие узкие места процесса, ускорение в которых обеспечит сокращение времени всего процесса.
  6. Для каждого процесса, подпадающего под автоматизацию, пройдитесь по процессу с соответствующими заинтересованными лицами, чтобы выявить требования, обеспечивающие каждый этап потока. На этом этапе будут полезными приемы, описанные в главе 7. Если это уместно, может быть полезным выяснить отраслевые стандарты для моделируемого процесса, чтобы поставить цели по оптимизации.
  7. Отследите связь требований с конкретными этапами потока процесса, чтобы понять, не упустили ли вы какие-либо требования для отдельных этапов. Если есть этапы процесса, которым не соответствуют требования, убедитесь, что эти этапы в рамках проекта не автоматизируются.
  8. Задокументируйте потоки будущих процессов, чтобы в компании могли подготовиться к новой системе и определить пробелы, которые при наличии новой системы могут остаться в процессе. Можно также создать варианты использования, предоставляющие более подробную информацию о том, как пользователи будут взаимодействовать с новой системой. Эта информация позволяет разработчикам быть уверенными, что они создают систему, отвечающую ожиданиями компании, и помогает пользователям понять, какую пользу они от нее получат. Потоки будущих процессов и варианты использования можно использовать для разработки обучающих материалов и определения других переходных требований. Это позволяет заинтересованным лицам понять не только, с чем им предстоит иметь дело, но и какие ручные действия и автоматизированные системы будут устранены.

Когда ПО не нужно

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

Проектирование в первую очередь будущих процессов

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

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

scanlibs.com

ВИГЕРС КАРЛ РАЗРАБОТКА ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ — Как стать настоящим аналитиком требований

Эта книга посвящена разработке качественных требований к продукту. Книга состоит из 32 глав, 3 приложений и словаря терминов. Книга посвящена разработке требований к программным продуктам, в ней достаточно полно описаны возможные способы выявления, формулирования, разработки, проверки, утверждения и тестирования требований.

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

Подборки, в которых встречается эта книга

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

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

Важно отметить, что это перевод второго издания оригинальной книги, на порядок качественнее первого издания ! Основная аудитория – аналитики и разработчики продукта. НО. те , кто читал первые издания Вигерса, наверняка, помнят, что книга прочитывалась за вечер, информация ложилась в голову с первого прочтения.

Эти книги тоже могут вас заинтересовать

Этой книги, надо сильно постараться. ИТ-специалиста книга нужная и полезная. Вы получаете его после первой покупки и в каждом письме от нас. По этому номеру мы узнаем вас и расскажем о ваших скидках и персональных спецпредложениях! Карл Вигерс написал свою книгу практически 10 лет назад, но ситуация не изменилась – настоящих аналитиков единицы.

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

Умение анализировать и обрабатывать информацию

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

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

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

Похожие записи:

  • Вместе с книгой «Минея дополнительная» покупают:В Минею дополнительную вошли службы, а также отдельные тропари, кондаки и молитвы, […]
  • Формирование элементарных математических представлений у дошкольников (3-й год обучения): Рабочая тетрадь (1-я) частьАдресована педагогам дошкольных образовательных организаций (ДОО), центров развития […]
  • Натуральных чисел от 1 до 30 и от 1 до 10044,37 = 6,661; √4,437 = 2,107; √0,04'437 =0,2107 и т.д. Нормальным называется магический […]

horokolisander.ru


Смотрите также