Software requirements

Book description here

Wiegers K. E., Beatty J. Software requirements / K. E. Wiegers, J. Beatty, 3-е изд., Redmond, Washington: Microsoft Press, 2013. 637 c.

Оценка авторской мысли

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

Конспект

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

Важность работы с требованиями:

  • минимизация “переделок” на более поздних этапах работы над ПО за счет раннего выявления несоответствий в требованиях;
  • повышение вероятности успеха системы за счет учета всех ролевых интересов, особенно интересов конечных пользователей (при условии должного их вовлечения в процесс работы над требованиями);
  • снижение стоимости сопровождения системы;
  • борьба с раздуванием скоупа (объема работ и ожидаемого результата) проекта.

Проблемы с требованиями возникают из-за:

  • неформальный обмен информацией о требованиях и (особенно) их изменениях;
  • неявно подразумеваемая функциональность;
  • неозвученные или неверно сформулированные предположения о том, как должна работать система;
  • недостаточно четкие требования;
  • неформализованный и хаотичный процесс изменений (отсутствие управления изменениями).
Требование
описание поведения, свойства или атрибута системы. Может выступать ограничением для процесса разработки системы.

Явно выделены три уровня требований:

  • Бизнес-требования - концепция системы. Это “почему” системы. Вероятно, стоит это рассматривать как запрос, пришедший из надсистемы.
  • Пользовательские требования - это “что” системы, описание задач, выполняемых пользователями.
  • Функциональные требования - это “как” системы, описание поведения в различных ситуациях.

Выделяют также и “требования к системе”, при этом под системой понимают некоторую композицию из железа, софта и людей. Но в целом такое рассмотрение кажется “субъективным” и зависящим от интересующего нас системного уровня. Даже одну софтовую систему можно рассматривать как композицию функциональных компонент.

Инженерия требований состоит из разработки и управления.

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

Явно о рисках в процессе разработки требований мы, похоже, редко думаем.

Управление требованиями - это по сути, управление конфигурацией (изменениями) в части требований, то есть определение базовых версий, веток, учет изменений и взаимосвязей требований, а также трассировка от требований до других артефактов разработки.

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

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

Действительно ли речь идет о требованиях на всех этих уровнях? Или все же требования "заканчиваются" на уровне продукта в целом, а дальше лишь создаются разные модели/описания, в конечном итоге позволяющие запустить приложение на серверах или клиентских устройствах? То есть, поскольку мы не можем "выполнить" (в смысле развернуть и запустить) непосредственно требования, то мы должны транслировать их в такую форму, которая может быть запущена. И вот эта трансляция проходит через много этапов преобразований, прежде чем превратится в исполняемый артефакт. Но тут сразу еще вопрос возникает, а в чем разница с этой точки зрения между бизнес-требованиями и функциональными требованиями? И те, и другие нельзя запустить на выполнение. Функциональные требования получены путем детализации бизнес-требований. Почему тогда макет UI, который нельзя запустить на выполнение, и который получен путем детализации функциональных требований, сам не может являться требованием?

Глава 2. Требования с точки зрения клиента

Права клиентов:

  1. Разговаривать с бизнес-аналитиками на языке бизнеса. Основой могут служить глоссарии. Снова Различные языки в процессе разработки ПО.
  2. Ожидать от бизнес-аналитиков изучения предметной области.
  3. Ожидать, что бизнес-аналитик зафиксирует требования в понятной форме.
  4. Получать объяснения практик и артефактов работы с требованиями.
  5. Изменять требования.
  6. Ожидать взаимного уважения.
  7. Слышать идеи и альтернативы по поводу требований и их возможной реализации.
  8. Описывать дополнительные характеристики продукта, позволяющие работать эффективнее.
  9. Узнавать от команды разработки о способах изменения требований таким образом, чтобы ускорить разработку за счет переиспользования решений и общих механизмов.
  10. Получить систему, отвечающую функциональным нуждам и соответствующую ожиданиям по качеству.

