Организация требований к семействам продуктов

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

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

Разработать документ-концепцию семейства продуктов, который описывает способы совместной работы продуктов и их общие совместно используемые функции

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

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

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

Полученная в результате организация требований представлена на рис. 16.4.

Рис. 16.4. Организация требований для семейства программных продуктов

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

"Будущие" требования

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

Было бы неправильно включать такие требования в спецификации требований (не должно быть никаких сомнений относительно того, какие требования должны быть реализованы. а какие — нет). С другой стороны, неправильно было бы отбрасывать их,. так как они представляют собой полезные рабочие продукты; мы сможем использовать их при создании последующих версий. Еще более важно то, что проектировщики могу иначе разработать проект системы, зная, что в будущем возможны требования определенного типа. Лучше всего записывать оба типа требований в документ, но необходимо четко выделять те из них, которые планируется реализовать в текущей версии.