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

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

На мастер-классе мы разберём, какими критериями и принципами можно руководствоваться, чтобы выбранная декомпозиция как минимум не усложняла дальнейшее проектирование, отработаем эти критерии на конкретных примерах. 

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

Мы поговорим о том, почему одни требования реализуются двумя строчками кода, а другие - “надо еще 3 сервера БД”. Почему одни изменения - это “ничего страшного”, а другие - “мы все умрем!”. Попробуем разобраться вместе, а также обсудить, как этого избежать.

Есть информационная система. Работает, пользователи довольны, заказчик доволен. Команда как минимум не испытывает отвращения.

И тут: кто-то уволился, нужно немного разгрузить команду или заказчик попросил развития системы.

Появляетесь вы - аналитики - как новый сотрудник - взамен другого, или новый участник - теперь вы часть команды. 

Что известно про систему?  Описаны схемы и процессы? Описано как устроена системы и что делает каждая её часть? 

Отражено то, что систему окружает, и как окружение связано с системой?

Если практически ничего этого и вам не на что опереться - вам сюда. 

Не знаете, как это всё обрести - поделюсь нашим опытом. Знаете - с удовольствием выслушаю ваши замечания.

В итоге вы узнаете 4 правила археолога информационных систем и как их применять на раскопках.