Артефакт: требования
Оригинал взят у dz в Артефакт: требования
(Чувствую себя человеком, который должен изложить Войну и Мир на двух страничках.)
Требования - центральный, ключевой и неотъемлемый документ в процессе разработки ПО.
Тема работы с требованиями описана в сотнях книг и, конечно, я не смогу раскрыть эту тему во всей полноте в краткой статье. Даже, наверное, не смогу пробежаться по всем верхам. Однако, я готов дополнять её и писать другие статьи - уточняйте, что бы вы хотели увидеть в дополнение к сказанному.
Хочу ещё раз подчеркнуть важность этого документа (или группы документов) - ошибка в требованиях или пропущенное требование могут привести к катастрофическому объёму переработок на проекте, срыву сроков в разы, и даже к провалу проекта в целом. Приведу "бытовой" пример - если в требованиях к автомобилю вы забыли указать, что максимальная скорость - 350 км/ч, то автомобиль-то в итоге проекта у вас получится, а вот формулу 1 на нём уже никак не выиграть. И переделать такой автомобиль в машину для формулы 1 - это, фактически, начать проект заново. И напротив - забыв указать клиренс, вы рискуете получить потрясающий суперкар, но не доехать на нём до любимой заимки в лесу.
Общее описание
Требования описывают результат работ. Причём не как нибудь, а, фактически, в виде критериев приёмки работ. Каждое требование описывает некоторое свойство итоговой системы, причём описывает так, чтобы существовал однозначный и достижимый (за разумное время и деньги) способ проверить, существует свойство, или нет.
Очень важно понимать, что требования должны быть отвязаны от способа реализации: требования описывают, каков должен быть результат, а не как его достичь. Конечно, фактически при написании требований мы имеем некоторую рамку (например - обсуждается веб-приложение, или обсуждается приложение, которое точно будет работать на платформе .net), но эта рамка тоже должна быть зафиксирована в виде требований.
Требования могут проистекать снаружи, от заказчика (и это основной объём требований) и изнутри, от исполнителя (или от технической службы заказчика) - во втором случае требования, как правило, описывают именно технические ограничения на реализацию. Если требование связано именно с данным конкретным исполнителем, его нужно маркировать соответствующим образом, чтобы отличить от основных, сущностных требований. Впрочем, лучше перенести такие требования в проектный документ (HLD).
Для неопытного читателя будет полезен простой пример.
Примеры нормальных требований:
Безусловно, доходить до полного маразма при формулировании требований тоже не стоит, но надо понимать, что, к примеру, скорорсть работы программы одним числом не описывается. Давайте попробуем переписать требование "Программа должна работать быстро" безупречным образом.
Занудство? Да. Поэтому стоит подумать, надо ли вообще выкатывать такое требование, или положиться на общую вменяемость и традиции отрасли.
Вообще, требования в целом должны быть:
Каждое требование должно включать в себя:
Требования являются источником информации для абсолютно всех последующих артефактов в проекте. От них не зависят только концепция проекта и устав проекта. Да и то, за устав я бы не поручился.
Требования обеспечивают идентичное понимание задачи заказчиком и всеми сотрудниками на проекте.
Требования являются (единственным!) основанием для принятия проектных решений.
Требования являются основанием для написания тест-плана, а в определённых случаях могут и вовсе заменить собой тест-план.
Требования являются основанием для плана приёмо-сдаточных испытаний или, опять же, сами являются критерием приёмки проекта.
Автор
Требования разрабатываются аналитиком проекта или группой аналитиков. Источником данных является концепция и интервью со стейк-холдерами проекта.
Требования проходят ревью практически всеми ключевыми участниками проекта:
Требования подписываются кровью заказчика. Ей же подписывается каждое изменение требований.
Процесс изменения требований
Наверное, я про это напишу отдельный пост. Кратко:
Стейкхолдеры
Источником требований являются так называемые стейкхолдеры. Люди, чьё мнение о результате важно для проекта. Найти таких людей - большое умение. Примеры типовых ошибок:
Про это тоже можно говорить вечно. Есть старая поговорка: бардак автоматизировать нельзя. Смысл её в том, что пытаясь разработать автоматизацию для каких-то процессов вы выясняете, что процессы нестабильны, плохи или вовсе неверны. Это означает, что, де-факто, заказчику надо нанести непоправимый консалтинг, простроив для начала сами процессы в бизнесе. Но вас для этого не звали и заказчик сомневается, что вы способны. Есть три выхода:
В фактическом проекте иногда возникают противоречащие друг другу требования. Например, в силу того, что генеральный директор представляет себе некоторый процесс одним образом, а реально он идёт другим. В целом задача аналитика в том, чтобы дойти до разрешения такой ситуации. Понятно, что в целом конфликты такого рода лежат в плоскости психологии, а не проектного управления, но, с другой стороны, если бы из проектного управления можно было бы выкинуть психологию, в ней перестали бы быть нужны мы. Люди.
Обозначим подходы к решению:
Требования, не верифицированные заказчиком, имеют не слишком большую, а иногда и отрицательную ценность. Заставить заказчика их читать - трудно.
Важность требований в проекте невозможно переоценить. Прохалявьте все остальные документы, но с этим работайте тщательно и детально. Убейте клиента, но заставьте его разобраться в ваших требованиях и правда понять их. Аналогично с коллегами по проекту.
Домашнее задание
Напишите требования к сегодняшнему ужину.
Лирическая отмазка (disclaimer)
Мне стыдно за то, что я попытался описать вселенную под названием "требования" в крошечной заметке, я глубоко осознаю тщету всего сущего и этого текста в частности, мироздание и боги CMMI - не убивайте меня.
Читателя прошу писать о том, в какие детали он хотел бы, чтобы я углубился.
(Чувствую себя человеком, который должен изложить Войну и Мир на двух страничках.)
Требования - центральный, ключевой и неотъемлемый документ в процессе разработки ПО.
Тема работы с требованиями описана в сотнях книг и, конечно, я не смогу раскрыть эту тему во всей полноте в краткой статье. Даже, наверное, не смогу пробежаться по всем верхам. Однако, я готов дополнять её и писать другие статьи - уточняйте, что бы вы хотели увидеть в дополнение к сказанному.
Хочу ещё раз подчеркнуть важность этого документа (или группы документов) - ошибка в требованиях или пропущенное требование могут привести к катастрофическому объёму переработок на проекте, срыву сроков в разы, и даже к провалу проекта в целом. Приведу "бытовой" пример - если в требованиях к автомобилю вы забыли указать, что максимальная скорость - 350 км/ч, то автомобиль-то в итоге проекта у вас получится, а вот формулу 1 на нём уже никак не выиграть. И переделать такой автомобиль в машину для формулы 1 - это, фактически, начать проект заново. И напротив - забыв указать клиренс, вы рискуете получить потрясающий суперкар, но не доехать на нём до любимой заимки в лесу.
Общее описание
Требования описывают результат работ. Причём не как нибудь, а, фактически, в виде критериев приёмки работ. Каждое требование описывает некоторое свойство итоговой системы, причём описывает так, чтобы существовал однозначный и достижимый (за разумное время и деньги) способ проверить, существует свойство, или нет.
Очень важно понимать, что требования должны быть отвязаны от способа реализации: требования описывают, каков должен быть результат, а не как его достичь. Конечно, фактически при написании требований мы имеем некоторую рамку (например - обсуждается веб-приложение, или обсуждается приложение, которое точно будет работать на платформе .net), но эта рамка тоже должна быть зафиксирована в виде требований.
Требования могут проистекать снаружи, от заказчика (и это основной объём требований) и изнутри, от исполнителя (или от технической службы заказчика) - во втором случае требования, как правило, описывают именно технические ограничения на реализацию. Если требование связано именно с данным конкретным исполнителем, его нужно маркировать соответствующим образом, чтобы отличить от основных, сущностных требований. Впрочем, лучше перенести такие требования в проектный документ (HLD).
Для неопытного читателя будет полезен простой пример.
Примеры нормальных требований:
- Система должна обеспечивать возможность создания, модификации или удаления записи о сотруднике. (Надо понимать, что реализация этого требования в виде файла с логинами и паролями требованию соответствует.)
- Автомобиль должен быть способен проехать 500 километров без дополнительной заправки.
- Светильник должен потреблять не более 20 ватт.
- Система должна быть переносима на другие ОС. (Какие? За день? За год? Силами профессора или двух школьников?)
- Программа должна работать быстро. (1, 10, 100 или 1000 мсек? Одна запись за 1 мсек или 1000 за секунду?)
- Магазин должен принимать оплату картой. (Карта Мир пойдёт? Или Американ Экспресс? Или Виза нужна?)
Безусловно, доходить до полного маразма при формулировании требований тоже не стоит, но надо понимать, что, к примеру, скорорсть работы программы одним числом не описывается. Давайте попробуем переписать требование "Программа должна работать быстро" безупречным образом.
- Что такое "работать"? Давайте заменим на "реакция программы на действие пользователя" или, если это веб-система "время генерации страницы, измеренное с помощью jmeter на локальной машине". Вообще-то надо указать и производительность машины, но по-хорошему требования к железу у нас где-то присутствовать всяко должны.
- Каково время реакции? Мы хотим 100 мсек (кстати, это число должно откуда-то взяться, по хорошему, но пока этот вопрос опустим), но мы же понимаем, что время реакции - это не число, а распределение, график вероятности. И если 1% действий юзера вызовет реакцию в 500 мсек, это, наверное, приемлемо.
- Мало того - основные функции в 100 мсек запихать можно, а генерацию отчётов по огромной БД - нельзя.
Занудство? Да. Поэтому стоит подумать, надо ли вообще выкатывать такое требование, или положиться на общую вменяемость и традиции отрасли.
Вообще, требования в целом должны быть:
- Полны. Описывать все существенные свойства системы.
- Неизбыточны. Не стоит описывать то, что неважно или АБСОЛЮТНО очевидно. Впрочем, в моей практике был случай, когда требование "в системе должна быть авторизация" заказчик трактовал так, что, очевидно, должна так же быть авторизация и через фейсбук, потому что "так сейчас у всех принято". В целом то, что вы в требованиях не написали, сделано в проекте не будет.
- Проверяемы. Каждое требование можно проверить, при этом на проверку не должны уйти годы и аэродинамическая труба с ядерным реактором.
- Однозначны. Формулировка не должна допускать разночтений.
- Непротиворечивы.
- Отчуждаемы. Пишите так, как будто работать по ним будет другой разрботчик. Или марсианин.
Каждое требование должно включать в себя:
- Собственно формулировку. Предикат. "Автомобиль должен быть красным".
- Приоритет: Критический, важный, желательный. NB! Не более 30% требований должны оказаться критичными. Не 90!
- Версия или этап проекта, к которому относится требование. Одна из типовых ловушек для раздувания скоупа проекта - "давайте запишем все требования, а реализуем не все". Уточняйте в требовании явно - "не входит в скоуп текущего проекта".
- Степень проработанности или готовности. Если у вас, как обычно, нет времени дописывать все требования и разработка пошла по частично готовому документу, по крайней мере, помечайте требования как финализированные.
Требования являются источником информации для абсолютно всех последующих артефактов в проекте. От них не зависят только концепция проекта и устав проекта. Да и то, за устав я бы не поручился.
Требования обеспечивают идентичное понимание задачи заказчиком и всеми сотрудниками на проекте.
Требования являются (единственным!) основанием для принятия проектных решений.
Требования являются основанием для написания тест-плана, а в определённых случаях могут и вовсе заменить собой тест-план.
Требования являются основанием для плана приёмо-сдаточных испытаний или, опять же, сами являются критерием приёмки проекта.
Автор
Требования разрабатываются аналитиком проекта или группой аналитиков. Источником данных является концепция и интервью со стейк-холдерами проекта.
Требования проходят ревью практически всеми ключевыми участниками проекта:
- Ведущим аналитиком или начальником отдела аналитики: верификация качества требований.
- Заказчиком (всеми стейкхолдерами, как минимум один из них должен проработать требования полностью): верификация достоверности и полноты требований.
- Ведущим разработчиком или разработчиками: верификация реализуемости и выявление требований, требующих избыточного объёма работ. (В таком случае надо предложить клиенту ослабленные или, наоборот, ужесточённые требования, которые реализуются дешевле.)
- Менеджером проекта: он же, в итоге, должен будет отвечать за реализацию.
- Дизайнером или ответственным за UX: опять же, реализуемость и соответствие лучшим практикам.
- Системным администратором и архитектором: архитектура, нагрузочная способность, наличие ресурсов.
Требования подписываются кровью заказчика. Ей же подписывается каждое изменение требований.
Процесс изменения требований
Наверное, я про это напишу отдельный пост. Кратко:
- Детектируется потребность в изменении.
- Формулируется суть изменения, фактически - новое или изменённое требование.
- Делается оценка стоимости оценки стоимости изменения. Не самого изменения!
- Клиент подтверждает (как правило, для пачки запросов на изменение), что платит за оценку.
- Делается оценка стоимости изменения и импакт-анализ: какие артефакты проекта затрагиваются этим изменением.
- Клиенту предъявляется оценка изменения сроков и стоимости работ.
- Клиент подтверждает готовность оплачивать банкет.
- Изменение ставится в план работ, ему назначается версия.
- Требование вносится в рабочий актуальный документ "требования", предыдущая его версия бекапится. Внесённое требование явно помечается как изменение и указывается, с какой версии системы оно актуально.
- До команды на очередном стенд-апе доносится информация об изменениях.
Стейкхолдеры
Источником требований являются так называемые стейкхолдеры. Люди, чьё мнение о результате важно для проекта. Найти таких людей - большое умение. Примеры типовых ошибок:
- Снять требования с начальника отдела. Представления начальника о работе отдела, как правило, несколько оторваны от реальности. Обязательно нужно верифицировать с реальными исполнителями.
- Снять требования с убощицы, которая случайно забрела в кабинет финансового директора. Очевидно.
- Не снять требования с того, кто будет принимать проект.
Про это тоже можно говорить вечно. Есть старая поговорка: бардак автоматизировать нельзя. Смысл её в том, что пытаясь разработать автоматизацию для каких-то процессов вы выясняете, что процессы нестабильны, плохи или вовсе неверны. Это означает, что, де-факто, заказчику надо нанести непоправимый консалтинг, простроив для начала сами процессы в бизнесе. Но вас для этого не звали и заказчик сомневается, что вы способны. Есть три выхода:
- Забить.
- Убедить.
- Привести партнёра, который это умеет.
В фактическом проекте иногда возникают противоречащие друг другу требования. Например, в силу того, что генеральный директор представляет себе некоторый процесс одним образом, а реально он идёт другим. В целом задача аналитика в том, чтобы дойти до разрешения такой ситуации. Понятно, что в целом конфликты такого рода лежат в плоскости психологии, а не проектного управления, но, с другой стороны, если бы из проектного управления можно было бы выкинуть психологию, в ней перестали бы быть нужны мы. Люди.
Обозначим подходы к решению:
- Закопать конфликт под ковёр. Если вы понимаете (можете формально обосновать), какой вариант верен - решение можно "замылить" и описать в другой части документа или вообще в другом документе. Решение допустимое, но плохое. Однако если конфликт между носителями спорных вариантов жёсткий, это может оказаться единственным вариантом.
- Пойти по пути "вероятно, оба варианта неидеальны, давайте спроектируем третий". Это удовлетворит эго конфликтующих сторон, а что вы там придумали - не факт, что им будет интересно разбираться. Заказчик вообще читает требования только под дулом пистолета.
Требования, не верифицированные заказчиком, имеют не слишком большую, а иногда и отрицательную ценность. Заставить заказчика их читать - трудно.
- Делайте презентации. Читайте им требования вслух. Я не шучу.
- Делайте альтернативные представления. Юз-кейзы заказчик читает неохотно, а скетчи интерфейсов разглядывает с удовольствием.
- Разбивайте работу по верификации на разных сотрудников заказчика. Конечно, есть ответственное лицо от заказчика - тот, кто подписывает. Но если показать части требований именно тем, кто будет работать с конкретными подсистемами или отвечать за них - шансов на интерес куда больше.
Важность требований в проекте невозможно переоценить. Прохалявьте все остальные документы, но с этим работайте тщательно и детально. Убейте клиента, но заставьте его разобраться в ваших требованиях и правда понять их. Аналогично с коллегами по проекту.
Домашнее задание
Напишите требования к сегодняшнему ужину.
Лирическая отмазка (disclaimer)
Мне стыдно за то, что я попытался описать вселенную под названием "требования" в крошечной заметке, я глубоко осознаю тщету всего сущего и этого текста в частности, мироздание и боги CMMI - не убивайте меня.
Читателя прошу писать о том, в какие детали он хотел бы, чтобы я углубился.