System Analysis and Design for Wooster Boomerang Films Ltd - Case Study Example

 System Analysis and design for Wooster Boomerang Films (WBF) Ltd Part1 A- Use case function and purpose A use case refers to a series of events that offer something of quantifiable importance to an actor and is sketched as a straight ellipse. Use case diagrams are used to outline the functionality of a system in a straightforward manner. Thus, before simply demonstrating the particulars of individual characteristics of a system, use case diagrams can be used to demonstrate all its functionalities. Moreover, that use case diagrams are basically dissimilar from sequence diagrams or flow charts for the reason that they do not make some effort to demonstrate the sequence or number of times that the systems events as well as sub-actions ought to be performed (Ambler, 2010), (Heywood, 2011) and (Pressman, 2001). Use cases can be used for almost every kind of project for the reason that they are cooperative in providing information about planning related issues and requirements of the project. Thus, in the beginning of a project the majority use cases should be defined, however as the project carries on more capacity turns out to be noticeable. In simple words, the basic purpose of use case diagram is to recognize the major elements and procedures that make up the system. These major elements are recognized as "actors" and the procedures are known as "use cases." In this scenario, the use case diagram demonstrates which actors relate with each use case (Braun et al., 2011) and (Chitnis et al., 2003). Use Case Diagram of WBF Ltd rental system B- Use case description The process of defining the overall use case along with main aspects of interactions between the system and the users is known as use case description. In the scenario of system development, the main purpose of use case description is to explain overall procedures in addition to aspects those are demonstrated in the diagram so that the viewer can have better overview of the interactions and processes (Sommerville, 2004) and (Pressman, 2001). Rental Process Use case description Use case Description This use case describes the process of film rental for customer. In this scenario a customer places a request for the film. In case film is available then customer provides his personal details. After recording customer details system stores the system film rental information and processes payment information. After payment processing system delivers the receipt to the customer. Precondition/s In order to process film rental request there is a precondition for the availability of the film in stock. If the required film is available in the film stock then the system processes the film rental request. Post condition/s For the successful completion of the overall rental process, there is a need to implement a proper approach for processing the payment of customer. After receiving payment from the customer, system carries out the rental requests as well as provides it by saving customer and film information and delivering the payment receipt. Steps I have outlined below some of the main steps for the overall process of film rental case: Customer requests for renting a film Customer selects the desired movie Customer provides personal details Customer pays the required cost of film he wants to take on rent System saves information System delivers receipt Assuming that the customer has chosen the film and it is available to rent out, produce a step-by-step use case description for the use case ‘Check out Film’ in WBF Ltd rental system using an appropriate template/format that should include: C- Role of class diagram Class diagrams are the foundation of object-oriented design and analysis. Class diagrams demonstrate the classes of the main system that we are going to develop, their involvements (comprising aggregation, inheritance as well as relationship), and the characteristics and processes of the classes. Moreover, class diagrams are used to carry out a broad range of functions, such as together domain/abstract modeling and comprehensive design modeling. Class diagrams are extensively used by the developers to explain the kinds of objects in a system and their associations. In this scenario, class diagrams represent class arrangement and contents employing design basics like that packages, classes and objects. A class diagram explains 3 diverse viewpoints while describing a system, requirement, theoretical and accomplishment. These viewpoints turn out to be obvious as the diagram is made and help freeze the design (Ambler, 2010) and (Braun et al., 2010). Class diagram of WBF Ltd rental system D- Role of interaction diagrams Interaction diagrams increase the performance of use-cases by explaining the ways groups of objects work in cooperation to perform the job. There are two types of interaction diagrams one is collaboration and other is sequence diagrams. Additionally, the interaction diagrams consist of techniques and models that illustrate how a collection of objects work together in a number of ways, normally a particular use case. The diagrams demonstrate a number of instances, objects and the messages that are transmitted among these objects in the use case (Braun et al., 2010), (Stotts, 2009) and (Whitten et al., 2000). Sequence diagram for WBF Ltd rental system Part 2 A- “Analysis” and “Design” in system development Systems analysis refers to the technique in which system analysts carry out a lot of activities to determine the working of a system, which is deciding what processes the system should carry out, whether it is practicable intended for the system to be developed (like that economic feasibility; perform the advantages of the system pay off the costs of building the system), what information and data are going to be gathered and stored. In other words, systems analysis is apprehensive by problem solving, building a system that will resolve an organizational issue. In this scenario, analysis is concerned with a detailed assessment of the existing system, leading to qualifications of a novel system. Moreover, analysis is a comprehensive analysis and study of a variety of processes carried out by a system as well as their associations inside and outside the system. In software engineering, the system design is actually the 3rd step of the software development life cycle. In this step the analysis designs how the developed system will perform the intended task. The substantial parts of the system are explained at this point that describe how the current problem will be resolved. On the basis of the user requirements and the comprehensive system analysis of a new system, the new system has to be competently designed. This is the stage of system designing. Moreover, it is a very critical stage in the system development lifecycle (NOS, 2010), (Sommerville, 2004) and (Whitten et al., 2000). B- Aggregation and Composition constructs in UML Aggregation Aggregation is a special type of relationship that identifies a whole relationship between the aggregate (whole) and element (part) (Blundell, 1999). Composition Composition is type of aggregation with powerful rights and instantaneous lifetime as fraction of the whole. In this scenario, parts with permanent diversity can be produced after the composite itself, however once produced they exist and expire through it (for instance they distribute lifetimes). Moreover, such components can be openly eliminated before the loss of the composite. Furthermore, the composition can be persistent: (Blundell, 1999) Image Source: http://www.c-sharpcorner.com/uploadfile/pcurnow/compagg07272007062838am/compagg.aspx Image Source: http://www.c-sharpcorner.com/uploadfile/pcurnow/compagg07272007062838am/compagg.aspx C- Requirements Definition Requirements definition refers to the process of recognizing the customers’ needs using a particular tool or system and it is a very important phase in the software development life cycle paradigm. In scenario of system development the requirements are an explanation of how a system should perform or an explanation of application characteristics or features. On the other hand, it could be a declaration of ‘what’ a system is anticipated to perform. Moreover, specified the numerous stages of communication among users, business procedures and contrivances in worldwide businesses nowadays, there are concurrent and intricate needs from a distinct application, since a variety of levels inside a business as well as outside it also. Furthermore, the software requirements definition procedure deals with the composite job of extracting and documenting the requirements of all the system users, modeling and evaluating these requirements and documenting them as foundations of system design. In more simple words, a software requirement is a process of describing system requirements in a comprehensive way of the intended purpose as well as environment intended for software under development (Outsource2India, 2011), (TechTarget, 2007) and (Japenga, 2008). There are a lot of high-quality descriptions for system and software requirements specifications which offer us a high level basis on which we can be able to together describe an enormous arrangement and recognize deficiencies in our earlier efforts. Moreover, there also exists a lot of stuff on the web which can help us write high-quality specifications (Japenga, 2008). Requirements Elicitation Methods Interviewing An interview is a most commonly used way of collecting software requirements; it is a one-on-one gathering where the company market analysts inquire or ask questions to gather data and information from the system stakeholders. In addition, by using this technique we can be able to rapidly collect a lot of requirements from one individual. Though, we yet require inspecting those requirements to confirm they do not clash with new stakeholder requirements (IT-Career-Coach, 2010) and (Whitten et al., 2000). Questionnaires Questionnaires are also a very useful method for requirements gathering. Normally, it involves building a general questionnaire that can assess the overall system handling information from its users and other stakeholders. The basic purpose of questioners is to take a well managed response from the system users (IT-Career-Coach, 2010) and (Whitten et al., 2000). Observation Another requirements gathering technique in which a business analyst observes the clients carrying out their every day jobs and ask questions regarding the tasks and efforts they put to complete those tasks. However, this method gives us the benefit of perceiving what the users actually do when they use the system as compared to that what they inform us to do. In this scenario, observation helps the analyst build up an actual idea of the user’s on the work matters. However, a business analyst should possess outstanding expertise of selecting and utilizing the correct elicitation method for every circumstance (IT-Career-Coach, 2010) and (Whitten et al., 2000). Requirements Elicitation for WBF Ltd For WBF Ltd. we will get the main requirements from system stakeholders by using following major methods: Interviewing: We will collect all the possible requirements for the system development from the system users by arranging a meeting with them. The main purpose of this meeting would be to inquire about a number of working and system related questions from business personnel. In this way we will be able to assess their viewpoint regarding system practice. Questionnaires: For WBF Ltd system development we will also use questionnaires to collect system requirements. In this way we would be able to assess system working and operational requirements by analyzing system requirements as well as user actions against those queries. Observation: For collecting WBF Ltd system requirements we will observe and monitor the working and jobs of the people working at WBF Ltd. In this way we will be able to assess working and information needs by directly asking questions to staff members. References Ambler, S.W., 2010. UML 2 Use Case Diagrams. [Online] Available at: http://www.agilemodeling.com/artifacts/useCaseDiagram.htm [Accessed 08 March 2011]. Blundell, R., 1999. UML Relationships and Associations, Aggregation and Composition. [Online] Available at: http://accu.org/index.php/journals/551 [Accessed 10 March 2011]. Braun, D., Sivils, J., Shapiro, A. & Versteegh, J., 2010. Class Diagrams. [Online] Available at: http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/class.htm [Accessed 09 March 2011]. Braun, D., Sivils, J., Shapiro, A. & Versteegh, J., 2010. Interaction Diagrams. [Online] Available at: http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/interaction.htm [Accessed 09 March 2011]. Braun, D., Sivils, J., Shapiro, A. & Versteegh, J., 2011. Use Case Diagrams. [Online] Available at: http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/use_case.htm [Accessed 09 March 2011]. Chitnis, M., Tiwari, P. & Ananthamurthy, L., 2003. Creating Use Case Diagrams. [Online] Available at: http://www.developer.com/design/article.php/2109801/Creating-Use-Case-Diagrams.htm [Accessed 10 March 2011]. Heywood, R., 2011. UML Use Case Diagrams: Tips and FAQ. [Online] Available at: http://www.andrew.cmu.edu/course/90-754/umlucdfaq.html [Accessed 08 March 2011]. IT-Career-Coach, 2010. Learn Effective Requirements Elicitation Techniques. [Online] Available at: http://www.it-career-coach.net/2009/01/22/requirements-elicitation-techniques/ [Accessed 10 March 2011]. Japenga, R., 2008. How to write a software requirements specification. [Online] Available at: http://www.microtoolsinc.com/Howsrs.php [Accessed 10 March 2011]. NOS, 2010. Introduction to System Analysis and Design. [Online] Available at: http://www.nos.org/htm/sad1.htm [Accessed 08 March 2011]. Outsource2India, 2011. Requirements Analysis Process: Requirements Elicitation, Analysis And Specification. [Online] Available at: http://www.outsource2india.com/software/RequirementAnalysis.asp [Accessed 09 March 2011]. Pressman, R.S., 2001. Software Engineering: A Practicioner's Approach, 5th Edition. London: McGraw Hill. Sommerville, I., 2004. Software Engineering, 7th Edition. New York: Pearson Education (Addison Wesley). Stotts, D., 2009. Interaction Diagrams. [Online] Available at: http://www.cs.unc.edu/~stotts/145/CRC/Interactions.html [Accessed 10 March 2011]. TechTarget, 2007. software requirements specification (SRS). [Online] Available at: http://searchsoftwarequality.techtarget.com/definition/software-requirements-specification [Accessed 09 March 2011]. Whitten, J.L., Bentley, L.D. & Dittman, K.C., 2000. Systems Analysis and Design Methods 5th Edition. New York: Irwin/McGraw-Hill. Read More