Принципы спецификации требований

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

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

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

Целесообразно разработать три категории моделей: модели состояний, модели поведения и модели изменения состояния. Эти модели дают формальное определение различных сторон (представлений) системы:

• • модели состояний детализируют требования к данным;
• • модели поведения обеспечивают детализированные спецификации для функциональных требований;
• • модели изменения состояния охватывают два вида требований: они призваны отразить, каким образом действие функций приводит к изменению данных.

Современные объектно-ориентированные методы проектирования программных систем диктуют представление моделей в виде диаграмм на языке визуального моделирования (Visual Modeling Language) — в данной работе это язык UML.

Обычно диаграмма служит целям моделирования одной из сторон системы — состояния, поведения или изменения состояния. Заметное исключение составляет диаграмма классов, которая определяет все три аспекта — состояние и поведение объектов, и косвенно изменения состояния объектов.

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

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

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

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