Systems Analyst
Let's figure out what the "systems analyst" does and how he will help on the project.
"Systems analyst" is often described as a "task maker," and I find that a fairly clear definition, albeit a very narrow one. I repeat that, just like with a business analyst, with a system analyst, we do not have a reference, clear definition, and the boundaries of his activities from project to project, from organization to organization, from environment to environment, can be very different. It so happens that our business analyst acts as a customer for a system analyst, who in turn tries to understand the “wants” of the business, assesses the “adequacy” of requirements and the “possibility” of their implementation (often this assessment takes place together with the development team and the architect software product), after which the systems analyst translates the business requirements into the development language and sets the development task. Thus, the "systems analyst" is a filter and transformer between business and development. The result of the work of a system analyst is the formulation of a task to create a system, software, application. Its design already depends on the methodology of software product development or project management, but most often, it is a document called "Terms of Reference". The system analyst collects all the requirements and integrates them, systematizes and describes the system setting of the problem remote network engineer jobs.
So, back to our store example. The store owner decided that it was important for him to implement ERFID technology for accounting for goods in the warehouse. And he wants nanotechnology to calculate in 5 minutes what is sold, what is left in the warehouse, and what is lost or stolen! He already has an understanding of the business goal of product implementation, he knows the company's business processes, he knows ERFID technologies and knows what a boxed warehouse management solution that his company implements is capable of. And then a system analyst comes, whose goals are to study the store environment, understand how the Warehouse system is set up, and how it will be integrated with the new software product and adjusted to the store's needs (customized). Thus, the systems analyst becomes the link between the introduction of a new product, i.e. improvement of business processes and development and customization of a new product being introduced with tags on goods. The systems analyst interrogates the "customer", collects functional requirements, fixes them, discusses with their development team, after which they make a joint decision to offer the customer a configuration for the implementation of their software product. After discussion and agreement, the analyst describes the statement of the problem in a document that is agreed with the customer. In the waterfall approach, the stage of coordination is again carried out, approval of the implementation, after which the team proceeds to development. But the analyst's work does not end, as he accompanies the stage of development, testing, implementation into the customer's environment, configuration and maintenance, and, if required, further development of the product.
Of course, we have briefly covered the classic system development process. Depending on the development methodology, the process may change, but the functions that the analyst performs remain the same. On small projects or on projects with a fairly simple business logic, but complex development, the responsibilities of a system analyst may include the responsibilities of a business analyst, a manager (coordinating task execution, monitoring deadlines, identifying problems, etc.), a tester, and even support services. As a business and systems analyst, I can immediately say that you will not be bored at work. And the scope of responsibilities, which can change from project to project, will give a person the opportunity to develop in different directions, learn new things and apply their knowledge in practice.
No comments:
Post a Comment