Требования подробно описывают, что должна делать программная система, а их выработка – первый шаг к решению проблемы. Выработка требований также известна как "разработка требований", "анализ требований", "анализ", "определение требований", "спецификация", "функциональная спецификация".
Зачем нужны официальные требования?
Явные требования помогают гарантировать, что функциональность системы определяется пользователем, а не программистом. Если требования сформулированы явно, пользователь может проанализировать и утвердить их. Если явных требований нет, программисту обычно самому приходится вырабатывать их во время программирования. Явные требования позволяют не гадать, чего хочет пользователь.
Внимание к требованиям позволяет свести к минимуму изменения системы после начала разработки. Обнаружив при кодировании ошибку в коде, вы измените несколько строк, и работа продолжится. Если же во время кодирования вы найдете ошибку в требованиях, придется изменить проект программы, чтобы он соотвествовал измененным требованиям.
Адекватное определение требований – одно из важнейших условий успеха проекта, возможно, даже более важное, чем использование эффективных методов конструирования.
Миф о стабильных требованиях
Требования подобны воде. Опираться на них легче, если они заморожены.
При стабильных требованиях смена этапов разработки архитектуры, проектирования, кодирования и тестирования приложения происходит упорядоченно, предсказуемо и спокойно.
Всем нам хотелось бы надеяться, что, как только клиент утвердил требования, никаких изменений не произойдет. Однако чаще всего клиент не может точно сказать, что ему нужно, пока не будет написан некоторый код. Процесс разработки помогает им лучше понять собственные потребности, что частоприводит к изменению требований.
Что делать при изменении требований во время конструирования программы?
Следующие действия позволяют максимально легко перенести изменения требований во время конструирования.
Оцените качество требований Если требования недостаточно хороши, прекратите работу, вернитесь назад и исправьте их.
Убедитесь, что всем известна цена изменения требований Если руководители вашей организации не понимают важность предварительной выработки требований, укажите им, что изменения во время выработки требований обходятся гораздо дешевле, чем на более поздних этапах.
Задайте процедуру контроля изменений Если клиент никак не может успокоиться, подумайте об установлении стенда контроля изменений для рассмотрения вносимых предложений.
Используйте те подходы к разработке, которые адаптируются к изменениям Некоторые подходы к разработке ПО позволяют особенно легко реагировать на изменения требований. Подход эфолюционного прототипирования (evolution prototyping) помогает исследовать требования к системе до начала ее создания.
Оставте проект Если требования особенно неудачны или изменчивы и никакой из предыдущих советов не работает, завершите проект.
Помните о бизнес-модели проекта Многие проблемы с требованиями исчезают при воспоминании о коммерческих предпосылках проекта. Программисты, которые принимают во внимание коммерческие следствия своих решений, ценятся на вес золота.
Статья составлена из отрывков книги Стива Макконнелла, "Совершенный код".
