Business Analysis & Requirements Frameworks - Essay Example

? Business Analysis & Requirements Frameworks Executive Summary Ambridge Software Ltd (ASL) has been declared as asoftware development organization whose specialization is to develop and tailor customized software in order to make them meet the needs of small and medium enterprises (SMEs). The managing director heads the top leadership, who has senior managers who report to reporting to her. The senior managers include the manager in charge of Software Development, manager in charge of Sales and that of Accounts (Thayer & Dorfman, 1997). At present, the Software Development Manager is the head of the software development. He is in charge of operation in the development together with the different Project Leaders including Software Trainers, Business analysts, Software Developers and one Technical Author. The study finds out that there are about ten different projects running at any time in Ambridge Software Ltd. The different departments are expected each to contribute to the development of software in Ambridge Software Ltd through specialization (Kotonya & Sommerville, 1998). There are different scenarios that occur from time to time, and prompt different actions to create transformation. 2. Introduction This study evaluates different scenarios and recommends the appropriate actions for the management of the scenario in Ambridge Software Ltd (Robertson & Robertson, 2006). It considers the position of a staff member of Ambridge Software Ltd in relation to the decisions of Software development, as well as the position of an employee of one of the clients of Ambridge Software Ltd (Sommerville & Sawyer, 1997). This takes place in various scenarios, involving different authorities including the project managers, Software Developer, Software Trainer, Technical author, Business analysts and support staff. The scenarios further consider the different stages of software development such as functional specification, Design specification, programming phase. Each leader has responsibilities to manage in the process of the development process (Kotonya & Sommerville, 1996). This report selects scenario 1 where the company realizes that there is the realization that misunderstanding led to certain unplanned changes on some projects. In this, there was poor understanding between the customers and the development team in Ambridge Software Ltd. The system developers apparently failed to understand the software requirements and their documentation (Macaulay, 1996). From the scenario, it was appropriately decided that there should be an update in the protocol and system documentation will be installed (Yeates & Paul, 2006). In the initial stages, there was a meeting held with the Ambridge Software Ltd customer at different durations before the beginning of development project. At the same time, there are three intervals every month while the project is in progress (Goquen & Linde, 1993). The processes and the stages involve the development of reports to the project coordinator. The project leader then has the task to distribute the information to the members of the teams who are working on the project. 2. Scenario One: Report 2.1. Discussion The division of labor and specialization is a special opportunity for the Ambridge Software Ltd staff to exercise their knowledge, experience and skills in the development of the software. There should be an understanding between the customers and the development team such that the final product is satisfactory and considerate of the issues affecting the Ambridge Software Ltd customers (Finkelstein et al, 1992). This requires frequent visits to the customers’ sites to identify their needs. It becomes easy to know how the system can implement them. The second recommendation is to involve the customers in the process of testing and evaluation of the system. This removes the misunderstanding between the development team and the customers. 2.2. Recommended Approach 2.2.1. Cost and benefit Analysis The costs involved here include the costs of travelling from the Ambridge Software Ltd to each of its client company. This is critical to the company because some of its clients are possibly in distant locations, both regionally and internationally. The second cost is about communication (Stapleton, 1997). It is essential in the sense that apart from physical visits, there will be need for communication through various channels. Finally, there will be the cost of trials of the system and documentation of technical specification (Holt, 2005). 2.2.2. Identification of the Deficiencies In order to identify the weaknesses of the system, the project team can analyze it through the testing process, in line with the original specification. The testing will reveal the tasks, which the system is not able to perform so that the future versions will be able to take care of the weakness. The other way of identifying the system deficiencies is by holding workshops with the customer to exhaust the details of the system and to receive the feedback from the customer’s views. The feedback will assist Ambridge Software Ltd to understand the exact need of the customers. This therefore will reduce the deficiencies in the system and its failure to meet the needs of the customers, who are the end users (Finkelstein, Kramer & Goedicke, 1990). The system developer and the technical author are very important at this stage and it is advisable that they attend workshops and discussions where testing of the system takes place. 2.2.3. Contract Revision The recommendation is that the IT managers and the business analyst go through the contract once again to revise I and address any issues that they find to be unclear. It may not help the current system because the contract has already been signed. However, this can assist in the future software projects. This follows the doubtful condition about the understanding of the customer regarding the system requirement (Easterbrook & Nuseibeh, 1995). From the contents of the documentation, it is possible that the customer will not be satisfied with the Bespoke Software. We recommend a proper understanding to eliminate the situation that could lead to the rejection of the system because of its inability to fit into the end user needs. 2.2.4. Customers’ Feedbacks It is possible for the IT manager to clarify to the customers about the desired system functionality. It is clear that the customer does not understand the requirement of the system for the from the documentation (Pfleeger, 2002). To avoid the situation, the recommended plan is to revise the contract together with the customers and to get feedback from them (IEEE, 1998). The feedback will address the deficiencies in the specification and the requirement documentation. The second recommendation is to include clauses in the documentation that indemnify our company from the responsibility of high-risk activities. During the functional specification, the customers can attend the discussions with the project team involving the technical author and the business analyst. The contents of the system documentation are very important and have to be understood properly. The documentation has to be written in simple language that the customers can understand before signing. The customer can then provide samples or the prototype of the bespoke system, dealing with SME businesses (Brooks, 1995). The documentation of the situation can assist in the rectification of the present and the future systems. The technical author will have to prepare a holistic documentation that considers the benefits and the safety of the organization. According to the recommendations for the future development, the programmers will manage the deficiencies during the programming phase (Weigers, 2003). 2.2.5. System Integration Plan The project team realizes that the recent needs in the market involve system integrations to relational databases. The requirement is that our company develops a system that is properly linked to a database. The database therefore forms part of the technical specifications. Recommendation for the software improvement is that the SME Bespoke software should have a network-based database such as SQL server or oracle (Hass, Vander & Ziemski, 2008). The model technique used in the design of the software will have to demonstrate the movement of data from the entry point to the data processing then finally to the data output. 3. Data Modeling Tools One of the modeling tools for this project is the Use Case Data Diagram. This is fitting for the purpose of the system because it has so many sequences of data processing stages. This tool shows the processes, through which data will flow (Ghezzi, Jazayeri, & Mandrioli, 2003). It also shows the actions and responses of the actors. It shows the validation stages in which exceptional situations in the data processing takes place (Alexander & Stevens, 2002). The entire process is covered using special symbols such as boxes and arrows, pictures representing actors and lines to separate the actions and responses of the actors. The second modeling tool is the Entity Relation Diagram. This model shows the relationship between the different data sets. For example, the SME software will be able manage a data about customers and their related transactions. The Entities in the model will thus include customers and Transactions. Others will include accounts opened, Suppliers, Orders, Products and Employees. Actors in the Use Case Diagram include employees, customers, managers and suppliers. The processes include Orders, system technical specification, Functional system evaluation, requirement analysis, programming and testing. 4. Management of Excessive Costs. The long-term cost in the system model is the software procurement, the relationship between suppliers and customers and the cost of maintenance of the system. It also involves short-term costs such as the payment of the cost of the software and the cost of installation. The benefits of the system are the automation of the SME transactions and data management for as long as then system exists. The cost of the development has to be kept to the lowest to ensure that many other projects that runs in the organization (Ambridge Software Ltd) are not interfered with. This is because Ambridge Software Ltd has about 10 projects being developed concurrently. 5. Organization Strategy The cost and benefit study in this project leads to a special decision about the strategy of the organization in relation to data processing. The design of the database should therefore have a level of integration that considers every entity. This enables the organizations to have the Core Management Information System to manage every process. It saves cost of system acquisition and maintenance because then there will be no need of having to procure extra systems. 6. Conclusion The main aim of the modeling and the design processes is to identify deficiencies and weaknesses of the existing system in order to prepare a new framework for improvement. It uses the knowledge of the concept of the present system to suggest appropriate models in the new business requirement (DSDM, 2003). The different forums and discussions are meant to analyze the current problem domains and evaluate the applicability of the different data models as well as the frameworks for improvement. It also examines the appropriateness of procedures used, and the identification of prospective plans to overcome the limitations of the methods. The research activities were successful in explanation of the strategies to make the future systems better. References Hass, K. B., Vander, H.R., & Ziemski, K., 2008. From Analyst to Leader: Elevating the Role of the Business Analyst Management Concepts, 2008. Alexander, I. F., & Stevens, R., 2002. Writing Better Requirements. Harlow, England: Addison Wesley. Brooks, F. P., 1995. The Mythical Man-Month: Essays on Software Engineering. London: Addison Wesley. DSDM Consortium, 2003. DSDM Tour. Retrieved 26th August, 2004, from http://www.dsdm.org/tour/default.asp. Easterbrook, S., & Nuseibeh, B., 1995. Using ViewPoints for Inconsistency Management. IEEE Software Engineering Journal, 11 (1). Finkelstein, A., Kramer, J., & Goedicke, M., 1990. ViewPoint Oriented Software Development. Paper presented at the International Workshop on Software Engineering and its Applications, Toulouse, France. Finkelstein, A., Kramer, J., Nuseibeh, B., & Goedicke, M., 1992. Viewpoints: A Framework for Integrating Multiple Perspectives in System Development. Int. J. of Software Engineering and Knowledge Engineering, 2 (1), 3158. Ghezzi, C., Jazayeri, M., & Mandrioli, D., 2003. Fundamentals of Software Engineering (2nd ed.). New York: Prentice Hall. Goquen, J., & Linde, C., 1993. Techniques for Requirements Elicitation. IEEE. Holt, J., 2005. A Pragmatic Guide to Business Process Modeling. London: BCS Publications. IEEE, 1998. IEEE Recommended Practice for Software Requirements Specification. IEEE-830. Kotonya, G., & Sommerville, I., 1996. Requirements Engineering with Viewpoints. Software Engineering, 1 (11), 5 -18. Kotonya, G., & Sommerville, I., 1998. Requirements Engineering: Processes and Techniques. New York: Wiley. Macaulay, L., 1996. Requirements Engineering. London: Springer. Pfleeger, S. L., 2002. Software Engineering: Theory and Practice. London: Prentice Hall. Robertson, S., & Robertson, J., 2006. Mastering the Requirements Process. Harlow: Addison Wesley. Sommerville, I., & Sawyer, P., 1997. Requirements Engineering: A Good Practice Guide. New York: Wiley. Stapleton, J., 1997. DSDM: Dynamic Systems Development Method. Harlow: Addison Wesley. Thayer, R. H., & Dorfman, M., 1997. Software Requirements Engineering (2nd ed.). Los A lamitos, CA: IEEE Computer Society. Weigers, K. E., 2003. Software Requirements. Redmond, WA: Microsoft Press. Yeates, D., & Paul, D., 2006. Business Analysis. London: BCS Publications. Read More