Problem identification
In the hypothetical situation of the library environment, problem identification will be achieved by making observation and inquiry into the functionality of the current system and conducting a comparative analysis of the current system with a functionally operational computerized library system. The preliminary investigation will crystallize the benefits of the proposed system compared with the current system to reinforce the rationale of adopting and implementing the proposed system.
The identification process will involve problem understanding of the intended users expressed in technical terms, convincing the users about the viability of the proposed system. Stakeholder problems will need to be identified in the problem space and mapping them into the solution space through specific algorithms (Blank & Barnes, 1998).
That will lead to requirements identification and definition. Overly, it will entail a requirements list that will be detailed by a requirements set that will be characterized by user requirements elicitations, requirements validation tailored to meet user needs, requirements verifications, requirements analysis against user needs, and a requirements management. However, problem identification will be conducted by collecting information from the library personnel (Blank & Barnes, 1998).
The role of personnel
The library personnel will play a critical role in creating the program for the proposed library system because they are and will be users of the current and proposed system. In addition to that, these users provide critical information about the current system that will lead the system developer to understand the problem inherent with the old system, thus enabling the developer to critically develop and outline the problem statement. The personnel know well stakeholders provide further information about the stakeholder. In addition to that, the problem statement will provide a detailed view of the impact of problems inherent with the old system in view of the new system. That will lead to the next level where the problem is translated into technical program solutions.
Program development lifecycle
A modular approach to program development lifecycle will involve defining the problem, then designing the problem based on the requirements that have been set out in technical terms, developing program code, debugging the developed program code to remove any errors inherent in the system, testing the program code and modules using different testing strategies such as bottom up and top down approach. Then, culminating with maintenance of the modules and program code and ending with extension and program redesign if need arises (Blank & Barnes, 1998).
Modular approach to problem solution
Once the problem is well defined and requirements list is technically mapped into program code, then the problem will be decomposed and modules developed to reflect the solution to each problem with a precise algorithm. However, the process is iterative and the modules will be integrated gradually to form a single library system. Modules are independent and will reflect all parts of the library such as the database and their interfaces (Sidky, Sud, Bhatia & Arthur, n.d).
Benefits of modularization
Modules can be delinked from the main system and overhauled. In addition to that other maintenance operations can be performed without affecting the functionality of the whole system. Each module reflects its problem domain and problems can be handled independently. New modules can be added and interfaced with the whole system allowing for system growth and integration with other new systems.
References
Blank, G., & Barnes, R. 1998. The Universal Machine, Boston, MA: WCB/McGraw-Hill.
Sidky, A.S., Sud, R.R., Bhatia, S. & Arthur, J.D. n.d. Problem Identification and Decomposition within the Requirements Generation Process. Web.