Advanced Object Oriented Programming with Visual FoxPro 6.0
Collecting the requirements
The first step when collecting requirements is interviewing customers. How this is done depends a lot on the individual project. When creating custom database applications, you typically put on a nice suit, drive over to the customer's office, write down what he needs and that's it. The situation is very similar when creating in-house applications. The difference is that, instead of customers, you interview coworkers and usually you don't need a suit. When creating shrink-wrapped applications, this process is a little different because you usually don't get a lot of direct input.
Research for shrink-wrapped applications
When creating standard software that sells off the shelf, you usually don't have customers that provide a lot of input. In this case you can do surveys, listen to complaints and requests about previous versions of the product (if there was a previous version, of course), make educated guesses or simply look at the feature lists of competitors. Very often, the marketing department replaces the customer and provides the input you need. Usually, this will be based on management decisions rather than on users' needs. But this is a different topic that should be discussed in a different place.
Normally, a company that creates standard software is somewhat knowledgeable about the domain they develop for. So from a starting point, their situation looks a lot better than for the company that creates custom software. The next steps are a little harder, though. Research has to be done, and there are many different ways to do that. Domain experts and external consultants can be brought in, which isn't cheap. Another way is to do surveys, which is resource intensive. No matter how you do it, you have to talk to many different people because you are trying to create an application that fits many different needs. One difficulty attached to this process is filtering out requests that wouldn't be in many people's interest or that are simply stupid. You don't want to add feature number 4079 to your invoicing application just because one person would appreciate it. However, when creating custom applications, the users (theoretically) know exactly what they need, and that's what you have to give them. When creating shrink-wrapped applications, you'll have to compromise and try to satisfy everybody.
On the other hand, once you have your list of requirements, which is based on extensive research, the list of requirements for shrink-wrapped applications is less likely to change. This takes out one of the major difficulties for managing requirements.
Interviewing customers
Most FoxPro programmers are not in the shrink-wrap business. For this reason I will focus on custom applications. Whenever the need for a custom application arises (be it in-house or for a customer), the future users have a pretty good overview of their business problem. Typically, they are not able to express their needs clearly. Issues that are obvious to them are by no means obvious to you. Also, they are not aware of the possibilities, limitations and traps that the software world features. If they were, they wouldn't hire you to take care of possible issues, would they?
Your job is to make sure to get all the input you need to fully understand the situation. Your job is also to educate the customer about his options. If you are hired as a consultant, you should not blindly follow all the requirements the user writes down. Don't be afraid to fight battles over issues you consider critical. I've never had a customer who got mad at me because I argued about some issues. After all, he hired me to make sure everything went well. I have to admit that these arguments get emotional every now and then, and the customer might get upset. But that is far preferable to having an easy time during development, and delivering a product in the end that doesn't meet the expectations of the customer. Programmers are not paid big bucks to have an easy development time; they are paid for the final product they deliver. Keep that in mind when you interview your next customer
Every customer I've met so far has at least two reasons why he needs this new product: One reason that looks good, and the real reason. The list of such cases is long. The most common scenario seems to be the "upgrade scenario." Somebody calls you up and tells you he really needs to convert his database application into Windows, because his business grew a lot lately and he wants to take advantage of all the cool "new" features like WYSIWYG word processing, OLE and others. The old version works fine, but he'd like to use the new system to send out this mass mailing at the end of next month
Sooner or later you find out that the business didn't grow quite as much as he told you. The old application that "works fine" really loses a dozen records every day, the original programmer took off to enjoy the sunset in the Bahamas and now nobody can write an export routine to Word or recover the damaged database. The mailing turns out to be extremely critical, because unless the company makes a lot of sales in the next three months it will file bankruptcy, in which case you won't get paid. Had they told you sooner, you could have tackled the main problem right away, the mailing would have been ready even earlier than needed and everybody would be happy. Of course, this is a little exaggerated, but I'm sure you've seen similar scenarios.
A clear sign for such cases are extremely short deadlines for no apparent reason. If you can't figure out that reason, don't start the project (unless you are getting paid up front). You'll save yourself a lot of trouble. Every day, a couple of hundred thousand people across America need a software problem resolved. Don't pick the one who isn't even willing to tell you what he wants to achieve!
Another scenario is the "old-fashioned guy." He tells you how much he likes graphical user interfaces and all the other modern technologies. But as the project evolves, you discover that many of the features he wants don't really make sense in their environment. Sooner or later, you figure that the guy doesn't even like graphical interfaces all that much. Really and truly, he secretly never wanted to give up the command-line interface that he had used since his early pioneer days, when his company was the first one in the area to use computers.
In such projects you might discover requirements like a command-line interface that allows entering Visual FoxPro commands such as browse and edit (just in case, you know ). Maybe the customer even wants some non-objectified code in the core pieces of the system so he can maintain it himself. Another obvious symptom is the DOS-prompt shortcut he drops on your active desktop every time he uses your computer for five minutes because he couldn't imagine living without it. (Not that I don't use it myself every now and then, but don't mess with my settings, for heaven's sake!)
This mindset can also become obvious during the first presentations of prototypes or early implementations. You might demonstrate a feature that exports the current customer database to an HTML file, publishes it automatically on the Web and sends an e-mail to all your contacts informing them about the news. However, the customer might not be impressed by that feature (most likely because it was slightly over his head), but he might really like the hotkey you used to start the customer form.
I'm not saying that any of these scenarios is completely bad. The point I want to make is that you have to make sure you follow the correct targets. If the customer wants a DOS-like interface, I'd try to educate him about the advantages of the Windows interface. If he doesn't like it, fine. I can then decide whether or not I want to work on this project. If you discover after six months or one year that you've been hunting a phantom instead of achieving a simple goal, you'll end up very frustrated and accompanied by an angry customer.
What you can prepare beforehand
Before I visit a customer for the first technical meeting, I make sure I have a very basic overview of the general problem. Usually, I ask the customer to send me some written information or other material that might be helpful in understanding the situation. Having some initial knowledge usually impresses the customer and makes him more confident. The atmosphere is more relaxed and the customer talks more naturally about his situation, which helps us get to the point more quickly. It also gives me a basic idea of whether I have any code or design I might be able to reuse. Usually I do, so I take notes and documentation and maybe even some demos with me, which allows me to evaluate those things at the customer's site if necessary.
What you can expect
Your customers usually have a good idea about their needs and excellent knowledge about their business. This means that you have all the resources you need for your research. The main difficulty is getting the customer to provide this information not because he isn't willing to share it, but because issues might be obvious to him but strange to you. Also, it will be very hard for him to share all his knowledge with you in the limited time you have to work together. For this reason, he has to pick what seems to be the most valuable knowledge and provide that to you. However, what seems to be valuable to him might be less valuable for you, and vice versa.
Customers know what they need at least in general but often they aren't sure about the details. It's your job to make them think about those details in order to find logical pitfalls.
In addition to these issues, there is the fact that the requirements change. I will discuss this issue in more detail a little later.
Lay a good foundation
Keep in mind that the list of requirements you put together is the foundation of your project. If the list is weak, your application won't be any better. Don't leave room for interpretations. After creating the list of requirements, you need to go back to your customer and make sure it meets his expectations. (You might need to go back several times.) Insist that the customer takes the time to read over all those items and re-evaluate them in detail. Make sure he understands every single item that's on your list. Also, make sure you understand every item on that list. If something isn't entirely clear, don't make educated guesses. Just ask him! You might end up asking a stupid question every now and then, but that's nothing compared to the embarrassment of implementing a requirement entirely wrong.
A well-maintained list of requirements allows you to manage changes and trace them through several layers to the actual implementation. If you don't have a good way to maintain requirements, you lose those links right at the beginning of the development cycle.
Hitting a moving target
Often I see programmers and designers getting upset because the customer changes requirements. I have to agree that this is a frustrating part of our work, but nevertheless, it's natural and maybe even important.
There are several reasons for requirements to change. One I see very often is that requirements are simply collected poorly. But there are more serious reasons than that. Customers usually aren't familiar with the possibilities in modern software development. How could they be? Even we ourselves don't have a good idea about the possibilities if we are lazy with our reading for a couple of months! Customers typically put their requirements together by looking at other systems or by looking at the weaknesses of the current one. Of course, there is also the real business problem that is to be solved, but usually it takes a while for the customer to explain all those details to you. As the project proceeds, customers see what you do, they learn about new possibilities and they always want to go a step further. On top of that, facts are simply changing over time. The longer a project takes, the more likely requirements are to change. At the same time, changes naturally have a more severe impact in larger projects.
All these factors are serious quality problems. They can lead to highly defective applications or to total failure. Normally, people try to avoid those changes as much as possible, which is the natural and simple solution. Talk to your customer and make sure every change is there for a good reason. Explain the related problems and the possible consequences. Very often, changes become less important when the customer understands all the impacts. However, you will never be able to eliminate changes completely, and I seriously doubt it would be good to do so. If changes didn't occur, every large undertaking would be hopelessly outdated when it's finished, and therefore would be useless. For this reason, you need to be able to manage changes and implement them without taking a quality hit.
When following the suggestions in this chapter, you should be able to eliminate the risk of poorly created requirement lists. Such lists leave you with customers that are unaware of possibilities and the changing business world. You won't be able to stop the world from evolving, but you can educate the customers somewhat. Don't spend weeks training them in the latest version of Windows, but give them an overview of the current options that might help to solve their problem. I typically give a two- to three-hour talk explaining the latest technologies from a user's point of view, which I've found to be well worth the effort.
There is no easy way to handle the evolving business world and its changing requirements. But I recommend evaluating in a very critical manner the reasons why a requirement changed. Often it turns out that changes can be avoided. You might even be able to postpone or ignore them entirely. If they have to be taken care of, you need procedures and tools that guarantee you can implement them without losing control over product quality. Avoiding delays seems impossible. Even small changes will cause serious delays. The later you are in the development lifecycle, the longer the delay will be. There is no such thing as a change that can be implemented "real quick" shortly before releasing your product.