При составлении документа, содержащего требования, следует тщательно соблюдать баланс между двумя аспектами:

• Документ с требованиями должен быть удобным для чтения.
• Набор требований должен быть технологичным, то есть удобным для работы с требованиями.

Свойства требований:

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

Жизненный цикл разработки ПО

Исходные модели:

• Waterfall Model каскадная модель, или «Водопад»
• V-model V-образная модель, разработки через тестирование
• Incremental Model инкрементная модель
• Iterative Model итеративная (или итерационная) модель
• Spiral Model спиральная модель
• Chaos model модель хаоса
• Prototype Model прототипная модель