Attention: We are retiring the ASP.NET Community Blogs. Learn more >

Gathering requirements for a GUI application rewrite

 I have struggled with this for years (having been on 4 rewrite projects now) as a rewrite really does not fit into any process I have seen.  After much struggling, researching and thinking, I have come up with a plan that is working for me.  Many thanks to Ian Griffiths for his input on this:

 

1)      Four main lines of attack:

 

a.      Talk to the original system developers

b.      Talk to the users

c.      Use the system yourself

d.      Examine the code of the original system

 

2)      Document what the UI does:

 

a.      Write a section for each window/screen in the UI

                                                               i.      List all the things the window/screen can display

                                                             ii.      List all the actions a user can perform on this window/screen

                                                            iii.      List all the places a user can go to next from this window/screen, or all of the windows/screens that can be opened from this window/screen

                                                           iv.      List all of the ‘behind the scene updates’ that are out of the users control that happen when this window/screen is modified

                  b.      Compare the Lists in 1) with the functional requirements

                                                               i.      If its in the window/screen but not in the functional requirements, update the functional specs

                                                             ii.      If its in the functional specs but not on the window/screen, go back to the users

1.      Was it missed?

2.      Featured removed?

3.      Feature never should have been in the functional specs

 

1 Comment

  • The biggest problem with rewrites is scope creep. I would take the tactic of straight rewriting the application (fix ONLY technical errors). Then, when it was done, fix business errors. Otherwise you get into an endless loop of "since you're rewriting it anyway, let's do x, y, z...". So much is usually tacked on that nothing is ever finished.

Comments have been disabled for this content.