Requirements Analysis

I got a call from a member of our requirements gathering team. She asked if the requirements for the latest change were good. I scanned them and decided not. Then I asked her what one of the main words in the requirements meant. She said she did not know, and was hoping I could figure that out when I designed the solution.

Now I can design all kind of goodness. I can create slick user interfaces. I can do database magic. And I know how to put together algorithms that work. But if I don't know what the customer wants, then I can't do much. I told the requirements analyst that she needed to figure out and understand what the customer was asking for. Only then could we move forward.

The next morning I get a message that I must attend a meeting with the customer. They were going to discuss the latest change. So the requirements analyst started asking the customer about some ideas she had. She imagined the customer wanted some sort of complex system based on the feedback they had already provided. This meeting was going nowhere. Then I was asked if the discussion answered my concerns. LOL!

I started at the beginning. First I went over how the current system worked. Then I started defining some of the new words the customer was using. Turns out they were just synonyms for other well known understood parts of the system. Then I took a concrete example, and walked the user through how they thought the system would need to work. Then I went through the main scenario a few more times, picking up more details, and getting confirmation and consensus from all the customers at the meeting.

Requirements analysis is hard. You cannot just act as a clerk and write down some ideas, hoping you have captured any requirements. You need to dig in. You need to get the customer themselves to think about what it is they want. Then you should walk through some concrete scenarios. Only then can you truly understand what it is you are talking about. I love designing and inmplementing software. But I definitely don't want to spend my life working on features that the customer does not want or even need.

Logging for C++

Our main apps write a log file to the local disk. This comes in handy when diagnosing bugs in the code. Some time this year, we had a bug. A manager thought we could look at the log to figure out the source. Well the log is not comprehensive. We just log things we think we might need. Now we are on the hook to add more logging!

A couple other manager types got involved. Their answer? Log4j! Well out code is written in C++. The managers said we should just implement the Log4j equivalent for C++. Hold on there partner. If we are going to add in a logging framework, shouldn't we check what is out there first? Yes indeed. I decided to look into the matter one afternoon. Here is what I found.

While there were many options to choose from, I found the most information on log4cxx, log4cplus, log4cpp, glog, and Pantheios. I paid attention to the license type each framework is released under. Also was interested in whether the framework is still being maintained.

Log4cxx is an Apache project. The config files match log4j. The project is being actively maintained. Log4cplus is a port of log4j. There is no a lot of documentation available for this project. Log4cpp is released under the LGPL. It is not an actively maintained project. It also goes by the name "Log for C++". Glog stands for Google Log. It is new, and is based on streams plus macros. It is released under a BSD license. It is thread safe. Pantheios is open source and type safe. It is recommended for large apps. It is simple to use. It is released under a BSD license.