Let say you wanted to build a house, but not just any house your dream house because you’ve been picturing this house for a while now. So the first thing you do is start buying all the materials you think you might need for the house like gravel, cement, sand, pipes, steel, and marbles for the driveway, and that imported Norwegian wood for the roof. You then call up a few construction guys you know to start building your house and in no time BAM you got your brand new home to live in. Now, before we go any further, do you think your house would come out exactly the way you pictured it without planning things and writing the details of each room to ensure you get it just right? I don’t think so, I think you probably won’t even feel safe sleeping inside your house; fearing that the roof might just fall off. But similar to how you don’t think you can build a house before you actually plan and design it. A lot of us believe software is much easier where you don’t have to plan and design things out before you start coding. A lot of us believe that a few pieces of ideas jotted down on a piece of paper is good enough to start coding but that is far from the truth. The truth is building software systems can be just as complex as building houses.
It takes a lot of planning and design that allows us to get all the details out before we take on the most expensive part of the process, the implementation. How do you capture the details though? Well, first things first, understand software requirements. You need to understand what requirements you need to capture and how to capture them. You need to appreciate gathering and writing good software requirements. Writing good requirements often save yourself tons of weeks in possible rework in the future.
Requirements Gathering and Why does it Matter? 😆😆
When it comes to building software systems, there are certain methodologies that drive how various activities are performed, and when they are performed. In the software world, the construction of software follows different phases. These phases are formally known as the system development life cycle. Where we must be able to, plan, analyze, design, develop, and overall maintaining these systems. The issues come in when people try to skip the first 3 phases and jump straight into the development. Without getting into too many details of these phases lets say that we really need to start at understanding what we are trying to build in the first place.
The first thing that is required is really gathering all the requirements that are needed to build your system. Requirements gathering is all about researching and documenting project requirements in a precise list of what the new system must do to provide the needed value. In many ways, determining requirements is the single most critical aspect of the entire SDLC although many factors contribute to the failure of systems development projects, failing to determine the correct requirements is a primary cause.
What are Requirements? 💁🏽
Just so we are on the same page let’s have shared vocabulary about what a requirement is and other types of requirements. A requirement is simply a statement of what the system must do or what characteristics it needs to have. But what can be confusing is that they are different types of requirements and each of them is uniquely important to capture. Requirements will be created that describes what the business needs (business requirements); what the users need to do (user requirements); what the software should do ( functional requirements); characteristics the system should have (nonfunctional requirements), and how the system should be built (system requirements).
How to Capture Requirements?
Knowing how to capture requirements is very important. You want to be able to notice the details and extract information from clients that are not necessarily obvious. You will most likely need to use a variety of techniques to elicit requirements. You don’t want to find out that you missed a major piece of the puzzle later down as this becomes more difficult to solve the further you are down in the project.
Interviews
Interviews are the most commonly used elicitation technique used to capture requirements. It’s quick and easy to get going but if you don’t know how to ask the right questions you might miss some important points. Generally, interviews are conducted with the project sponsors and business analysts to get the details but it can also involve other stakeholders. There are five basic steps to the interview process: selecting interviewees, designing interview questions, preparing for the interview, conducting the interview, and postinterview follow-up.
Joint Application Development (JAD)
Joint application development is an information-gathering technique that allows the project team, users, and management to work together to identify requirements for the system. JAD is a structured process in which 10 to 20 users meet under the direction of a facilitator skilled in JAD techniques. A facilitator is a person who sets the meeting agenda and guides the discussion but does not join in the discussion as a participant.
Questionnaires
A questionnaire is a set of written questions for obtaining information from individuals. Questionnaires often are used when there is a large number of people from whom information and opinions are needed.
Document Analysis
Most of the time software is created to replace a workflow that existed before. These existing workflows tend to produce documents that can used by project teams to understand the as-is system.
Observation
Observation, the act of watching processes being performed, is a powerful tool to gain insight into the existing system. Observation enables you to see the reality of a situation, rather than listening to others describe it in interviews.
Final Thoughts
No matter how small or simple you might think your idea sound, the truth is, it is easier said than done. Meaning, you might underestimate how something will actually work in a software because on the surface it seems like a fairly simple thing to do but in actuality, it is often a complex process that takes some research and tinkering. Not planning and designing systems no matter the size will always result in missed requirements that were crucial to the overall quality of the system. Save yourself the time and do the first things first.
