Редизайн системы, SyRS

Question

Если вы перепроектируете систему и пишете SyRS для перепроектированной версии системы, следуйте IEEE 1233 как делать обратные ссылки на " старый дизайн "и упомянуть, что с ним не так?

Я могу придумать 2 способа сделать это:

1. Старая система должна быть обобщена за пределами новой SyRS, а новая SyRS должна просто указывать новую систему без обратной ссылки на «как это было сделано» в старой системе.

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

Answer 1

Я бы сказал # 1.

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

Определите новую систему в положительном смысле. Другими словами, укажите, что должна делать новая система - и то, что она делала ранее в качестве старой системы, и новые функциональные возможности, и новые требования, которые по существу являются недостатками в старой системе. Но это должны быть функции / поведения для новой системы.

Если вы ссылаетесь на старую систему и пытаетесь исправить ее недостатки с помощью требований, вполне вероятно, что в итоге вы получите множество утверждений, которые выглядят как «не такие». Это, как правило, некорректное написание требований, поскольку его сложно тестировать и правильно реализовать.