2. Рекомендуемые практики
Что делает одну спецификацию требований хорошей, а другую плохой? Перефразируя Дэвида Парнаса, хорошая спецификация требований должна описывать всё необходимое для создания правильной системы — и ничего больше. Имеется ввиду баланс, которого нужно достичь в спецификации требований: мы должны указать всё, что нужно для создания системы, но при этом не слишком углубляться в проектирование. Часто говорят, что в требованиях должно быть указано, что система будет делать, но не как именно она будет это делать.

Однако объём информации в спецификации всегда оказывается большим, чем мы ожидаем там увидеть.

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

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

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

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

Эти 11 рекомендуемых методик подробно описаны в разделах 2.1–2.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 В зависимости от размера и стабильности проекта (или, напротив, вероятности изменений в нём) собирайте и поддерживайте информацию, которая поможет оценить важность каждой из целей системы по отношению к другим.
Что дальше
В следующем разделе рассмотрим подробнее каждый подпункт разработки общего описания системы.

Вперед к пункту 2.1.1!
Made on
Tilda