Systems Gathering Requirements Document

During the systems planning phase a feasibility analysis was performed in determining if purchasing a software program would meet the demands of operations (need), technical (practicality), and economic (financial) factors of the project. Given the fact that over time, collateral analysts spend a tremendous amount of time manually calculating borrowing base ineligibles from cumbersome agings, management along with the IT department have approved the request to purchase the software program. The assessment was performed by departmental bank management, IT department, the software developer, and the departmental liaison. In order for the project to move forward to phase two of the SDLC, the system analysis phase must be accepted.

IN THE SYSTEMS ANALYSIS PHASE OF THE SDLC, YOU USE MODELS AND OTHER DOCUMENTATION TOOLS TO VISUALIZE AND DESCRIBE THE PROPOSED SYSTEM. THE OVERALL OBJECTIVE OF THE SYSTEMS ANALYSIS PHASE IS TO UNDERSTAND THE PROPOSED PROJECT, ENSURE THAT IT WILL SUPPORT BUSINESS REQUIREMENTS, AND BUILD A SOLID FOUNDATION FOR SYSTEM DEVELOPMENT (SHELLY, CASHMAN & ROSENBLATT, 2004, P. 92,¶ 1).

Resulting in the design of the overall system called the system requirements document of the systems analysis phase. However, before the system requirements document can be written the systems analyst must gather information that will be recognized. This document will discuss the various methods to be used to determine requirements for the proposed system.

The first process in gathering requirements is to conduct interviews with managers, department heads, and users. During this process questions are formed and information is gathered. One main question that a systems analyst will ask is, “Do you see any advantages in the proposed system?” The responding reply might state that the new system will cut down on the amount of time it takes an analyst to calculate borrowing base ineligibles.

Other responses may be that the new system will save both the customer and the bank extensive time and money. Meaning, customers who have access to export cumbersome agings into an electronic format will no longer have to be bothered with printing accounts receivable and accounts payable agings. During the interview process the systems analyst should avoid leading questions, such as “The current requirements for recording borrowing base ineligibles is time consuming, isn’t it?” rather the systems analyst should ask “What aspects of the current requirement for calculating borrowing base ineligibles do you find the most difficult?” The analyst should also let the potential users know that constructive criticism is accepted and needed in order to convey requests to the developer.

In addition to these questions the systems analyst will need to determine if users will be comfortable with using a computer and new software. Therefore, during the interview process the interviewee may be asked “What his or her computer capabilities are if training is offered would the user participate?” Depending on the responses from the interviewees’ the design of the program will have to be simple if computer capabilities are limited. Complex screens and formatting requirements within the program will have to be made as simple as possible. Users may also request that the imported files are capable of being printed, such as top 10 customers or vendors, ineligible detail, and a summary of the aging itself if a detailed aging was imported. Along with this request users have implied that historical aging information be maintained for approximately two months and that the agings can be exported an Excel spreadsheet.

Once the interview process is complete the systems analyst should summarize the main points covered during the interview and inform the interviewee that follow up information or correspondents, such as additional questions or comments is appreciated if he or she thinks of something after the interview. Give the interviewee reassurance that his or her opinion matters. Before the interview is closed the systems analyst should make sure responses are understood by rephrasing unclear answers. In addition to this the systems analyst will need to document the interview.

One way to accomplish this task is by taking brief notes that will be easily recalled, however, time should be set aside to record responses via an electronic recorder or even record the conversation with the interviewee approval, of course. The systems analyst will also observe body language and nonverbal responses. Assuming this situation occurs, the interviewee may be holding back comments or opinions because he or she thinks statements made may be shared with management where he or she may be held accountable. Again the systems analyst should reassure the interviewee that this process is used to gather information not a bashing session.

The systems analyst should also consider forming a questionnaire that can be distributed to each user prior to the interview. The questionnaire should be user friendly, brief and to the point. Questions can range from “What percentage of time during a work day does calculating a borrowing base take? or “How many agings can be worked manually during a five day business week?” and “How many customers are currently sending in printed agings?”

After the interview process and questionnaire the systems analyst will need to gather samples of the accounts receivable and accounts payable agings in order to determine what heading formats and what column and row formats are being used. The systems analyst will also need to determine what type of electronic importing files will be able to interface correctly with the software program. Assuming that the majority of the department’s customers have somewhat current operating systems most will be able to either export company agings into a PDF file, Excel spreadsheet, or text document. Customer agings that are able to be exported will need to be formatted during the initial by importing the reports into the bank’s new software program.

This process will take some time initial because of heading, column, and row formatting. However, once formatted correctly the user will be able to format automatically the imported agings, given that the reports are setup the same way each time. During this phase or the requirements gathering the systems analyst should research the software developer’s website to verify if a trial version of the software is available and other consumer response of the software developer. One way to do this is to check within the banking industry and determine what is available and what other banks are using, if possible. Assuming the systems analyst has contact with other banking systems analyst this process will be fairly easy; however, if the systems analyst has no past dealing with other banking industry employees this may be an uphill battle.

Overall, requirements gathering can be a difficult and extensive process. Therefore, systems analysts should be prepared to ask clear and concise questions, avoid leading questions and prepare questionnaires for interviewees. Once the interview process has been completed the systems analyst should review documented notes and responses in order to begin the sampling and research process of the requested requirements.

REFERENCES

Shelly, G. B., Cashman, T. J., & Rosenblatt, H. J. (2004). Chapter 3: Requirements Modeling. In _Systems Analysis and Design_ (5th ed., p. 92). Course Technology. Retrieved September 28, 2008, from http://ecampus.phoenix.edu/content/eBookLibrary2/content/ereader.aspx?assetmetaid=3df7b872-d3c7-4c1f-a0fe-5ed46961030c&assetdataid=c2047d4b-7855-450e-b51e-6e007038bd6a