Okay, let's take a look at software development just to make sure that we're on the same page here. software development teams develop all types of software for all types of industries. So the software can be vastly different between companies. But all companies have the same goal in mind, right? Develop quality software on time on budget, and that meets the customer's real needs. That is the definition of a successful project is an excellent if an application is developed that is completely on budget on time and has very few defects, it may be an excellent system.
But if it doesn't meet the needs of the customer, then they're not going to use it. And if they're forced to use it, they'll probably still use other software or some manual processes to compensate for what's lacking in the new application. company money has been spent and usually it's A very large chunk of change, to design, develop and deploy an application that isn't doing what they expected it to do. This is going to lead to unhappy users, managers, executive staff, and sometimes even unhappy investors. Requirements errors are usually the most expensive to fix, because they've happened at the very beginning of the project. And now everything else being done is going to be done incorrectly.
So that's why the requirements elicitation and analysis is so important on a project, it's imperative to have business analysis being an important part of the project. Once the scope of a project has been defined. The next step is for the business analysts to gather, elicit and analyze complete requirements. This is the most important task for you as a BA. The business requirement defines what the business problem is and what specifically the business needs to accomplish. There can also be system requirements, system requirements are needed.
In order to meet business requirements, now the reason I said can and I didn't say there are also business requirements is because you aren't necessarily always going to work on a project that has a technology solution. Because we're living in this technology age that we're in. And most problems these days are being solved with a technology solution. We tend to always jump there in our minds, right? That it's always a software system application website, something along those lines, that's the solution. But occasionally, there might even be a manual process that's being defined, right.
And in that case, there are no system requirements if it's a manual process. So don't always assume that everything that you do as a business analyst is always going to be related to a technology solution because there may be times when it is not. system requirements, if you need them will usually come from the technical partners on the project, not the business partners. So the business analyst is responsible for determining where to find the requirements. In some cases, the project may be more technical. And if that's the case, then you're going to be eliciting requirements from developers architect DBAs.
That type of thing. If you're working on, say, for example, a project that's related to upgrading servers, right, then that's more of a technical type of project and you might not even have a business area that you're talking to about it, which really means that that technical team becomes your business area.