Hello, and welcome to our blog for the
Requirements Engineering course!
I am Petr Viktorin, a student from Brno, Czech republic. In this introductory post, I'll tell you about a project I've been developing for the past three years: an information system for a small hotel.
There is a small hotel in Brno that used to manage everything on paper. They had huge A3 sheets to organize their reservations, a book of guests, a book of payments, separate papers for managing long-term guests. An eraser was used to cancel reservations. Each guest's name, and other details, had to be written about three times to three different places. Searching was next to impossible.
So, the management turned to computers. They tried out some existing hotel software, only to find that it it was not suited (or flexible enough) for their purposes: the main problem was that most of the people working at the reception counter had little or no computer experience, and learning complicated systems was simply beyond them.
So, the hotel turned to me.
My responsibility was to build and deploy the whole system, write documentation, and help train the employees to use it. I was given one year to build a basic production version, and another to add a payment system and other additions.
I chose C++, Qt and MySQL technologies to implement the system, a choice I never regretted later.
An enthusiastic employee (there was only one; the others were quite skeptical) helped me sketch out the requirements: ease of use, familiarity to users of the existing paper-based system, ability to safely work from multiple computers, details about what information to store and display. Most of these were not formalized; many of the few that were were quietly ignored or changed later as I learned about hotels and my client about computers.
For example, one of the stated requirements was a special kind of reservation for large groups. This reflected the fact that large reservations were handled very differently, and even by different people, than normal ones. However, normal reservations ended up being general enough, so this separation was never needed.
The important thing was communication: I discussed the development choices in a language normal people could understand, watched what users were doing wrong and adapted the program to make it easier to use and prevent mistakes. I kept the code modular and easy to change, so the constant requirement modifications did not cause many problems. Only in one case I had to rewrite a major portion, the reservation display screen.
A year later, most of the employees were thanking me for saving much of their work: now, each guest's name only has to be written once, and with regular guests, typing the first few letters of the name and a click is enough to put all the needed details in almost all the required places. (This is starting to sound like an ad, isn't it? :)
This project is still going on – I have about six items in my to-do list (or the list of unmet requirements, if you like): half of them have to do with changes in legislation – changed tax amounts and information that the law requires to be kept on file in printed form. The other half is making some common tasks easier to do.
Oh, and the documentation is still unfinished. Nobody would read it anyway; instead there is a few short „howto“ documents for less obvious things.
I believe that for this one-man project, this kind of natural handling of requirements was perfect, and any attempts at a more formal method would both slow the development down and confuse the client. I might be wrong, though – there might be a more effective way to do this, and that is why I enrolled in this course.
