Menu
It is decided, you have an idea that will bring your business to the sky. It only requires the development of a piece of software to offer your very innovative Widget Management Services to the market. You know that it is possible to do it, you have had several conversations with very competent people on the subject and what you want is achievable with a tailored software. So, what is the next step? The next step is two fold:
We have seen in the two previous articles of the series 1 – how big the paradigm shift is between the real world and the digital world; 2 – how a Software Architect is bridging this gap. But to bridge this gap, the IT specialist must start from somewhere. If a conversation is nice to have, it is unfortunately not enough to know what to do. What is required is a description of a combination of solid business needs and technical constraints. You have to state enough precise information for the IT team to be able to work. So, just as you don’t buy “a car”, you don’t purchase “a Widget Management Software”. For a car you need to decide if it is a city car, a highway car, a rally car, a Formula 1 car, etc. And then you need to keep going: how many passengers, level of comfort, etc. It is the same for your IT project. What do you actually want?
Your project did not start from nowhere. It started from the realisation of an existing gap between “what is” and “what should be”. This is true for a green field project starting from scratch but also for a version 3 of an existing system. When you and your team realised the existence of this gap, you had a “Vision” of a better world. This Vision is a great step in the project. How do you go for this step? You can ask yourself a few questions. Basically, it consists in comparing the existing situation with the target one. Please note that the following lists are non-exhaustive but are aiming at illustrating the point. If you want a more thorough insight, please contact me.
Existing Situation:
Target Situation:
Once you have captured all this information, you can now pass your Vision to other people for feedback. The objective is to get a fairly stable description of the project that people can read and understand easily. This is more of a business document than a technical one.
If your Vision is making people excited, it is then time to get to the next stage: the Requirements.
The challenge is the following: unless you are an experienced IT specialist, you will want to explain your needs with concepts and criteria that are not necessarily helpful for the technical job to do. For instance, explaining that you want the “information to be found fast” is not describing half enough your need to be able to give an opinion about what it takes to do the job. If you state that your widgets must be “managed in real time”, once again it is far from enough to be able to know what it takes to do it. “Real Time” will be defined differently by different people in the industry.
But don’t worry; these are only “challenges”. The good news is: there are plenty of methods that make the job possible.
Capturing the Requirements is about writing down in word what people have in their mind. It can be processes (how things are done), actors (kind of people using the system), objects (things manipulated by the system) or even technical constraints (how fast, how reliable, geographical or technical constraints). This job is done by someone who will be called “Business Analyst”.
The Business Analyst will often interview a lot of people named “The Stakeholders”, i.e. the people who have a say in what needs to be done. They may also go through plenty of documents that could describe how things are done at the moment. This is the gathering of the information.
Once the raw information gathered, the Business Analyst will put it is a format that must be understood by various people; and this is where things become tricky. The documents produced, named Requirements, must be understood by the Stakeholders (i.e. the people who gave the information in the first place) but also be useful to the technical team, as they need to convert these requirements into a technical solution. The gap between the two worlds can be quite wide. In order to fill the gap, some Requirements formats have been invented. Some well-known modern ones are: Use Cases and User Stories. In some cases, the project can be defined by the test that will be done to check it is working fine. This type of approach is called Test Driven Development. This article will not enter into the details of the differences between the possible formats. The point is: there are various ways to capture this information. The trend is to go Agile, i.e. as light and fast as possible.
In the end, the requirements are passed to the technical team. Their job is to convert that into a software system. The Requirements main document is not the only source of information on a project. The Business Analyst may also produce diagrams to elicit the requirements. The diagrams are likely to be produced using the UML format. Actually using UML as a complement to the natural language documents is a great way to enhance the quality of the requirements. UML is a fantastic tool when it comes to removing ambiguities. This might be the topic for another article.
The time needed to go through the whole process of capturing the project’s requirements can vary a lot from project to project. The trend nowadays is to have less formal requirements documents but more interaction between the Technical team and the Stakeholders. It is the subject of heated debates in the Industry. I will not enter into this debate here. What you should remember is rather simple: one cannot create what has not been properly thought. Without a Vision and some level of detailed plan, you are likely to go nowhere. Capturing the requirements is a mandatory step in your project.
If you want more in-depth info about producing the Requirements of your project, please get in touch with me.
The Vison and Software Requirements Gathering phase of a project is absolutely key. Whatever the format you have chosen for capturing these requirements, the most important aspect of this phase is the thinking process: What do I really want? Usually, having someone dedicated to this job is giving the best results. And unlike what one could think, the main Stakeholder of the project is rarely the best person for this job. The reason is: the better you know what you want, the more assumptions you will make. These assumptions will ultimately be converted into mistakes that can be very costly. The best Business Analyst should be someone making very few assumptions. A good Business Analyst is also someone with technical knowledge and who can discuss constructively with the technical team.
Ultimately, if you have only one thing to remember about Requirements Gathering is this: it is the key step that is bridging the business needs into the technical world. Without a solid bridge, you will fall and drown into the river.
Liemur provides Software Development Services within UK and with its nearshore branch in Budapest.
Contact us about your project.
This article is #3 of a series on Software Development for Non-Technical Decision makers. This series contains or will contain: