2.5 Чтобы улучшить читаемость требований и сделать их устойчивыми перед лицом изменений, сгруппируйте требования по функциям, которые логически связаны друг с другом, с минимальными зависимостями между ними. Чтобы требования можно было масштабировать до больших систем, функции разбивают на более мелкие.
2.5.1 Организуйте функции в группы, которые тесно связаны и скорее всего при внесении изменений будут меняться вместе.
2.5.2 Используйте диаграммы потоков данных для графического отображения функций и их зависимостей.
2.5.3 Сведите к минимуму зависимости между функциями, гарантируя тем самым, что информация, которой они обмениваются, представляет собой стабильные высокоуровневые концепции из предметной области, которые вряд ли изменятся. Переместите зависимости, подверженные изменениям, как можно ниже в иерархии функций.
2.5.4 Определите тип, диапазон, точность и единицы измерения всех внутренних переменных, введенных для определения зависимостей данных между функциями.
2.5.5 Организуйте большие спецификации требований в несколько уровней, организуя функции в иерархии с учётом зависимостей данных.
2.5.6 Если вы описываете высокоуровневые требования, определите только то, что может быть заявлено на этом уровне иерархии. Не используйте термины, определённые на более низких уровнях иерархии.
2.5.7 При описании высокоуровневых требований к функции не указывайте обоснования в требованиях, даже если вы хотите детализировать требования, которые было бы уместнее указывать во вложенной функции.
Вся спецификация требований на инкубатор написана нами на нескольких страницах. Для реальной системы это, разумеется, было бы не так. Например, когда методология CoRE была применена к бортовым системам самолёта C-130J, насчитывалось более 1600 измеряемых и изменяемых переменных [6]. Чтобы ею было удобно пользоваться, спецификация требований к системе любого размера должна быть особым образом организована.
Чтобы хорошо организовать требования, нужно знать, как они будут использоваться. Одна структура может улучшить читаемость требований, в то время как другая — облегчить описание группы продуктов. Эти цели могут противоречить друг другу: организация для сопровождения группы продуктов может привести к созданию спецификации, которую труднее понять, чем спецификацию, разработанную для одного модуля. Автоматизированные инструменты могут помочь в этой задаче, создавая различные представления одной и той же базовой спецификации по мере необходимости.
Что дальше
В следующем разделе мы подробнее разберём, что стоит учитывать при разработке функциональной архитектуры.