80 likes | 104 Views
Discover the challenges in transitioning from requirements to design, including managing derived requirements. Learn why finding the "best" design solution is complex and iterative, with valuable tips for successful software design.
E N D
Reference • “Facts and Fallacies of Software Engineering” by Robert L. Glass, Addison-Wesley, 2003, ISBN: 0-321-11742-5
Design Fact 26 • When moving from requirements to design, there is an explosion of “derived requirements” (the requirements for a particular design solution) caused by the complexity of the solution process. The list of these design requirements is often 50 times longer than the list of original requirements.
Derived Requirements • Often the reason it is difficult to implement requirements traceability even though everyone agrees it is important to do so. • Simple design solutions are always sought, but only rarely found. • What if a requirement links to 50 or more design requirements? • The author can remember telling his software engineering students this in the early 1980s.
Design Fact 27 • There is seldom one best design solution to a software problem.
“One” and “Best” • Most software problems can be solved in many different ways. • It is extremely difficult to know whether you have found a “best” solution even if there were one. • You can certainly compare two solutions and find one better than another. But this comparison can be extensive and difficult. • Again, don’t let “simple” degenerate into “simplistic”
Design Fact 28 • Design is a complex, iterative process. The initial design solution will likely be wrong and certainly not optimal.
“Hard Part First” • Top designers pursue a design solution by pursuing targets of important opportunity. • Those targets of important opportunity are usually the difficult problems. You must eliminate these if a final solution is to be created.