Вимоги користувача

Високорівневі мети організації і клієнта

Системні вимоги

Нефункціональні вимоги

Функціональні вимоги

наслідування від класів

чи відображають поняття і об'єкти область, що моделюється, об'єкти класів співпрацюють, щоб описати те, що має робити додаток?

архітектуру системи

як підтипи повинні бути замінні базовими типами

Низька захищеність системи

Клієнт (presentation layer) містить логіку програми - «Товстий» клієнт

Не гарантує цілісності даних при використанні декількома користувачами

Система важко масштабується

Компонент планувальник Production має залежність від планувальника Staff planner.

Планувальник Staff planner має залежність від компонента планувальника Production.

підтипи повинні бути замінні базовими типами

модулі верхнього рівня не повинні залежати від модулів нижнього рівня. Обидва повинні залежати від абстракції. Абстракції не повинні залежати від деталей. Деталі повинні залежати від абстракцій.

клієнти не повинні залежати від методів, які вони не використовують

не повинно бути більше однієї причини для зміни класу

програмні сутності повинні бути відкриті для розширення, але закриті для зміни

Простота системи досягається шляхом зменшення кількості її компонентів.

Простота системи важлива тільки на етпапі створення архітектури системи

Простота системи декларується в якості основної мети та / або цінності.

Кожен клас системи не повинен бути більше 300 рядків щоб забезпечити простоту розуміння коду.

Сontext.hlp та index.html не є компонентами

Внесення змін у вихідному коді програми або динамічній бібліотеці не призводить до змін у компоненті main.exe

Внесення змін у вихідному коді програми або динамічній бібліотеці призводить до змін у компоненті main.exe

Сторожовий перехід

Транзитивний перехід 

Рефлексивний перехід

Асоціативний перехід