Обязанности клиентов:

  1. Обучать команду разработки особенностям предметной области.
  2. Уделять время прояснению и уточнению требований. Лушче в виде сфокусированных воркшопов.
  3. Конкретно и точно сообщать информацию о требованиях.
  4. Принимать своевременные решения о требованиях.
  5. Уважать оценки стоимости и технической возможности реализации требований от команды.
  6. Устанавливать реалистичные приоритеты реализации требований вместе с командой.
  7. Проверять документацию по требованиям и оценивать прототипы.
  8. Устанавливать критерии приемки.
  9. Без промедлений сообщать бизнес-аналитикам об изменении требований.
  10. Уважать процесс разработки требований.

Глава 3. Рекомендуемые приемы формулирования требований

Для того, чтобы начать быстро осваивать разные практики/способы выполнения работ/ виды деятельности/методы получения результата (всё это разными словами одно и то же), сначала нужно научиться замечать их у себя и других, разговаривать о них, размышлять о них как о специальных объектах, требующих вашего внимания. Пока вы не заметили, что вы занимаетесь испытаниями какого-то оборудования как выделенным видом деятельности, нет шанса это делать быстро, надёжно, результативно, без новичковых ошибок. Как только заметили, появляется шанс этому научиться (погуглить, найти учебник и прочесть его! И потом делать, как написано в учебнике, а не как попало! Удивительно, как много людей даже не подозревают, что по их деятельности есть учебники, и эти учебники реально полезны!).

Системное саморазвитие

Ситуативные инструменты, создаваемые “по запросу”, редко позволяют получить выдающиеся результаты.

Глава 4. Бизнес-аналитик

Глава 10. Документирование требований

На очень “подвижных” проектах может показаться, что документирование требований того не стоит, т.к. занимает слишком много времени, особенно если учесть, что изменчивый характер проекта может в любой проект “отменить” любые требования (и таким образом, время окажется потраченным впустую). Это заблуждение, т.к. затраты времени на фиксирование приобретенных знаний куда меньше, чем затраты времени на получение этого знания или его реконструкцию в случае утраты.

Экзокортекс важен для собранности и качества результатов

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

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

Смысловое иерархическое кодирование требований. Типа Order.Discount.Error.

Неизвестные или пока несформулированные требования можно заменять на TBD (to be determined). Перед началом разработки все TBD должны быть обработаны и либо превращены в требования, либо выброшены из скоупа очередного инкремента.

Определить степень формальности при фиксации требований можно, рассмотрев следующие факторы:

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

Глава 17. Валидация требований

Зачастую некоторые активности не включаются в график работ из опасения, что они задержат поставку. Неявно это свидетельствует о том, что лица, принимающие решения, считают ROI таких активностей нулевым (или даже отрицательным). То есть, если мы добавим день работ и тем самым сэкономим полдня (50% ROI), то задержим поставку на полдня. В реальности же у многих (особенно управленческих) решений ROI намного выше 100%.

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

Инспекция - формальный процесс.

Участники должны представить четыре точки зрения на инспектируемую сущность:

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

Роли в процессе инспекции:

  • Автор - пассивная роль, чтобы иметь возможность слушать, отвечать на вопросы (предоставлять дополнительную информацию, а не дискутировать) и думать.
  • Модератор
  • Читатель - описывает требования своими словами, по одному за раз. Это дает возможность обнаружить тонкие несоответствия и отличия в интерпретации.
  • Секретарь - записывает обнаруженные в ходе инспекции проблемы, обязательно предъявляет написанное участникам, чтобы вместе сформулировать наиболее точные описания.

В главе 7 приведен набор техник для обнаружения пропущенных требований.

Практически каждая практика работы над качеством обнаруживает несколько дефектов.

Software requirements

Прототипирование требований в нашем случае может выполняться с помощью wireframes, макетов с низкой детализацией.