Comments 2
Советы толковые. Однако суждения слишком категоричны. Стоило бы в начале статьи задать контекст, очертив тем самым область применимости описанного подхода: указать методологию разработки, структуру команды, способ взаимодействия с заказчиком и пр. И ещё не понятно, почему описаны всего лишь две проблемы. Указаны самые болезненные или наиболее типичные для такого рода проектов?
Я описал 2 основные с моей точки зрения проблемы управления требованиями в проектах разработки софта: описание что делать и зачем делать. Конечно же этот список не исчерпывающий, есть еще, например, необходимость понять «когда и как это менялось» или трассировка требований. Но зато если решить хотя бы эти две, то сразу можно переходить к написанию кода (ну или к оценке трудоемкости).
Sign up to leave a comment.
Документирование требований: мелкие ошибки, порождающие крупные проблемы