系统重新设计，SyRS
如果您正在重新设计系统，并且正在为重新设计的系统版本编写 SyRS，请遵循 IEEE 1233 如何反向引用“旧设计”并提及它有什么问题？
我可以想到两种方法来做到这一点：
旧系统应该在新 SyRS 之外进行总结，而新 SyRS 应该简单地指定新系统，而不需要回溯“它是如何”的旧系统中的“完成”。
没有预先的旧系统摘要，相反，SyRS 将在指定新系统时不断参考旧系统及其内联问题。
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:
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.
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我想说#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.