Что делает одну спецификацию требований хорошей, а другую плохой? Перефразируем Дэвида Парнаса: «Хорошая спецификация требований должна описывать всё необходимое для создания правильной системы — и ничего больше». Имеется ввиду баланс, которого нужно достичь в спецификации требований: мы должны указать всё, что нужно для создания системы, но при этом не ограничивать разработчиков в решениях, слишком уходя в проектирование. Часто говорят, что в требованиях должно быть указано, что система будет делать, но не как именно она будет это делать.
Однако объём информации в спецификации всегда оказывается большим, чем мы ожидаем там увидеть.
Чтобы аудитория с очень разным опытом и интересами могла понять сформулированные требования, а мы были в состоянии поддерживать их качество в условиях изменений, нужно приложить немало усилий и выстроить процесс работы с требованиями.
Поэтому хорошая спецификация требований представляет из себя нечто большее, чем простой список утверждений «система должна». Рекомендации, описанные в этом руководстве, посвящены созданию такой структуры документации, которая будет гарантировать, что в вашем документе приведены полные, последовательные, понятные и хорошо организованные требования.
Как правило, разработка требований представляет собой переход от состояния, в котором о системе известно относительно мало — к состоянию, в котором известно очень много. Схожим образом, для эффективной разработки требований необходимо переходить от неформальных практик на ранних этапах определения требований к более строгим практикам, по мере завершения проработки требований.
Для крупных систем обычно нет смысла формулировать подробные требования без учёта конкретной архитектуры. Вместо этого разрабатываются высокоуровневые требования, выполняется проектирование следующего системного уровня (с выделением компонентов, прим. ред.) и для каждого компонента разрабатываются более подробные требования. Этот процесс продолжается до тех пор, пока не будет достигнут необходимый уровень детализации. По сути, спецификация требований чередуется с разработкой архитектуры системы.
В этом руководстве описаны 11 опорных рекомендаций, которые позволяют разработчикам двигаться от первоначального высокоуровневого обзора разрабатываемой системы к подробному описанию требований к её поведению и работе.
Вот они:
Создайте «Общее описание системы»
Определите границы системы
Разработайте концепцию эксплуатации
Определите ограничения среды
Разработайте функциональную архитектуру
Пересмотрите архитектуру с учётом ограничений
Определите режимы работы системы
Разработайте детальные требования к поведению и работе системы
Определите требования к программному обеспечению
Распределите требования по подсистемам
Приведите обоснования (требований)
Эти 11 методик подробно описаны в разделах 2.1 — 2.11.
За исключением последних двух, все они представлены примерно в том порядке, в котором выполнялись бы в программе разработки программного обеспечения, хотя это нельзя назвать последовательностью шагов, которую нужно обязательно строго соблюдать. И хотя эти методы применимы практически к любой разработке, в разных компаниях может потребоваться некоторая адаптация этих методов под свою практику.
В рамках каждого из рекомендуемых в данном руководстве опорных 11 методов даны и другие, более подробные рекомендации. Эти детальные рекомендации зависят от соответствующих им основных рекомендуемых методов и, скорее всего, компаниям придётся подстраивать их к существующим методам и инструментам. Подробно эти детальные рекомендации описаны в разделах 2.1.1 — 2.11.7.
2.1 Создайте «Общее описание системы»
2.1 Разработайте «Общее описание системы», которое должно включать в себя краткий обзор будущей системы и описывать все контексты, в которых её планируется использовать. Также в нём должны быть перечислены основные цели, задачи и ограничения системы. Это поможет определить область применения системы во время разработки требований, а новому читателю быстро сориентироваться в требованиях.
2.1.1 Разработайте «Общее описание системы» в самом начале разработки требований и используйте это как первый шаг к подготовке спецификации требований. Пишите высокоуровневые требования, чтобы документ можно было использовать для быстрого введения новых читателей в курс дела.
2.1.2 Предоставьте краткое текстовое описание системы (синопсис) в качестве первой части. В кратком описании следует назвать систему, описать её назначение и описать основные возможности.
2.1.3 Рассмотрите жизненный цикл разработки системы и сформулируйте каждый контекст её использования.
2.1.4 Используйте контекстные диаграммы для высокоуровневого визуального описания системы, внешних объектов, с которыми она взаимодействует, и этих взаимодействий.
2.1.5 Для каждой контекстной диаграммы предоставьте краткое описание каждого внешнего объекта и его взаимодействий с системой.
2.1.6 Зафиксируйте предварительный набор целей системы на ранней стадии процесса разработки требований, чтобы их можно было использовать для управления процессом разработки требований.
2.1.7 В зависимости от размера и стабильности проекта (или, напротив, вероятности изменений в нём) собирайте и поддерживайте информацию, которая поможет оценить важность каждой из целей системы по отношению к другим.
Что дальше
В следующем разделе рассмотрим подробнее каждый подпункт разработки общего описания системы.