The beginning of any project starts with requirements gathering. What would seem to be a ‘no-brainer’, however, is the key factor that determines project profitability and the customer satisfaction level of any business deal. It is also an area of expertise which is not always treated with the deference it demands.

Requirements gathering done well means profitable sales and high customer satisfaction – done half-way or not well at all can mean the end of your own business.

“Requirements gathering” is more than just finding out what the client needs today. It means learning all you can about your customer’s business and daily routines (in their truck on a cell phone or in the office most of the day?), as well as future plans (expansion, increased staff, new product lines).

It also means finding out how knowledgeable your customer is regarding the solutions available to them and what capabilities are theirs for the asking. Are they willing to invest some time to learn the new tool, or should it be completely mistake proof? How much flexibility do they need for daily activities? What logistical or capital investments will be needed to implement the new tool?

And sometimes, it means gently educating the client on the subject of ROI (Return on Investment). Once clients get a glimmer of the amount work hours saved via a line or two of software code, or the purchase of a new machine, it’s easy for them to start dreaming of all the new requirements they’d now like to add.

Showing what all is possible while pointing out which options offer the best return becomes a fine line in the requirements gathering process.

Extra care spent on requirements gathering allows for greater quote accuracy, facilitates better communication during the course of the project and enables you to exceed the expectations of your client.

Excellent requirements gathering methods makes doing business with you a Great Return on Investment for your clients.

While accountants and financial analysts throughout major corporations all over the world rely heavily upon the information that financial statements provide, those numbers are generated from business systems, such as SAP, PeopleSoft and others. A business systems analyst, or, more likely, a fleet of them, is a key part of the team that maintains these crucial business systems.

Information technology has grown as a profession over the past fifteen years, growing by leaps and bounds in the area of finance with the passage of the Sarbanes Oxley Act in 2002, which means that there are more jobs than ever before for a qualified business systems analyst. Unlike many information technology professionals who are versed only in the technical aspects of how computers are built or how to administer networks, a business systems analyst is able to not only understand the intricate details behind the financial systems that generate a corporation’s financial statements but are also able to understand those numbers.

A business systems analyst likely has an undergraduate degree in either accounting, computer science or both. If he or she has a degree in computer science then he or she has gone on for his or her master’s degree in accountancy or business administration, in order to straddle both the financial and information technology arenas. Both of these areas require business systems analysts to remain up to date on frequently changing technology, laws and regulations, which means that a business systems analyst can expect to spend a great deal of time each year in continuing professional education courses, regardless of whether he or she is required to do so as part of a certified public accountant license or another license.

While there may be a wide variety of different individuals in this field, the most successful business systems analysts are generally capable of being both detail oriented and multi-tasking without becoming overly stressed. They are also able to explain complex financial systems to non-technical staff.

For professionals working in the IT industry, especially in careers like software engineering, project management, and computer programming, requirements training comes in handy. This type of training provides each professional with the skills that are needed to collaborate on a software project.

Say, for instance, that a business will contract with an IT/software development firm to build a new human resources information management system. This business has researched possible options, such as using a scalable application such as PeopleSoft. After evaluating the capabilities of PeopleSoft, this company decides that a custom application built around its specific organizational needs will do the best job in helping the company to make strategic human capital decisions.

Commissioning the project with the IT firm will require a long-term collaboration between the IT staff and HR experts in the business and the project team from the IT firm. They are going to need to speak the same language. Chances are that the people in the IT firm will already have the training they need to build a new software application to meet this business’ needs. This business could benefit from sending some of its own staff to the appropriate requirements training.

Through a well-delivered requirements training course, IT staff can learn to speak the language the same as the IT firm’s staff. For example, if the project is going to be written using Agile Software Development, which has been around since the 1990s, the business might send its tech staff to take requirements training specifically for working with Agile software.

Agile software is an example of development software that requires the tight collaboration between the IT firm’s project team and the specific experts working in the client business. This software requires a certain set of conditions for the collaboration between both businesses to be successful.

A business systems analyst is an individual who analyzes, specifies, and designs business applications for both management and users. Business managers and users need clear direction and information, similar to a road map that will successfully lead them to their final destination to ensure the success of a business project. The responsibilities of a business systems analyst include the analysis, understanding, and documentation of the business processes of a project that forms the initial project requirements.

A typical workday revolves around many tasks and phases. During the planning phase, the business systems analyst may interview the business application manager or user and/or conduct additional research to gather information about how the business project will fulfill the financial success or other business needs of the entity. After the planning phase, the next step involves the analysis of different business models to understand the business processes and policies of the business. The business systems analyst will now have enough information to produce a detailed business process model. Finally, information technology facilitates the interpretation of the business policies, formulas, and business requirements.

