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

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

Как определить момент завершения проекта, этапа проекта или итерации разработки?

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

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

Жизненный цикл любого проекта включает в себя этапы инициации, планирования, исполнения, контроля и завершения. Гибкие методологии и итерационный подход используют в проектах по разработке программного обеспечения всё чаще. С ними этапы проекта повторяются несколько раз для каждой итерации, а перечень инструментов аналитика максимально упрощается и сводится до написания user story. 

Этой статьёй я открою серию материалов про управление требованиями на разных этапах проекта.  Уже больше 10 лет я работаю в IT и успела побывать бизнес аналитиком, системным аналитиком и руководителем проектов. Также я выступаю в роли ревьюера на курсе «Системный аналитик». 

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