Introduction
Software requirements gathering is an important part of the software development process. It's critical to understand what your customer expects from your product and how they want it to work, this will help you build the right product, the first time. Overall, leading to happy stakeholders, and reduced costs.
Software requirements gathering is the process of discovering, analyzing, and documenting the software needed to create a solution to a problem or opportunity.
Software requirements gathering is a systematic process that helps you gather information about the software needed to build a solution. Software requirements gathering is an ongoing activity, and it starts with defining the problem or opportunity. The definition of the problem or opportunity drives deciding what capabilities are required in order to solve it. These capabilities are called “features” in Agile terminology and “requirements” in traditional terminology.
Software requirements help build the right product with less cost, as well as making sure software development resources align with business goals by providing clarity on what needs to be built and why it's important for your business (business value).
Types and characteristics of software requirements
The following factors should be taken into consideration when identifying requirements:
- Consistency and non-conflict with other requirements or existing functionalities (unless intentional)
- Feasibility of the requirement
- Explicitness—the requirement must be clear, precise, and unambiguous. The way it is stated should not leave room for interpretation by the developers or users of the system.
- Testability—the requirement has to be testable so that its verification can be done objectively and independently from other systems. This requires a thorough understanding of the business domain as well as an in-depth knowledge of what makes software work successfully in real-life scenarios
The most common types of requirements are
- User requirements: These are requirements related to the user experience, such as performance, usability, and accessibility.
- Business requirements: Business requirements are those that have to do with the business of the system (e.g., cost, schedule, and quality). They include both functional and non-functional characteristics that must be met before a product can be accepted by its customers
Functional requirements describe the business features of the system. They are usually created during business modeling exercises, and they describe the use cases and behaviors of the system.
During analysis, functional requirements are usually analyzed first. This is because most systems can be analyzed without considering other types of requirements (such as performance or quality). In addition, functional requirements are usually validated first because they tend to be more concrete than other types of requirements.
One of the most challenging aspects of gathering requirements is asking the right questions. The following section will discuss some techniques for asking good questions and how to avoid asking leading questions.
It's a good idea to think about your requirements before you start gathering them. You may not know all the requirements for your system at this point, but it's still important to have some understanding of the kinds of questions you'll need to ask and the types of answers you may get.
Requirements related to usability, maintainability, and accessibility are called nonfunctional requirements
Nonfunctional requirements are not concerned with what the system does, but rather how it should be implemented. These can range from simple things like performance and usability to more complicated problems such as security or portability.
- Performance: The system must respond within a set time period in order to provide adequate service to the customer
- Usability: Users should be able to navigate through the system without difficulty
- Portability: The application can run on several different operating systems without requiring modification or customization
Functional requirements vs Nonfunctional requirements
It's important to understand the difference between functional and non-functional requirements.
Functional requirements define what a system does. For example, a banking application might be expected to allow users to deposit money, withdraw money and get interest on their savings account. These are all functional requirements for this application.
Nonfunctional requirements define how the system does it. For example, we know that the bank will need an online secure connection so they can transmit information securely over the Internet. This is one of several nonfunctional requirements for this application (along with others such as availability).
The life cycle of a software requirement
You must understand that requirements do not exist in isolation from the rest of your development process. Requirements change as you develop your software and interact with users.
The first step of this life cycle is gathering requirements using whatever method works best for your project: interviews, collective sketches, brainstorming meetings where both customers and internal team members participate, etc. The output will be an unstructured list of use cases and desired system features—in other words, what you want out of this new product.
The second step is vetting these requirements; that is to say, high-level analysis (such as categorization), removing contradictions between them, and taking into account factors like costs vs benefits or technical feasibility vs business value when deciding which ones should make it onto our official list.
Thirdly comes deep analysis: looking at each feature individually with its impact on other aspects (such as cost or performance) taken into account so we can measure their completeness/priority correctly now that we have all our initial ideas sorted out! This will help us decide which ones need more work during development phases later down the road too (if any). It also lets us figure out where there may be gaps in our understanding before proceeding further along with making sure everything checks out okay internally first before moving forward further still towards release day...
The fourth step is specifying requirements. This is when you have to collect and formally document the requirements in order to create your official list of what needs to be done.
Discovering and collecting requirements
There are many techniques to collect requirements. The most common is to create a set of questions and ask them during a meeting with your stakeholders. You'll want to focus on the following:
Understand the problem or opportunity. What's missing, broken, or bad about the current system? What do you need this new system for?
Understand the stakeholders. Who will be using this system, interacting with it, or otherwise impacted by its existence in their lives? How do they currently use their time and resources (e.g., paper vs online forms)?
Understand limitations of project scope: Is there a limited budget at stake here? Only one or two people working on it—you're going to want at least four if not more so that you don't burn out before finishing! Are there technical limitations preventing certain solutions from being implemented due to compatibility issues with older databases etc., which could slow down development time considerably if not addressed upfront during the initial design stages; so be sure not only to consider but also address these concerns before starting any coding work! If possible try looking up other similar software solutions already available—what features did those have? Did they work well enough for customers' needs/expectations so why would ours be any different?"
State assumptions as you have discussions with stakeholders. This is important because it prevents you from building features that are not needed or may even be harmful. For example, if the customer wants an account feature but we don't know who will use said account then this could create a security risk; so instead let's say customers can access their accounts via browser login where they'll log in using their email address/password rather than creating another profile for each user.
Learn about the problem. This is important because it allows you to understand the customer's needs and scope out potential risks early on before committing resources such as time or money towards solving them; so be sure to gather information before starting any coding work! You can also use this opportunity to clarify any questions they might have about our solution which will make them feel like we're listening as well.
Remember, the goal of software requirements gathering is not just to gather information but also to acquire an understanding of what the customer wants and how we can best provide it. This will help us avoid mistakes in our codebase while ensuring that they'll get exactly what they were hoping for from their product.
Analyzing requirements by exploring the implications of the requirements and completing our vision of what the finished product should look like
We've gathered our requirements, but we still need to analyze them. The first step in this process is exploring the implications of the requirements on the quality characteristics of your product. The second step is completing our vision of what the finished product should look like.
Are there any missing requirements? Are there any conflicting requirements? Are there any overly specific or overly broad requirements? At this point, you can consider whether these issues will affect your ability to meet the users' needs as well as their satisfaction with your product. You may also want to consider whether they'll affect other aspects of project success—such as cost and schedule—that aren't directly related to addressing user needs (the nonfunctional characteristics).
Finally, by now you should have gained a clearer understanding of what it would take for us all to be able to say "mission accomplished!"
Validating requirements with stakeholders
Stakeholders are the people whose needs will be met by your software. They are often the ones who initially commission it and then use it throughout its life cycle, so they are an incredibly important part of the requirements validation process.
Stakeholders should be involved in the requirements gathering process so that they can give you context on what problems your solution should solve for them. Once these problems have been identified, stakeholders can also provide feedback on whether or not they feel like they've been solved with your new system.
You should also consider inviting other members of your team to participate in this validation step as well—if possible, invite them all! This helps ensure that everyone has a say in how well their ideas align with those of their coworkers.
As a developer, you always want to be clear on what you're supposed to deliver so you don't have unmet expectations
One of the first steps in any project is defining what you are supposed to deliver.
You want to make sure that everyone involved in the project understands:
- What it is that you're supposed to deliver, and why.
- What it is that you're not supposed to deliver and why. (This is important because sometimes people will ask you for things that are not part of your responsibility.)
- The scope of what they want to be built (i.e., how big or small they want it). This includes what features they require and how many users will be using this new application/service/system etc...
- You want to make sure that you are clear on the test plan and release strategies. These are important steps that need to be taken before starting any project because they will help you budget your time and resources accordingly.
- Last but not least, defining how many users will be using this new application is important because it helps define what type of servers (or cloud services) you might need to host those users.
Conclusion
Clearly, requirements are important. They define the scope of what your project should do and how it should do it. Without clear requirements, you could end up delivering something that isn't needed or wanted by your client or boss. It's also important to remember that these requirements will change over time as new information becomes available about the problem being solved or the opportunity being pursued. In order for you to keep track of all these changes over time (and ensure everyone else does too), use any tool that works for your team. Whether it's a formal requirements specification tool, project management tools like Jira, Trello, etc. or even just a google doc/spreadsheet.
Build the right product the first time by going through the requirements phase of the software development lifecycle.
Follow me on twitter to stay up to date on my content. Feel free to DM!
