24 Combining and Refactoring
As you gather requirements, you will often notice that many features, functions, screen, pages, and other items will have a great deal of commonality. For instance, in a business-control setting, you’re likely to have a number of screens that search for various things, and list the results, such as finding and listing customers, finding and listing suppliers, finding and listing employees, and so on. Similarly, you’re likely to have screens to edit a customer record, to edit a supplier record, edit an employee record, and so on. You don’t want to be listing requirements for each of these separately, for two reasons. First, if there are 100 find and list screens, you don’t want to describe the action of the Search button 100 times, but even more importantly, you don’t want people implementing 100 separate Search buttons. As a cascaded effect, 100 implementations of Search would also need 100 QA efforts.
The remedy for this is for you to notice that, in general, there is a Search function, and in general, there is an Edit function. Typically, you’d document the requirements for a search-in-general, and for an edit-in-general, and then document those as “abstract” requirements, meaning that the requirements will hold for specific functions down the line, but are not a function in-and-of themselves. Sometimes you’ll be in a position to do this sort of documentation up-front, especially on Waterfall-oriented projects, but on an Agile-oriented project, you’re more likely to have a function or two documented before you see the same thing pop up again and realize the commonality of the functions. When that happens, the process is called “refactoring”, whereby the common part of the functions is factored out to its own abstract area, and the functions’ documentation just refers to the common area, and incorporates it by reference.
Typically, you won’t be involved in the code area or code design, but there are some things you should know about it anyway: In object-oriented (OO) programming (OOP) and design, we have “parent objects” and “child objects”. The “parent object” is often marked as “abstract”, meaning that it can’t operate on its own, but that it lays out certain data structures and/or behaviors that each of the “child objects” will “inherit”. For instance, if there’s going to be an “object” to search and display employees, named “SearchEmployee”, it will be marked as a child of some general search function, perhaps named “SearchGeneral”. In pure procedural programming, the search functionality will generally be in or moved to a generalized search function and a generalized listing function, which will be “called” by the specific search and list functions. In a Waterfall project, things will just be built this way. In an Agile project, things will be built this way if you didn’t have to refactor your requirements documentation, and will be refactored on the code side when you do have to refactor your requirements documentation. Don’t worry about upsetting the programmers with such requirements changes, because they’re used to doing this sort of refactoring, and may even notice and do this if you miss it, hopefully bringing it to your attention in the process.
