Introduction
The role of information technology (IT) has in recent years played an increasingly important role in the way people do business (Shelly, Cashman and Rosenblatt 4). IT refers to a combination of hardware and software products and services used widely in business for management, access, communication, and sharing of information. The role of IT has become increasingly pervasive given that forms can use this information as a vital asset thus suggesting constant updates and safeguards (Shelly, Cashman, and Rosenblatt 4).
It has been reported that between 2000 and 2007 the global online population has increased dramatically to well over a billion users dispersed across the globe (Shelly, Cashman, and Rosenblatt 4). This position is supported by data from the US department of labor that indicates that the IT sector is expected to create over a million jobs by 2016. It is already known that the IT sector receives a large portion of annual company budgets despite the effects of global economic trends.
In the development of an IT project aimed at automating or improving business processes, an analysis needs to be carried out by the systems analyst. This process is a step-by-step process that is aimed at the production of improved and high-quality software systems. An IT system is aimed at combining IT, data and people in a manner that will bring improvements to the business processes thus improving efficiency or profitability (Shelly, Cashman and Rosenblatt 5). In the traditional model of business a company developed its own IT solutions also known as in-house applications. The second option was the use of an external IT team to develop a purchased system. Regardless of the approach used to develop the software, there is a great risk when a company attempts to determine how the system will be implemented. Instead it is often more advisable to determine what is expected of the proposed system (Shelly, Cashman and Rosenblatt 5).
The above statement suggests that instead of placing the cart before the horse, a company is more likely to succeed by clearly outlining business needs and searching for suggested IT solutions (Shelly, Cashman and Rosenblatt 5). Thus a company must have a clear set of objectives before deciding on areas that require the implementation of IT-based solutions. In this report the discussion will be based on gathering requirements and using these to design an object-oriented solution to satisfy a business need.
Systems Analysis and Business Problem Resolution
From the introduction, it is possible to suggest that systems analysis is a practical task that is based on time-tested and rapidly evolving techniques and knowledge (Satzinger, Jackson and Burd 4). Though an analyst must understand computers and programs, they also should possess curiosity on how tasks are carried out and the determination to make these tasks easier to perform. The analyst therefore must in addition to having programming skills have some knowledge on how to identify bottlenecks in business processes and find ways to unlock these bottlenecks.
The system analyst must suitably address the business problem. The analyst’s first and very crucial task is to carry out research and identify the problem to be solved. Perform a costs benefits analysis that can prove that the cost of implementing the proposed solution is lower than the costs currently incurred by the existing system (Satzinger, Jackson and Burd 5). This is crucial given that business is about making a profit and if the costs of producing and maintaining a system are very high suggesting business losses then it is not advisable to implement the solution.
Once the cost-benefit analysis has been done successfully, the analyst must then proceed and define set requirements for solving the problem. These requirements will form the basis by which the analyst can produce a variety of alternatives to solve the problem. Once this has been done the analyst should prepare the variations and suggest a suitable solution from the proposals (Satzinger, Jackson and Burd 5). This task is especially crucial given that the analyst alone can identify potential pitfalls with each approach and thus is in the best position to decide on a suitable option. From that statement, it is possible to understand that this suitable option may not be the best solution. Reasons for this include the fact that the cost of the solution may outweigh the benefits.
Once the recommendation has been made the analyst should define the details of the recommended solution. With a clear set of objectives to meet the analyst then hands over the task to the design team to prepare the software-based implementation (Satzinger, Jackson and Burd 5). After coding and testing the software, there is a testing period where the team can assess whether the solution provides the user with the desired results.
Critical Project Factors
In most software development projects it has been noted that the majority of software projects result in failure. The main cause for such failure has been identified as poor requirements analysis, as a result, causing only 9% to 16% of all software projects to fail or fall behind schedule (Satzinger, Jackson and Burd 75). The main reason behind the failure of most software projects is traced to the requirements analysis phase. Among the notable causes include incomplete and changes in requirements, limited user involvement, lack of or inadequate user involvement, lack of technical support, poor project planning, unclear objectives and lack of required resources, inadequacy in risk assessment and unreasonable expectations (Satzinger, Jackson and Burd 75).
On the contrary in cases where projects have successfully been implemented some critical success factors include; clearly understood requirements definition, substantial user involvement in the requirements and subsequent phases of a project, support from administrative personnel, through and clear project plans, and the use of realistic and accurate project schedules and milestones during design to maintenance (Satzinger, Jackson and Burd 75). In summary, it would appear that the requirements need to be determined before the design phase and not the other way around (Shelly, Cashman and Rosenblatt 75).
Requirements Modeling
In traditional software engineering models it is not uncommon to see tasks being completed sequentially. However, this is among the main causes for the failure of a software project given that requirements are likely to change at any point during the development cycle (Shelly, Cashman and Rosenblatt 138). This is among the main causes for the need to incorporate an approach that allows for iteration between related stages in the software project life cycle (See Figure I). This is especially crucial in the stages of requirements modeling, object modeling, and lastly in data and process modeling.
Another approach to the requirements modeling is the use of Rapid Application Development (RAD); Joint Application Development or Agile methods to systems design (Shelly, Cashman, and Rosenblatt 143). These approaches have been known to present some disadvantages to the design team in the course of software development. It is because of such reasons that the agile methods were selected as a suitable approach for this project.
Agile processes are known to reduce the risks associated with a project because they ensure constant production of deliverables (Shelly, Cashman and Rosenblatt 145). Other than the above advantages agile processes also bring with them some specific disadvantages such as the fact that the development team requires to have well-honed technical and interpersonal skills. Also due to the rapid mode of production a lack of documentation and sequential structure can reintroduce significant risks in case a problem emerges in the software team.
A well-chosen business remodeling approach is likely to have a significant impact on the remodeling and eventual system. Different models provide the project leader with different views of the system and requirements for that system. For example an activity-based remodeling will most likely result in changes in how the activity is to be carried out in the completed system (Kock 79).
The selection of an appropriate technique for business remodeling is crucial in construction of an effective and satisfactory solution. It is already known that the more abstract a concept the more likely it will be understood in varying ways by different people (Kock 80). Such abstract concepts occur upon completion of fact-finding through the use of interviews or questionnaires (Doyle 98). The process of remodeling is aimed at bringing the understanding of the concept to a more unified understanding. For example, remodeling process will define what is meant by a four-legged chair as opposed to the conceptual differences that may arise when the solution merely defines a chair. This remodeling process is crucial to aid in
This process does not entirely remove contradictions as there is still room for variation in terms of the color of the chair, height and the material used to create this chair (Kock 80). Despite the existence of such differences it is clear to see that the description that is accorded due to the use of business remodeling has removed the significant variations that could result when the software is still in the conceptual phase.
In a project that is to be completed using agile methods, the software is designed in an incremental approach with new requirements being collected and implemented each time there is an iteration in the software engineering cycle (Shelly, Cashman and Rosenblatt 143). Another approach that has been found to be effective in the development of software is the use of a class diagram.
In this approach to software design and construction software requirements are often identified using CASE tools (Shelly, Cashman and Rosenblatt 145). This approach was found suitable due to the ease with which Agile processes can identify and adapt to changes in requirements. Further the Agile processes place a lot more emphasis on team interaction and reflect community values in the completed project.
As mentioned in the introduction to this report that software that is to be produced is object-oriented due to the fact that this approach allows greater ease and faster learning for the user. Based on this it suggests that the software requirements will rely heavily on the use of use-case diagrams. These diagrams are constructed using unified modeling language and rely on the use of some popular identifiable symbols (See Figure II). In this approach the humanlike stick figure is used to identify an actor which represents an organizational function such as a shop operator entering details of a purchase (Kock 94). A line is used to represent an association between the actor with one or more use case symbols.
An oval represents a use case that is very much like an actor in a communication flow diagram (Kock, 93). A rectangle is used to encase a set of use case symbols that are supposed to be part of or associated with the same computer system. The use case diagram is very essential in object-oriented software engineering. This is because once it has been drawn to provide a wholesome view of the system (both the automated and non-automated parts) the software development team can embark on the identification of objects and their attributes (Kock 94).
The use case diagram is reported to be the universal foundation for all universal modeling language techniques (Denis, Wixom and Roth 505). A well-defined use case will allow us to determine what the system needs to accomplish at a very high level of abstraction. The use case allows us to observe a number of different interactions with the systems and identify different users who will interact with the complete system. For example, the actor in the use case diagram defines an external entity that can be used in the construction of a dataflow diagram (DFD). As the name suggests a DFD is an approach that aids in constructing the system by emphasizing the flow of data and identifying different inputs and outputs that are crucial in the system (Denis, Wixom and Roth 509).
The proposed solution for this report is meant to be an object-oriented software solution and as such the use case diagrams will be essential in that they can aid in designing the classes and identifying their attributes (Denis, Wixom and Roth 512). These can be very useful when it comes to drawing a class diagram (See Figure III).
From the above illustration, it is possible to see just how the use case diagram can be used to produce a class diagram (Denis, Wixom and Roth 513). Based upon the activities of each actor the software development team can embark on the identification of classes that will be useful in the process. A class diagram is drawn based on storage and management of information in the system. A Class diagram is useful at various stages of the software development cycle. During analysis, the diagram can be used to identify people, places and events in addition to things about which the system should gather information. Later in the cycle during design and coding, the class diagram can be used to define where windows, forms and other objects will be used in the creation of the complete software solution (Denis, Wixom and Roth 513).
A class diagram is drawn in the form of a rectangle with three rows or parts. In the topmost row, there is the class name which is used to identify a specific object that is relevant to the computer system (Denis, Wixom and Roth 512). The second row contains a list of attributes this particular object should include to be wholly operational. The last row contains methods that the class will use to perform any activity that is useful or relevant for the object.
The class name refers to an object, place, or something about which the computerized system needs to collect information. In a class diagram, this name is often written in bold, is centered and occupies the topmost row. There is no explicit list of the methods or operations that the object may be required to achieve. After this row is the attributes row which can be used to define the attributes of an object. It is possible for a class to derive attributes from other objects. In the third row the class diagram contains methods or operations that the class will be required to perform. This provides an illustrated example of what is expected of the class and to which classes it should be associated.
A relationship within the class is denoted by a line (Denis, Wixom and Roth 213). Also included in this relationship is the cardinality or external relationship between the class and other classes in the system. As mentioned earlier this is a result of the external relations and use of external attributes from another class to facilitate the sharing of data. These associations are very essential and need to be uncovered early in the project cycle. These associations are fairly similar to those that are found in Entity-Relationship Diagrams (ERD) (Denis, Wixom and Roth 213).
The steps that are followed in the creation of a class diagram and identification of classes, attributes, and methods are fairly simple and can be drawn from a narrative describing the business processes. IN such a narrative it is possible to identify classes by looking for nouns within the narrative (Denis, Wixom and Roth 217). For example, an employee serving the customer implies the existence of two separate classes. Still on identifying specific attributes it has been reported that verbs in the narrative will imply associations and operations. For example, the librarian files new books, which implies a file operation.
Adjectives in such a narrative imply attributes of a class. For example, all customers over the age of 55 are eligible for senior discount. This implies an age attribute for the customer class (Denis, Wixom, and Roth 217). Lastly an adverb in the narrative implies an attribute of an operation or method. For example, Steve drives very fast, which can be said to imply a class for a driver and speed as an attribute of that driver class.
The discussion so far has mentioned the use of class diagrams, ERD, and use case diagrams in the construction of a software project. Other possible diagrams include a sequence diagram that further provides information regarding the relationship between classes (Denis, Wixom, and Roth 529). In addition to that there is the behavioral state machine diagram that is used in differentiating the states that a single class passes through as it continues its existence amidst the various responses and actions. Through the appropriate use of such diagrams and procedures it becomes possible and fairly simple to design and code a suitable object-oriented software solution that effectively addresses a business need for a given company.
Feasibility Report
This discussion has gone in-depth on the methods that are crucial in the production of an IT-based solution for a Video and DVD known as New Arrivals. The current system used at the store is manual and relies heavily on the use of cards that file to collect and update customer and borrowing information. The current system provides a lot of difficulty in the development and storage of crucial customer data. The current system is also fairly cumbersome as it becomes very difficult to trace overdue rentals and make changes to customer personal information such as phone numbers.
Further, it has been observed that the current system can not provide accurate and reliable reports that are crucial to the operation of the business. For example, it would be good to be able to produce reports that identify the reorder information based on rental data. Also, reports that indicate employee activity such as the number of overtime hours, customer served, daily rental reports, etc are all very difficult to establish when we consider the manual approach currently in use. The lack of a backup system is also very cumbersome as all the company business is constantly updated on individual cards.
It is based on the above limitations with the current system that a decision was made with regards to automating the business processes such as recording sales, making purchase orders, preparation of reports within the New Arrivals premises. The proposed system is expected to provide a reliable databank and easier backup facilities in addition t automating the mentioned processes. It has been noted that such a backup can ensure the business will remain safe in the event of any risky situation and minimize potential losses.
Cost Analysis
As mentioned earlier, a thorough analysis of associated costs is necessary for a project to be economically feasible (Rajaraman 66). Based on the results of a cost analysis a project can be considered economically worthwhile. To perform a cost analysis the project leader must prepare a list of direct costs associated with the project. These include; cost of a computer for the sales counter and another for the office, cost of space which in this case will not be applicable given the shop is already operational, cost of system analysts during the project lifecycle and cost of training which in this case again is not applicable. A rough estimate places these at about $ 800.
After the assessment of direct costs, it becomes crucial to determine direct savings made by implementing this approach (Rajaraman 67). Among these one major saving that will be gained is the ability to quickly identify customers with overdue company material and apply the penalties. It has been observed that during each week there are at least 10 DVDs or Videotapes that are overdue and can be used as a source of revenue, approximately $100 per month. In addition to that, it should provide some reports that can be used by management to assess the performance of staff and sales of various DVDs and tapes.
Once direct costs and direct saving have been assessed it is easy to determine whether the project will be viable or not simply by calculating the payback period. This calculation is based on the duration it would take the proposed system to generate revenue that is equal to or greater than the direct costs. In this case with direct benefits amounting to $100 the proposed system will take 8 months to have generated enough revenue to cover the amount spent on direct costs this may also be referred to as break-even analysis (Doyle 307).
Conclusion
In this paper, a discussion on the role of systems analysis was presented to understand the importance of the requirements stage in software development. It has been noted that traditional methods of software engineering are perhaps the main reason why software projects fall behind schedule or fail altogether. This is because these approaches are very linear and any change along the way often has a ripple effect forcing change to all other parts of the system.
However, in response to the scenario caused or prompted by traditional approaches an agile approach to system engineering was selected. The main reason is, the approach relies on the submission of updated software regularly. It also encourages increased user involvement in the engineering of software. The approach also tends to engineer software in a team-based environment thus ensuring the satisfaction of all related parties.
It has also been established that the translation of requirements to a tangible piece of software requires an understanding of the tools and techniques that are used to translate requirements and produce a software solution that is suitable for all users. Among the most common tools for this in object-oriented software engineering is the use case diagram. These diagrams are used to translate a specific function and identify the essential attributes and operations that are related to these functions. In addition to that, there are also data-related tools such as DFD’s that can be useful in providing a clear understanding of the flow of information. There are also activity-related tools that can be used to trace the flow from one activity to the next in the completed system. Through the tools that use information and activity a systems analyst can determine how the system should interact with the user and what information is required at each stage of the lifecycle (See Figure V and VI).
Works Cited
Denis, Alan, Barbara Haley Wixom and Roberta Marie Roth. Systems Analysis and Design. Heboken, NJ: John Wiley & Sons Inc, 2009. Print.
Doyle, Stephen. Information Systems for you. Cheltenham: Stanley Thornes (Publishers) Ltd, 2001. Print.
Kock, Ned, F. Systems Analysis & Design Fundamentals: A Business Process Redesign Approach. Thousand Oaks, CA: Sage publications, 2007. Print.
Rajaraman, V. Analysis and Design of Information Systems. Bangalore: PHI Learning Pyt Ltd., 2000. Print.
Satzinger, John, Robert Jackson and Stephen Burd. Systems Analysis and Design in a Changing World. Boston: Course Technology, 2009. Print.
Shelly, Gary B, Thomas J. Cashman and Rosenblatt, Harry J. Systems Analysis and Design. Boston: Course Technology, 2010. Print.
Appendix
A Sample Questionnaire for the proposed system
What is your opinion of the current sales procedure used on the premises?
- It is very effective
- Effective
- Needs improvement
- Poor
Kindly provide some information on why you have expressed your opinion in the above question. E.g. the system is especially difficult when it comes to searching for customers with overdue tapes. Many times we are forced to wait till the customer returns to borrow to identify a late return. Often when customers realize they are very late they don’t return and it causes the company major losses.
What improvements do you think you would like to see made? E.g. it would be nice for the company to invest in a simple program that can allow speedy access to all the information. Allow for daily reports on late returns and calculate automatically the penalties.
What is your position on the security or reliability of the current system?
- Very Good
- Good
- Fair
- Below average
Do you possess any prior skills in using computers? Answer by circling the correct option.
- Yes
- No
Are you prepared to undergo some training to make your work easier?
- Yes
- No
If your answer to the above question is No, kindly explain why?