15/09/2023

How it all started

It is summer 2005. I am almost done studying on AGH and will become Master Of Science in Telecommunications maybe in Autumn. For this to happen I still have to finish working on my thesis regarding multicast protocol PGM. However I also want to earn some money so I am working as a software tester in Comarch. During vacations I worked there full time on an IT project which is a standalone web application. One day I came to work and tested our application to find bugs and to properly document them so that developers can reproduce and fix them. It is morning time some two or three hours before lunch time and suddenly our Project Manager approaches my colleague Sergiusz. He tells Sergiusz that while he visited our customer the day before they told him we did our website in a wrong way. We should rather embed our application as a part of some existing webpage. This is shocking information for Sergiusz who is our HTML and JavaScript developer. Sergiusz gets very frustrated. Over the last few months he was developing the user interface as a standalone HTML webpage. He was in control of CSS (which controls the style of fonts, margins and other visual elements) and he had the whole space on the screen just for himself. Right now he has to use CSS which our client created. He also needs to fit our content into a much smaller space on the screen. It is not enough to say that Sergiusz was upset. He was pissed off. He started to swear and work in a rush. I was sitting next to him and just listening as I could not help in that situation. Sergiusz was frustrated and angry. Why is this communicated so late? Project is almost done. Why does it have to change only now? Whose fault is it?

You see we were very young, motivated and I think quite a talented team. The technology back in 2005 was hard to work with but we were developing interesting web applications. There was a sense of camaraderie and we were all in it together. I started wondering what went wrong with communication. We obviously didn’t have anything in writing. There were many emails, phone calls and face to face meetings between our PM and the client. It was later referred by the PM to the team.

This is just one of a series of events that showed me problems with communication regarding requirements. When I moved to Motorola I was creating test plans based on requirements delivered by Software Architects. What I saw were literally hundreds of mistakes done in the written requirements. They were too abstract, illogical, contradictory or missing. There were dozens of small decisions that had to be made every day in order to move forward with software development. Those things shall be explained inside requirements specification but they were not there. Our Software Architects were working from Motorola headquarters in Schaumburg near Chicago. We had a 7 hour time difference so it was about 3PM in Krakow when we could finally start talking with people from the US.

One day my whole career changed. In autumn 2008 I was doing routine health checks which every employee in Poland has to do once in a while. However my health check this time got very thorough after I informed a neurologist that I spend up to 4 h a day in a telecommunication laboratory.  The doctor sent me for a series of tests including an MRI and measuring my brain waves. It turned out that I can actually receive some radio frequencies with my brain. I thought it was cool - I have some superpowers and my brain can be used as an antenna. I went to the doctor with the test results. She looked at it and told me I can not work in a telecommunications laboratory. Imagine how I felt after studying Telecommunications for 5 years. I could not even go to the lab to configure devices, connect cables or set some measuring apparatus. I was a hard working person who kept complaining every week to my boss - Pawel about the quality of software requirements. When Pawel saw me with this medical condition he told me that I could either write requirements or write source code. You know what I decided 🙂

The point of these two stories is to explain this: while people are concerned about technology and processes there is also a third side of software development. It is about user needs and communicating those needs to developers. Requirements are very important, I know I can make much more impact by working as a Business Analyst or Requirements Engineer than what I could do as software developer or even Project Manager. I also know that most companies have problems with maintaining documentation and that I can help them with it.

That is why this website is all about educating people in techniques and methods of Requirements Engineering. You will find here multiple examples of software requirements. There is no other place on the internet where you could learn more about such amazing techniques like Warnier diagrams or Task Descriptions. I have been into requirements engineering since 2008. My mission is to create the world's first Requirements House which will help to solve problems with requirements quality. I want to keep working on the best tools and methods for helping software developers and their customers to be satisfied with their work. I still remember how Sergiusz felt that day in 2005.

 

About me

I have been a requirements engineer for 15 years.
I'm here to help you communicate software requirements.

 

Social Media

Strona www stworzona w kreatorze WebWave.