System re-design, SyRS

Question

If you are re-designing a system, and you are writing a SyRS for the re-designed version of the system, following IEEE 1233 how do you make backreferences to "the old design" and mention what was wrong with it?

I can think of 2 ways to do it:

1. The old system should be summarized outside the new SyRS, and the new SyRS should simply specify the new system without making back references to "how it was done" in the old system.

2. No old-system summary up-front, instead the SyRS will constantly refer to the old system and what was wrong with it inline, as the new system is being specified.

Answer 1

I'd say #1.

I think a summary of the old system, and it's major flaws as introductory matter (not requirements), is a win. From a communication/efficiency perspective, a new developer or tester should not have to learn all about the old system in order to work with the new system, but there should be some overall learning-from-mistakes that can happen at a higher level.

Define the new system in a positive sense. In other words, state what the new system should do - both the things that it previously did as the old system, and the new functionality, and the new requirements that are essentially flaws in the old system. But worded to be functions/behaviors for the new system.

If you refer to the old system and try to correct it's flaws through requirements, it's likely that you will end up with a lot of statements that come out as "not like that". That's generally faulty requirements writing, since it is both hard to test and hard to implement correctly.