Before a single line of code is written in a greenfield project, someone must take a seat and figure out what problem the upcoming software will solve. This is the next step after the initial contact from the customer. Mind for the word customer, because it doesn’t only mean some person with money, visiting a software house. This is a perfectly fine case for a software engineering contract, but not the only possible.
The One Who Decides
Generally speaking, there is always this one individual, or a group, the entity who has the last word. You can work directly with this person, or with someone acting in his or her name, it all depends. Let’s refer to this human as a Project Owner from the group of Stakeholders. The stakeholder is anyone involved in a project, who will also be affected by its result and operations, usually folks from funder to managers. It also may be the other department in the context of bigger companies, they also have their budget and structures. Internal or not, it still makes them your customers.
The First Meeting
The date for the initial meeting was set, now it is to decide, who will participate in the meeting from your organization’s side. Good practice here is to involve both business and technical folks, because there might be a chance for additional sale or instant validation of the customer’s ideas.
Personnel From Your Side
When it comes to first meeting with a client, you and your team have to make the best impression possible. Try to pickup the most experienced people, use their experience and confidence to convince your client that you are the company to develop his or her project. Your representation should include two folks minimum: a non-technical person, who will be able to propose full set of features, even those the client is unaware yet, and some technical person. Employee with a technical background, like software architect or developer, will be there to tell how feasible is what the customers want or what the salesperson is trying to offer. Selling an incomplete product may be as bad as selling some impossible to provide functionalities, so they will keep an eye on each other and hold each other’s horses.
Preparing
If you think you can go to the meeting without even knowing who your client is…, well I encourage you to think once again. Asking your customer a basic questions about nature if his business and its domain, is a clear sign you don’t care much. Not doing a proper research only shows your ignorance and lack of engagement. Oh my, and the project hasn’t even started yet. Steps below shows how you should research your potential customer:
- search the web for your client’s company, visit their website
- try to find the person you are going to meet, you may add him or her on the LinkedIn
- learn as much as possible about client’s company and domain, find some competitors
- after you do all above steps, you must have some questions, so right them down
- don’t be surprised if client will ask you about the similar projects in your portfolio, have a list handy
After gathering all necessary information customer-wise, don’t forget to come up with a folder presenting your company. A quick overview of services you offer, qualifications, all possible contact details and initial estimations are the required minimum. Be creative when it comes to the first impression, you can only make it once.
On The Meeting
I assume, I don’t have to even mention, that under any circumstances you cannot be late. When the day comes, have a good night sleep to be fresh and rested. Be early in the office, check your presentation hardware, prepare your computer and required media. Find a moment to relax and clear your mind, it will help you overcome a stage fright.
When the client arrives, remember about the proper welcome. Ask if he or she wants anything to drink. Have some water or juice already prepared, so you don’t have to keep them waiting. Before you will cut to the chase, it is nice to start with some small talk. There are some safe topics to discuss like vacation plans, sport events, tv shows, or the safest of them all — the weather. Politics, religion and conspiracy theories are strictly forbidden, unless you want to end up arguing and without a contract. You have already done a decent research, so topics for a chat will be rather obvious.
The person who comes to visit you, probably have some rough idea about what needs to be done, but don’t expect to be told what has to be done and how. Your customer approached you, because he doesn’t have resources, knowledge or both, to develop required software system by his own. Actually, you are expected to ask a proper set of questions, not the client telling you stuff. Read a Michelle’s story about one question she didn’t ask during initial meeting.
Michelle says:
My worst project ever? Oh gosh, I remember it well. It was during my work at the Shipyard, I was called for the meeting out of the blue, I had only fifteen minutes to prepare, but I thought: hey, the guy just wants ship, let’s give him one. There he was, wearing black and having funny white hat on his head. We started with some small talk and right after a cup of tea, the time was right to start picturing his dream ship. A lot of questions were asked, what will be the color, how many engines she needs, what audio system must be installed on a captain’s bridge. Restrooms, cabins, kitchen, even her displacement. After the meeting, me and my team did a summary, wrote requirements and started engineering process. When the ship was finished, the sad man in his white cap came to see the result of our two year effort. We took him to the dock and presented his new boat. He was more than surprised, when he saw the product, he started asking about cannons, rocket launchers and machine guns. I couldn’t get it first, but then I asked him about missing features. He answered: “In the Navy, such a work of art is not useful, because it can’t even protect itself. Missing features must be implemented on the house, because we have answered all your questions during planning phase”. I was shocked. On the house? I’m sooo fired. “But you never told you are with the Navy” was the best I could say at that moment. “You didn’t ask. I was even wearing my uniform, the same I am wearing now. It seemed obvious, who Am I representing, wasn’t it?” he replied.
Who was right, captain or the contractor? It depends on point of view. One can say, that captain’s claims are right. If your company believes, that customer always comes first, you may expect a lot of extra hours spent on weaponry design. Different option is to blame everything on a customer, trying to convince him to take the blame. If it ends this way, it is likely to be your last cooperation. The wisest choice here is trying to negotiate and encourage the investor to accept half of the costs. Maybe you won’t keep this account, but if you play it right, who knows what future will bring. Don’t let the bridges burn. And ask many, many questions.
After The Meeting Comes Feasibility Study
After the meeting was over, you told the customer that now you need a few days, to prepare a Feasibility Study. This report will answer two questions:
- is it possible, to develop such system in some finite time span?
- is it doable within a given budget then? Will it be enough, to cover all your costs and let you earn money?
If both answers are positive, then this project is feasible. Will your company be the one who will develop it? It looks like this, so now the time has come to start preparing the final version of the study. You should remember to add a necessary comments, put important remarks, and some general notes for the higher management.
Time For The Second Catch-Up
It is unusual for the software project to be created only for one user. If someone decides to spent a big pile of money for the computer system, then it must be dictated by needs of his whole organisation. This company probably supports many complex Domains, which are managed by many employees from different departments. To make things even more complicated, the knowledge you need to collect is distributed amongst people who don’t cooperate on their everyday basis. Looks like a hard nut to crack, and in fact this is one.
Gathering System Requirements
This is the moment, when system analysts come to action. Their job is to talk with the Stakeholders, Domain Experts and users about what they actually need to solve their problems. Hwo they can do it? Unfortunately, there is no one, unified method of collecting required features of a future system. Instead, there are several techniques available, each having different characteristics, together with pros and cons. Let’s go through them briefly.
Analyze Existing Interfaces And Documentation
In many cases, it is obvious and first-to-go solution when you start a particular system’s exploration. We all know this saying: “Documentation is like YETI, someone saw it once”, and you can probably admit it. Believe it or not, there are projects out there with nearly perfect manual and nicely presented API endpoints. If it happens to be your new assignment, consider yourself lucky. Even if it doesn’t shine, it is always better than nothing. Mind that bugtrackers are also a great source of knowledge, they are a historical record of architectural drivers and decisions, which led to solutions, sometimes widespread through the system. It may give you a significant amount of answers concerning strange source code fragments.
Together with the documentation, you should start exploring the system acting as an end-user. Ask an administrator for some test account on their staging environment, and brake something. Do some monkey test first and observe how the system behaves. Then try to go through some processes from the beginning to the end. If you work on e-commerce application, you should definitely try to buy something. In this scenario, you must start with registering a new account, go through checkout and commit some payment. Then, you might proceed to some admin panel and other services made to manage domains. Together with the documentation, exploring company’s domain might be a piece of cake.
Let Them Speak By Interviews Or Questionnaires
Interview or Questionnaire are great ways to start. Usage of these techniques will uncover first layers of business needs and problems users facing. It is important to note, that you should reach all the Stakeholders. Thanks to this, you will be able to extract a common denominator of everyone’s needs. Good Interview and Questionnaire are build with open-ended questions, meaning none of them let interviewed person give simple “yes” or “no” answers. Your interviewees must provide you with the context, explanations and reasons behind what they say. Your role during the Interview, is to add as many follow-up questions as possible, because Stakeholders may hold some facts or details important from your perspective, without even knowing.
Interviews shine, when amount of Stakeholders is insignificant, because it requires you to speak with them separately. Sure, it takes some time, but for you, the analyst, it is a comfortable situation. You can ask as many questions as you need, Stakeholders are more likely to be focused and cooperative, knowledge is transferred and new facts get uncovered.
Questionnaires, on the other hand, are helpful when the time is not on your side, or amount of interviewees is so big, it would take weeks to meet all of them. If well-designed, it is not less helpful than the Interview. It can be prepared before meeting client’s team, so it doesn’t require you to explore a customer’s domain in real time.
User Stories
User story is a decent tool when it comes to write some piece of functionality. Thanks to its easy and repeatable form, it is used a checklist with detailed information. Let’s see how user stories for the e-commerce cart requirements may look like:
- As a User, I can add product to my Cart
- As a User, I can remove product or products from my Cart
- As an Admin User, I can clear every User’s Cart
The list above contains only rough description of what must be done, every User Story comes with a detailed description. It is a good practice, to segregate them in proper submodules.
Role-Playing
If you have a rich imagination, you can be creative and incorporate stakeholders to have some fun during the role-playing session. Let them be customers who comes to the company, or assign them roles like in microservices, observing how they will cooperate, how the information will be passed from one to another. It may tell you a lot about both, people and their needs. Don’t be afraid to do something funny or little crazy, if it helps you to get everyone on the same page, then it is not stupid, right? After such play, you can expect positive and accepting feedback, so this is worth to try.
Engage Everyone By Conducting A Workshop Or Brainstorming Session
And what actually the brainstorming is? Imagine you are in the classroom, and the only copy of the door key was accidentally threw out the window. Now this is you, your classmates and your teacher, locked together. You need to figure out how to get loose. If you let everyone speak his ideas, write the best ones down on the chalkboard, and then try to follow them, then this is a brainstorm. For the best results, let it be up to the group to decide, which ideas are worth the effort and which are not.
Similar to brainstorm, but having broader meaning are workshops. Workshop may have a double meaning. First, it is a form of exploring the system and the domain, like Event Storming. In its second meaning, you may consider it as a peace talks between stakeholders. If the project, and the company are big enough, you may expect requirements to have many conflicts and self excluding ideas for how stuff should work. If it happens to take place in your project, be prepared to solve those issues first, before code implementation even starts.
Observe Them In Their Natural Habitat
This method is interesting, because it involves less speaking, but more observing of users during their everyday activities. It doesn’t exclude asking questions of course, they will be just shorter, just like answers. You don’t have to rely on what stakeholders tell you, it is more likely for them to skip some important details. Processes are observable, you can analyze them in real-time and quickly fill gaps in your knowledge.
Software Requirement Specification As An Outcome Of Requirements Gathering
No matter what techniques expressed above you have used, finally you need to merge them in one, consistent document. It may come in many forms: pdf, html even MS Word, it is up to the client. From you side, you should use software, which lets you export your work to multiple formats. The document I’m talking about, has its name, which is Software Requirement Specification (SRS). This document should contain detailed information about:
- Environment for the system, meaning hardware and operating system
- Required network throughput and conditions
- Operating system and programming languages
- Requirements expressed in natural language
- User interfaces as images
- Detailed logic description using pseudocode, together with conditions and math expressions
Don’t forget to be meticulous when creating this document. If you miss something at this point, you will have to add missing features within the accepted budget, what may be hard to achieve. By the way, this is one of the main reasons why IT projects are late and underestimated.
SRS Must Be Validated
This is the last task for the Stakeholders, they have to validate the SRS document you have provided. If this process is passed, the implementation may start. If not, the SRS document must be updated and once again passed for the validation process. These two steps will repeat, until all issues and doubts will be resolved. What complications may show up? It may turn out that requirements cannot be implemented, it may be due to some illegal activities or security breaches. Another aspect is a completeness of the solution, there may be some features missing. When Stakeholders can see the big picture, they may also decide that the system will be impractical and will not solve any problem at all.
A Word On Functional And Non-Functional Requirements
Generally speaking, there are two main categories of Software Requirements, functional and non-functional. Functional requirements tells us about how a particular software should function. These are unique for every project, even if compared systems have similar features. The examples are:
- User may search products in the e-commerce store, using price filters
- Cart must always indicate which promotions were used when calculating total price
- Customers have an option to pay with Credit Card or PayPal
- Frameworks used must be always up-to-date
And then we have a non-functional requirements, they don’t concern any specific functionality or feature implemented by the software. They are not important from the end user’s perspective, because they are mainly connected with the system’s environment and its availability, so users expect it to just work. Good examples of this kind of requirements are:
- System must be configurable, changes can be made without re-deployment
- Software must be secured, all breaches must be logged
- Architecture must be flexible, so future extensions are easy to develop and maintain
- Performance doesn’t degrade with time, system is scalable
Summary
As you can see, gathering System Requirements is not an easy task, but with proper tools you can provide a valuable input for your development team. Remember to ask many questions, so you don’t miss any important features. Don’t be like Michelle, if you work hard during this phase, it will pay you back during the development. And if project is delivered on time, then everyone is happy, meaning your client nad your boss. Stay tuned.