Сегодня мы хотим предложить вашему вниманию книгу Ильи Корнипаева «Требования для программного обеспечения: Рекомендации по сбору и документированию», которая готовится к выходу в нашем издательстве.
Эта книга о том, как собирать, документировать и проверять требования. Она рассчитана на самый широкий круг читателей: начинающих аналитиков, проектировщиков, архитекторов, разработчиков, тестировщиков, руководителей проектов, и других специалистов задействованных в проектах по разработке ПО на ранних стадиях.
Читатель, независимо от того работает ли он на стороне компании разработчика, является или он представителям заказчика, или работает в ИТ-отделе компании, не связанной с разработкой ПО, может найти в книге полезные для себя советы и рекомендации.
Книга написана на основе более чем пятнадцатилетнего опыта автора, а также по материалам авторских курсов по разработке и управлению требованиями.
Другая концепция очень мало распространена в области разработки требований — это Ключевые Критерии (или Показатели) Производительности. Этот термин известен всем. В оригинале это всем известные KPIs — Key Performance Indicators. Но смысл этого термина с точки зрения применения его в области разработки требований нуждается в уточнении.
По аналогии с Ключевыми Требованиями, Ключевые Критерии Производительности определяют значения параметров производительности системы, без достижения которых система не будет полезна заказчику, а, следовательно, не может быть принята в промышленную эксплуатацию.
Стоит сразу пояснить, почему этому вопросу я уделил внимание. Неоднократно я видел ситуации, когда критерий производительности записывался в виде:
21.1. Система должна сохранять информацию, введенную на любой форме не более чем за 2 с.
или
21.2. Система должна возвращать результаты поиска не более чем за 5 с.
В принципе нормальные критерии производительности. Однако что же может произойти, если вдруг в конце проекта обнаруживается, что система не удовлетворяет одному из них? Во-первых, почему в конце? Во-во вторых, что же происходит?
В конце, потому что параметры производительности обычно проверяются, когда разработан и проверен весть перечень функциональных требований. А происходит следующее: недостатки в производительности системы обычно кроются на достаточно низком уровне, как разработчики говорят — «в ядре». И начинаются достаточно низкоуровневые правки кода, которые, нередко приводят к появлению проблем с работающими и уже оттестированным функциональными возможностями системы. Если выражаться на сленге разработчиков — «мы начали тюнить пеформас и это привело к коре рефакторингу, из-за чего поехал функционал». Т.е. пытались добиться соответствия параметрам производительности, а в итоге сломали систему, и это, я напомню, в конце проекта. В итоге команда попадает в цейтнот, все начинают работать сверхурочно, теряется внимание, и, в конце концов, команда может подойти к дате сдачи проекта с нерабочей системой.
Как же может аналитик помочь свой команде в ситуации, когда система на поздних этапах не удовлетворяет критериям производительности? Во-первых, аналитик должен попытаться определить вместе с заинтересованными сторонами, какие критерии производительности являются действительно ключевыми, и без их достижения система не может быть внедрена в промышленную эксплуатацию. Во-вторых, аналитик на этапе сбора требований должен понять функцию каждого критерия производительности, особенно это важно для ключевых.
На Рис.8 показано четыре функции показателей производительности. Зачастую аналитики ограничиваются первой функцией, т.е. фиксируют определенную величину. На самом деле это достаточно редкий случай.
Разберем пример на графике а) Заказчику нужно чтобы система поддерживала 100 одновременно работающих пользователей. Это значит, что у него есть 100 реальных пользователей и меньше быть не может, а больше в обозримом будущем не ожидается.
Графики б) и с) отражают более распространенные случаи. Для большинства web решений нагрузка носит вероятностный характер, что значит, что требование о том, что система должна поддерживать 200 одновременно работающих с системой пользователей, скорее всего также носит характер прогноза. Более того для новых сайтов количество одновременно работающих пользователей в начале работы в режиме промышленной эксплуатации может быть значительно меньше. Следовательно, если команда сталкивается с проблемами при удовлетворении этого критерия производительности, возможно, стоит не пытаться решить эти проблемы за оставшиеся несколько дней до окончания проекта, а договориться с заказчиком о приемке системы с более низким значением этого показателя, при условии, что команда потом доработает систему и поставит ее заказчику еще раз позднее. Особенно это имеет смысл, когда запланировано несколько поставок (проектных фаз), соответственно и производительность системы может наращиваться постепенно. Как видно на графике б), удовлетворенность заказчика при достижении значения 100 одновременно работающих с системой пользователей будет равным приблизительно 70%. Я полагаю, что в такой ситуации заказчик скорее всего пойдет навстречу команде разработчиков и предпочтет в срок получить работающую систему, с более низким значением критерия производительности, чем согласиться переносить сроки внедрения.
Рис.8. Функции значения показателя производительности.
На графике с) отражена аналогичная ситуация с той лишь разницей, что в данном случае заказчик заинтересован в минимизации значения критерия производительности. Например, время выполнения системой поискового запроса не должно превышать 3 с. При том как следует из графика достижение системой значения этого показателя равного 5 с дает около 90% удовлетворенности заказчика, и даже 7 с дают около 70%, следовательно, как показывает график, все, что лучше 7 с, но недотягивает до 3 с, может быть принято заказчиком, после дополнительных переговоров и, наверняка, при условии бесплатной доработки системы в будущем. Команда может сдать проект вовремя, а затем в следующей поставке улучшить систему в соответствии с первоначальными требованиями.
В некоторых случаях удовлетворенность заказчика значением показателя производительности можно описать функцией д). Это достаточно редкий случай, когда требуется определенная величина, но отклонение от нее в допустимых пределах все еще являются приемлемыми, хотя степень удовлетворенности заказчика при этих отклонениях снижается.
Понимание аналитиком функции значения показателя производительности, особенно если он ключевой, может помочь команде разработки на более поздних этапах проекта, поэтому стоит уделять этому вопросу достаточно внимания при сборе требований.
Предисловие
Главные вопросы: Зачем? Для кого? Что?
Как читать эту книгу. Структура книги. Ограничение ответственности
Введение
Что такое требования?
Коммуникация при разработке систем
Область проблем и область решений
Количество требований и выбор решения
Проблемы, связанные с преждевременным переходом в область решений
Управление ожиданиями заказчика
Типы требований
Требования и качество
Требования и моделирование
Требования и изменения
Источник изменений — заказчик
Рынок как источник изменений
Разработчики как источник изменений
Другие характерные трудности
Высокая неопределенность
Разный культурный и образовательный уровень участников проекта
Противоречия
Использование естественного языка
Объем и глубина проработки требований
Обзор процесса разработки требований
Глава 1. Определение заинтересованных сторон и их представителей
Заинтересованные стороны в проекте
Определение представителей заинтересованных сторон для сбора требований
Диаграмма взаимодействия
Выбор представителя заинтересованной стороны
Заинтересованные стороны и их цели
Заинтересованные стороны и их проблемы
Заключение
Глава 2. Сбор требований
Обзор источников требований
Планирование сбора требований
Люди как источник для сбора требований
Подготовка к встрече
Интервью
С чего начинается встреча?
Как сесть?
Установить контакт
Введение
Вопросы и ответы
Окончание встречи
После встречи
Телефонные переговоры
Переписка
Групповые встречи
Семинар рабочей группы (Requirements Workshop)
Опросы
Другие способы получения требований
Наблюдение за работой людей
Временное выполнение аналитиком текущей работы будущих пользователей системы
Эксперты и консультанты
Системы
Документы
Обращения в службу поддержки
Прототипы
Опасные прототипы
Заключение
Глава 3. Работа с собранными требованиями
С чего начинается хороший документ
Структура требований
Текст требований
Атрибуты требований
Ключевые требования
Ключевые критерии производительности
Заключение
Глава 4. Проверка требований
Важность проверок
Виды проверок
Неформальные проверки коллегами (Peer Review)
Критерии проверки текста требований
Критерии законченного набора требований
Еще немного о проверках
Заключение
Литература
Аннотация
Эта книга о том, как собирать, документировать и проверять требования. Она рассчитана на самый широкий круг читателей: начинающих аналитиков, проектировщиков, архитекторов, разработчиков, тестировщиков, руководителей проектов, и других специалистов задействованных в проектах по разработке ПО на ранних стадиях.
Читатель, независимо от того работает ли он на стороне компании разработчика, является или он представителям заказчика, или работает в ИТ-отделе компании, не связанной с разработкой ПО, может найти в книге полезные для себя советы и рекомендации.
Книга написана на основе более чем пятнадцатилетнего опыта автора, а также по материалам авторских курсов по разработке и управлению требованиями.
Фрагмент из Главы 3.
Ключевые критерии производительности
Другая концепция очень мало распространена в области разработки требований — это Ключевые Критерии (или Показатели) Производительности. Этот термин известен всем. В оригинале это всем известные KPIs — Key Performance Indicators. Но смысл этого термина с точки зрения применения его в области разработки требований нуждается в уточнении.
По аналогии с Ключевыми Требованиями, Ключевые Критерии Производительности определяют значения параметров производительности системы, без достижения которых система не будет полезна заказчику, а, следовательно, не может быть принята в промышленную эксплуатацию.
Стоит сразу пояснить, почему этому вопросу я уделил внимание. Неоднократно я видел ситуации, когда критерий производительности записывался в виде:
21.1. Система должна сохранять информацию, введенную на любой форме не более чем за 2 с.
или
21.2. Система должна возвращать результаты поиска не более чем за 5 с.
В принципе нормальные критерии производительности. Однако что же может произойти, если вдруг в конце проекта обнаруживается, что система не удовлетворяет одному из них? Во-первых, почему в конце? Во-во вторых, что же происходит?
В конце, потому что параметры производительности обычно проверяются, когда разработан и проверен весть перечень функциональных требований. А происходит следующее: недостатки в производительности системы обычно кроются на достаточно низком уровне, как разработчики говорят — «в ядре». И начинаются достаточно низкоуровневые правки кода, которые, нередко приводят к появлению проблем с работающими и уже оттестированным функциональными возможностями системы. Если выражаться на сленге разработчиков — «мы начали тюнить пеформас и это привело к коре рефакторингу, из-за чего поехал функционал». Т.е. пытались добиться соответствия параметрам производительности, а в итоге сломали систему, и это, я напомню, в конце проекта. В итоге команда попадает в цейтнот, все начинают работать сверхурочно, теряется внимание, и, в конце концов, команда может подойти к дате сдачи проекта с нерабочей системой.
Как же может аналитик помочь свой команде в ситуации, когда система на поздних этапах не удовлетворяет критериям производительности? Во-первых, аналитик должен попытаться определить вместе с заинтересованными сторонами, какие критерии производительности являются действительно ключевыми, и без их достижения система не может быть внедрена в промышленную эксплуатацию. Во-вторых, аналитик на этапе сбора требований должен понять функцию каждого критерия производительности, особенно это важно для ключевых.
На Рис.8 показано четыре функции показателей производительности. Зачастую аналитики ограничиваются первой функцией, т.е. фиксируют определенную величину. На самом деле это достаточно редкий случай.
Разберем пример на графике а) Заказчику нужно чтобы система поддерживала 100 одновременно работающих пользователей. Это значит, что у него есть 100 реальных пользователей и меньше быть не может, а больше в обозримом будущем не ожидается.
Графики б) и с) отражают более распространенные случаи. Для большинства web решений нагрузка носит вероятностный характер, что значит, что требование о том, что система должна поддерживать 200 одновременно работающих с системой пользователей, скорее всего также носит характер прогноза. Более того для новых сайтов количество одновременно работающих пользователей в начале работы в режиме промышленной эксплуатации может быть значительно меньше. Следовательно, если команда сталкивается с проблемами при удовлетворении этого критерия производительности, возможно, стоит не пытаться решить эти проблемы за оставшиеся несколько дней до окончания проекта, а договориться с заказчиком о приемке системы с более низким значением этого показателя, при условии, что команда потом доработает систему и поставит ее заказчику еще раз позднее. Особенно это имеет смысл, когда запланировано несколько поставок (проектных фаз), соответственно и производительность системы может наращиваться постепенно. Как видно на графике б), удовлетворенность заказчика при достижении значения 100 одновременно работающих с системой пользователей будет равным приблизительно 70%. Я полагаю, что в такой ситуации заказчик скорее всего пойдет навстречу команде разработчиков и предпочтет в срок получить работающую систему, с более низким значением критерия производительности, чем согласиться переносить сроки внедрения.
Рис.8. Функции значения показателя производительности.
На графике с) отражена аналогичная ситуация с той лишь разницей, что в данном случае заказчик заинтересован в минимизации значения критерия производительности. Например, время выполнения системой поискового запроса не должно превышать 3 с. При том как следует из графика достижение системой значения этого показателя равного 5 с дает около 90% удовлетворенности заказчика, и даже 7 с дают около 70%, следовательно, как показывает график, все, что лучше 7 с, но недотягивает до 3 с, может быть принято заказчиком, после дополнительных переговоров и, наверняка, при условии бесплатной доработки системы в будущем. Команда может сдать проект вовремя, а затем в следующей поставке улучшить систему в соответствии с первоначальными требованиями.
В некоторых случаях удовлетворенность заказчика значением показателя производительности можно описать функцией д). Это достаточно редкий случай, когда требуется определенная величина, но отклонение от нее в допустимых пределах все еще являются приемлемыми, хотя степень удовлетворенности заказчика при этих отклонениях снижается.
Понимание аналитиком функции значения показателя производительности, особенно если он ключевой, может помочь команде разработки на более поздних этапах проекта, поэтому стоит уделять этому вопросу достаточно внимания при сборе требований.
ОГЛАВЛЕНИЕ
Предисловие
Главные вопросы: Зачем? Для кого? Что?
Как читать эту книгу. Структура книги. Ограничение ответственности
Введение
Что такое требования?
Коммуникация при разработке систем
Область проблем и область решений
Количество требований и выбор решения
Проблемы, связанные с преждевременным переходом в область решений
Управление ожиданиями заказчика
Типы требований
Требования и качество
Требования и моделирование
Требования и изменения
Источник изменений — заказчик
Рынок как источник изменений
Разработчики как источник изменений
Другие характерные трудности
Высокая неопределенность
Разный культурный и образовательный уровень участников проекта
Противоречия
Использование естественного языка
Объем и глубина проработки требований
Обзор процесса разработки требований
Глава 1. Определение заинтересованных сторон и их представителей
Заинтересованные стороны в проекте
Определение представителей заинтересованных сторон для сбора требований
Диаграмма взаимодействия
Выбор представителя заинтересованной стороны
Заинтересованные стороны и их цели
Заинтересованные стороны и их проблемы
Заключение
Глава 2. Сбор требований
Обзор источников требований
Планирование сбора требований
Люди как источник для сбора требований
Подготовка к встрече
Интервью
С чего начинается встреча?
Как сесть?
Установить контакт
Введение
Вопросы и ответы
Окончание встречи
После встречи
Телефонные переговоры
Переписка
Групповые встречи
Семинар рабочей группы (Requirements Workshop)
Опросы
Другие способы получения требований
Наблюдение за работой людей
Временное выполнение аналитиком текущей работы будущих пользователей системы
Эксперты и консультанты
Системы
Документы
Обращения в службу поддержки
Прототипы
Опасные прототипы
Заключение
Глава 3. Работа с собранными требованиями
С чего начинается хороший документ
Структура требований
Текст требований
Атрибуты требований
Ключевые требования
Ключевые критерии производительности
Заключение
Глава 4. Проверка требований
Важность проверок
Виды проверок
Неформальные проверки коллегами (Peer Review)
Критерии проверки текста требований
Критерии законченного набора требований
Еще немного о проверках
Заключение
Литература