A business systems analyst possesses a technical background, either through work experience as a programmer or engineer or through the attainment of a Computer Science or Management of Information Systems degree. Experienced business systems analysts possess both excellent business knowledge and capabilities in systems analysis and design. Other abilities include knowledge of math and logical thinking and excellent oral and written communication skills. A business systems analyst wears many different hats. Examples of these roles are process analyst, system analyst, project manager, application support, data analyst, and tester.

Let’s face it. User acceptance testing will make or break a software project. No matter how skilled the project manager, no matter how hard-working the development team, the project can’t succeed without solid user acceptance testing.

From the customer’s standpoint, acceptance testing is the proof of the pudding; it’s the formal demonstration that a fully-working, completely satisfactory product is being delivered. From the developer’s standpoint, it’s a leg to stand on; successful user acceptance testing provides positive evidence that the project is complete and that full payment is in order.

For these reasons, it’s imperative that both customer and developer agree on a detailed user acceptance testing plan, which should include at least the following points.

1. It is vital that the test plan covers all software features listed in the original specifications, in checklist fashion, to ensure that the customer sees that everything has been done as requested. Experience shows that testing most but not all software features is the single most prevalent cause of dispute and difficulty after delivery.

2. The test plan should cover the course of action to be taken by the developer if an element of the software doesn’t pass the test.

3. The test plan should cover the course of action to be taken by both customer and developer if the customer finds, during user acceptance testing, that new or different features may be required.

4. The test plan should include a means of resolving technical disagreements, such as referral to a combined developer-customer technical committee, or the use of a mutually agreeable third-party consultant.

5. The test plan should be time-based and include specific dates for completion of testing, correction of problems, and final sign-off.

User acceptance testing is critically important, and wise project managers give it their full attention.

A business system analyst is the crucial bridge that facilitates communication between an organization’s business and technical departments. For instance, a business manager with little or no technical background, would face great challenges if he were asked to come up with a business system. There is no guarantee that he will be in a position to visualize the system specifications sufficiently, so that they can be passed on to the IT department for implementation. Therefore, someone with knowledge in business, and with the necessary technical know-how will be required to act as a conduit between the business manager and programmers; hence the need for a business system analyst.

For any organization to be functional, the business and IT departments must be seen to work in harmony, without either one seemingly dominating the functions of the other. As such, the business department must stick to its core functionality of operations, whereas the IT department sticks to implementing systems. A business system analyst on the other hand, has the responsibility of being the go-between, by carrying out the functions that fall within the grey areas of these two departments.

The functions of a business system analyst include researching problems and coming up with possible solutions, studying business models, coordination of the development of business systems, and recommending suitable business software and systems. These professionals have to sit down with clients or business managers, to get the system requirements in non-technical terms. They then have to convert these specifications into technical language e.g. system architecture and processes, designs, flowcharts, and databases, that programmers can work with.

On the other hand, a business system analyst can recommend the most suitable solution that will enable a business to operate efficiently. Their recommendations are normally based on factors such as the hardware configuration that will be required, the cost of implementing and maintaining the system, the overall usability, and the speed of the system.

First requirements training is a general term primarily used in a business setting. It is important that businesses have a process for their employees to receive requirements training as it can affect not only their present customers but can affect the potential of acquiring new customers. In this respect requirements training is an integral part of business success. The training process for any business is critical.

There are two aspects of requirements training. The first involves those performing various functions understand the details of the function they are performing. It is important for any function to not only understand what it represents as part of the overall process but the importance of following requirements associated with the function. In business depending upon the nature of the products or services employees must have the proper training to do the job with the utmost quality. This is important to project the perspective that a company produces quality products and services.

The second aspect of the need for requirements training involves requirements identified in contractual documents between customers and the company. Understanding the requirements is another critical aspect of doing business. Customers can have specific detailed requirements that they want products or services to meet when they receive them. In some cases understanding the requirements may require conversations between customers and companies where requirements may be vague. This is necessary so both parties are on the same page.

Contractual requirements once understood must be compared to the detailed instructions in place for functions/operations which will be involved in completing the tasks identified in contractual documents. This is where requirements training come into the picture. Those performing various functions must understand their own process but the associated contractual requirements involved and how they may be different. There are always going to be differences between contractual requirements in relation to processes. The key is how businesses address those differences however minor that determine the successful delivery of a product or process.