This post aims to act as your complete and comprehensive guide to requirements gathering for software development. Starting by defining requirements gathering and outlining the main issues surrounding it, followed by explaining why requirements gathering is so important and what challenges project risks it incurs. Lastly, we will outline why it is important to adopt software for the requirements gathering process.
What is requirements gathering?
Finding out what your projects must accomplish and what must be produced to make it happen is the process of identifying project goals, requirements and gathering.
The method of gathering requirements generally involves creating a list of the capabilities your product must have. It is expected these criteria will come from different backgrounds.
This means you will encounter both design requirements and business requirements in a single product because every product out there needs to consider more than simply the design of things. In essence, you are asking, “What does my product need?”
This can seem like a straightforward question, but you might be surprised to realise how challenging it can be to accurately identify needs. This is largely due to the variety of participants and perspectives, including designers, engineers, developers, and business analysts.
What are the two main types of project requirements?
Business requirements: What the project should accomplish. A comprehensive set of features that specify what the system should be able to perform is called a functional requirement.
Technical requirements: How your project will meet organisational needs. On the other side, non-functional requirements are limitations or characteristics of a system such as performance, security, or usability.
Functional requirements should not be confused with other types of requirements in product management:
- Business requirements are fundamental needs for the company, such as boosting market share or extending customer lifetime value.
- User stories, use cases, and scenarios are typically used to develop user requirements, which outline the many goals your users can achieve with the product.
- Product specifications describe how the system must operate to meet the needs of the user and the company. Both functional and non-functional needs are included in them.
Functional specifications must be precise, condensed, and explicit. Here are a few instances of sensible functional specifications:
- A confirmation email must be sent by the system each time an order is placed.
- The blog system’s users must be able to sign up for the newsletter by entering their email address.
- Users must be able to verify their accounts on the system using their phone numbers.
Documenting and co-operating on functional requirements has various benefits, including the following:
- By ensuring that stakeholders, developers, designers, and testers are on the same page and are focused on the same goals, clearly specified requirements eliminate misunderstandings.
- The key to a technical project’s success is effective communication since it facilitates goal-setting and meeting by having clearly stated functional requirements.
- As the team learns more about the user’s needs, estimation becomes more precise.
- Any assumptions, clarifications, etc. can be addressed early when Functional Requirements are thoroughly examined during the discovery phase, which has been proved to save time and money.
When gathering requirements, it’s critical to make the distinction between functional and non-functional needs.
Simply said, non-functional requirements place restrictions on how the product should be able to do something, while functional requirements identify what it should be able to do.
Functional requirements, as the name implies, are about specific product functioning. It is typically not difficult to define, measure, and test them. Contrarily, non-functional criteria are more abstract and are often known as “quality requirements” or “quality attributes.” They impose limitations on the performance, security, dependability, scalability, and portability of the implementation of the functional requirements.
Functional requirements are frequently used to establish the attributes of a system or product’s quality, and are frequently used to measure the system or product’s overall performance and effectiveness rather than particular behaviours or functions. Response time, throughput, availability, and security are a few examples of non-functional needs.
Across the custom software development industry it has become apparent that at the start of a project, the requirements gathering phase is often neglected and therefore, many details of crucial project elements are missed. Too often assumptions are made, resulting in the requirements gathered being unstructured and lacking in detail. This is an issue we began to amend internally and upon research realised it was an industry wide issue. Research by Forbes indicates, 9/10 major digital projects experience overruns. Moreover, 80% of rework can be traced to requirements defects (Technova).
According to McKinsey the average project overruns by 33%, from this we can conclude that 1 in 4 software developers are working on unplanned work. Again, illustrating the effort wasted when requirements gather information aren’t gathered properly.
Despite these statistics, 70% of organisations still do not take effective action to adequately improve the quality of their requirements (Technova). Considering requirements gathering is the greatest pitfall in software development and costs the industry millions a year, we still do not pay enough attention to them.
Why is software requirements gathering so important?
Ultimately, without successful requirements gathering most projects will overrun which may result in the following factors in the project’s outcome and progress:
Design mistakes are a major cause of cost overruns in most projects. Every project’s design serves as its basis. The project design lays the groundwork for an accurate depiction of the client’s requirements as well as the framework for obtaining quality technical input, both of which are essential for successful project execution. An erroneous or insufficient representation of the project objectives and outcomes is referred to as a design error in context.
If the design is wrong, the project’s plans and tactics will be implemented incorrectly. These design problems begin to show themselves later, during the project’s execution phase, which results in additional work, change orders, etc. and, in the worst-case scenario, scope revisions that result in cost overruns.
Unfeasible Cost Estimate
An inflated cost estimate is another frequent reason for project cost overruns. The crucial phase that comes after the project design stage is the cost estimation. If the cost is predicted solely on a hunch without taking appropriate escalations and contingencies into account, the project team will probably experience cost overruns. This may go unnoticed at first, but it gradually becomes more noticeable.
Project complexity is a contributing element that frequently causes project cost overruns and schedule delays. Since there are more possible issues during execution the bigger the project is, large projects usually run the risk of running over budget. Variables including inflation, shifting material costs, and varying exchange rates may have an impact on a project when it is being implemented over a longer period of time; as a result, additional funds may be required to supplement the project’s initial budget.
Additionally, as the complexity of the project increases, it becomes more crucial to carry out plans accurately. If this is disregarded, it could cause a number of delays which significantly affect the project’s schedule.
Lack of resource planning
Another common reason for budget overruns and project schedule delays is ineffective resource planning. Failure to estimate the resources which will be used during the project could lead to under or over allocating resources to a task. This indicates a lengthening of time or a barrier.
Resource planning is also taken into account by the contract and project management and system. If there is insufficient, unnecessary, or ambiguous information in the contract, it may lead to protracted negotiations, conflicts, arbitration, and mitigation due to work modification orders and the pursuit of a rewritten contractual agreement with new budgets and schedules. There will undoubtedly be a project delay and cost overrun as a result.
Requirements Gathering is Undertaught
Another study conducted by Info-Tech Research Group shows that 70% of those failures are due to issues with requirements. If we take these two statistics together, we can infer that 49% of digital transformation projects will fail due to requirements. That’s almost half! Moreover, another study (Tecnova) indicates that 80% of rework can be traced to poor requirements gathering.
The NHS cancelled an £11 billion system. The goal was to link every component of the NHS in the largest single civilian system ever built. It was abandoned because they were unable to deliver. This is an illustration from the public sector of a project that was entirely unsuccessful as a result of inadequate requirements at the project’s inception.
Despite these figures, 70% of organisations continue to fail to take necessary steps to raise the calibre of their standards (Technova). We still don’t pay enough attention to requirements gathering, despite the fact that it is the biggest risk in software development and costs the sector millions of dollars every year.
The “bad relation” of the software development process seems to be the software requirements. The development community appears to teach and value it too little. The aforementioned figures appear to demonstrate that there is a problem with the calibre of requirements in software development.
The adoption—and frequently abuse—of the agile methodology also seems to imply that some people have given up on trying to articulate in-depth system requirements in advance. When employing an agile methodology, the requirements are frequently “fleshed out” as the project moves forward. Although this is undoubtedly a strategy, it makes it very challenging to plan a fixed budget for a given set of capabilities. In fact, if employing an agile strategy with a limited budget, the features typically will be reduced if the whole project budget begins to overrun.
Following our own investigation, we provide some proof that the crucial field of requirements is given less weight than other areas of software development. A lot of instruction and media attention is focused on technology and getting things done, but less attention is paid to the things we are actually constructing.
The lack of focus on requirements gathering in project management can be attributed to university-level software development courses.
Many of the developers at our organisation have stated that during their undergraduate studies, there was no emphasis placed on requirements collecting. According to the opinions of different developers from different colleges and the lengths of their degrees, teaching of requirements collection was undertaught. Some people claimed to have gained knowledge of UML, ERD Diagrams, and User Stories, among other system design techniques. These do not, however, meet all the prerequisites needed to create software for the commercial market. It was noted that OOP ideas, databases, and programming languages like Java and C# were given more attention. Although these are all important, they become useless if you can’t feed in something of use, i.e, fully defined requirements.
We examined a renowned UK university ranked in the top 10 for computer science degrees. The curriculum for their four-year Software Engineering degree makes very little mention of requirements gathering. Only two of the twenty classes, on average, which software engineering students will take specifically address requirements and requirement gathering techniques. Given that requirements collecting only makes up a fourth of those two classes, it can be inferred from that analysis that as little as 2.5% of this university’s Software Engineering degree is likely to be spent on it. Our conversations with people who have studied computer science or software engineering seem to align with this case.
Similar findings can be found at all of the Scottish Universities we looked up online as well as in other educational pathways such more for-profit software engineering conversion courses, whose curriculum also downplays the value of requirements collecting.
Given that requirements gathering is essential for all digital initiatives and that there is evidence connecting it to failure, it is troubling that education does not give this subject any thought. Effective requirements gathering approaches are applicable every time, unlike coding languages, which can change from project to project.
Lack of literature
When you look at the problem through a lens larger than just requirements gathering as it is taught in schools, you will notice that there is a lot less literature in this area than there is in other areas of the software development process.
This graph shows the amount of books available on Amazon for various software engineering search phrases. As you can see once more, the coverage of software requirements is far less than that of the other topics. There are 10 times more books written about one coding language alone than there are software requirements. Even though not every project utilises the same language, requirements gathering is a necessary part of any project. It would seem reasonable that there would be less writing on a topic that is disregarded at the university level and serves to further explain the problem at hand.
Moreover, similar results can be seen within Google Search Results.
This graph conveys that there is significantly less content on Google surrounding software requirements than there is for other software development related subject areas. This further suggests that there is a lack of information out there on requirements . Can this can be attributed to the lack of education in this field and misunderstanding of its importance in general?
The aforementioned details emphasise how requirements gathering would seem to be neglected on a general level. Whether that be in the writing and web material or the software development instruction. Given that it has been shown to be the most challenging aspect of software development, the fact that it is inadequately covered in educational settings may be a contributing factor in how poorly requirements collecting is carried out.
What are the challenges of requirements gathering?
The cone of uncertainty
Custom software development is a process of constant improvement. Starting with a broad idea, you can then focus it to meet the project and product’s goals. Your objective is to gather requirements and determine the cost and time needed to complete a particular project timeline level of capability. The project’s intended outcome will impact cost estimates, timelines, and feature combinations because there are many possible final configurations for the development.
Throughout the software development process, several decisions will be taken about feature-related matters. Ambiguity in software estimation results from uncertainty in the way judgements will be made. With each decision you make, the level of uncertainty declines.
As a result of this decision-making process, researchers have found that project estimates are susceptible to predictable amounts of uncertainty at certain periods. The Cone of Uncertainty below illustrates how estimations improve in precision as a project initiation phase moves along.
As more choices are made, the requirements are refined as indicated by the horizontal axis, and the estimated work is represented by the vertical axis. The cone serves as an example of how estimations made early in the whole project process are highly prone to inaccuracy. This is a result of the incomplete information that was available when software developers and clients first started working together to get to an understanding and agreement over the outcome of the development project and how they will reach that outcome.
A software development project’s initial requirements collection has been found to have an impact on how accurate estimations are. In cases where clear needs are agreed upon, estimates will be more accurate. Because of the unpredictable nature of the software project management software, itself, there is some variation in the estimate. If the estimating variability is to be reduced at all, the project’s own variability must be reduced.
Misunderstandings and inaccuracies in the requirements might arise from poor communication between stakeholders and the development team. Because of this, the development team may create features that aren’t genuinely necessary, aren’t precisely defined, or even contradict with other needs. Time and expense overruns may result from this.
Miscommunication can occur between stakeholders as well as between stakeholders and developers if numerous persons are responsible for a system’s requirements. For instance, the finance department may have requirements for the system which disagree with those set forth by the project manager or the HR department for a new system.
Incomplete or ambiguous requirements
The development team may need to spend more time and effort trying to comprehend the requirements if they are not properly specified. Delays and cost overruns may result from this. Due to the difficulty in identifying missing items, ensuring that requirements are full is a problem that is nearly impossible to solve. However, using tools like Requiment, our requirement collection software, or templates can try to lessen the likelihood that requirements will be overlooked.
Conflicting requirements may be brought about by ambiguity over the process’s conclusion or project success rate or by disparate priorities for various stakeholders. If this is the case, it is the responsibility of the business analyst to list all requirements, report project progress, identify those that clash with one another, and let stakeholders determine the priority of each requirement.
Lack of access to end user
End user unavailability can occur for a variety of reasons, and it must be carefully addressed. Because they are too preoccupied with their regular work, end users may choose not to participate in activities that will help them meet criteria.
Lack of stakeholder involvement
The project’s scope and goals may not be well understood by the project stakeholders, if they are not actively participating in the requirements gathering process. This may cause misconceptions and inflated expectations, which increase project costs.
Managers and project managers who are involved in the specification of a new system are a frequent source of trouble for us. When the system is delivered, the stakeholders discover the system is unfit for purpose since they choose not to involve the people whose job they will help automate. It is beneficial to involve as many key stakeholders as you can and to refrain from assuming that you understand how individuals will carry out their duties utilising a new system.
Focusing on visual aspects rather than functional
In many cases, stakeholders and end users have a clear idea of how the new solution should look but are unsure of what it should be able to do. The user interface of any system is an essential component, yet it shouldn’t restrict or hinder operation.
Why you should use software for requirements gathering process
Software may be useful for the requirements gathering project management process for a number of reasons. When we refer to “software,” we imply programmes that do more than just serve as word processors. Additionally, we are explicitly talking about requirements collection and NOT specifically requirements management.
The process of learning about and recording the features of a system or product that is planned is known as requirements gathering. In most cases, it entails identifying a problem and offering a remedy.
The skill and expertise of the person or team acquiring requirements generally determines the calibre of the requirements capture. Due to the variety of persons working on the assignment, one project’s requirements may be very well defined and detailed while another is vague and poorly defined.
An example of this might be someone gathering requirements for a system and recording the following requirement item.
- The user should be able to login
- The user should be able to logout
This might seem simple and straightforward and obviously more details would be provided in a ‘real’ requirements document. However, an inexperienced analyst might leave the requirements like this whereas an experienced analyst would add a third requirement:
- The user should have access to a ‘Forget Password’ feature.
While Word checklists and templates can be used to increase the coverage of requirements, software can be more flexible in the workflow of managing requirements and collection and offer functionality beyond a straightforward template.
Process and quality improvement
The requirements gathering procedure will be standardised through the use of software. Teams will produce requirements gathering specifications which are more successful and consistent if they follow a systematic method that is consistent throughout. The knowledge of an organisation may be largely restricted to its employees. An automated method of acquiring and streamline requirements gathering, helps streamline the procedure into a standardised process that less experienced staff can follow. This will help the organisation maintain a more reliable and high-quality requirements gathering process while making it more resilient to employee changes.
More accurate documentation and clarity
Even with the best templates, requirements gathering can occasionally provide ambiguous needs. For instance, the need “a user can establish a new job” might be universal for a system, but if the system includes many user kinds (such as system administrators, office staff, and field workers), the requirement might never be obvious that only specific categories of users can carry out this action. When this problem is uncovered, it may cause misunderstandings, delays, and project overruns.
Another advantage of requirements collecting software is better requirements documentation. It is conceivable and simple for a member of the organisation to edit, amend, or delete certain sections of a document using basic document templates. Software can guarantee the production of a specific project’s exact requirements in document and the completion of each section. Some software can provide estimates, a list of the tasks necessary to develop the product, requirements documentation, and more.
Stakeholders and the development team will be less likely to overlook important requirements by having a clear and accurate document defining the requirements of a project. It has been demonstrated that improving the requirements will lessen the likelihood of inaccurate estimating, project overruns, and possibly project failure.
Multiple stakeholders can participate in the requirements gathering process in real-time thanks to requirements gathering software, which helps enhance coordination project planning and collaboration. Some apps for requirements collecting may even enable non-technical stakeholders to finish the initial draught of requirements by posing the appropriate questions in the manner of a “robot business analyst.”
When requirements are gathered using software, it is simpler to track and trace the process, including who contributed what and when. This can assist in guaranteeing that all needs are correctly accounted for and documented.
Version control features are frequently found in various requirements gathering tools and software, which can be useful for managing changes to requirements over time. When working on extensive, complex tasks, this can be quite helpful.
In comparison to using manual requirements gathering techniques, adopting software for requirements collecting can speed up the requirement gathering process and save time. Instead of the user having to manually type these criteria into a Word document or support ticket, an application can generate a set of specific requirements from a simple yes/no question.
You will have a competitive advantage by adopting a requirements gathering programme because it will make sure that your projects are more successful. The typical software project overrun is 33%, with requirements problems accounting for a large portion of that. Better requirements capture can increase organisational efficiency and possibly lower project costs and schedules.