Software Development Lifecycle - Essay Example

SYSTEM SPECIFICATION DOCUMENT Name of Student Institution System Analysis System analysis entails the study of varies sets and entities of a software system and all the requirements the system should meet (functional and non-functional requirements). A requirement analysis of the system should be carried during this phase, and a requirement specification document produced. Apart from documentation, the requirements should also be; testable, actionable, measurable and traceable. Upon the gathering of the database requirements, interviews and questionnaires were the methods I adapted. Interviews were my most preferable means of gathering the system requirements. I adapted only two interview techniques which were; the face-to-face technique and telephone interviews. Among the advantages of these techniques were. For the face to face interviews, both the interviewee and I were more spontaneous on the response from the other. The interviewees did not deliberate too long in their response. I had the ability to clarify questions I’d asked. The one-on-one experience gave me the ability to analyze abstract aspects. I was able to collect more detailed information as interviews offer an in-depth analysis. I had the advantage of flexibility on both the questions I had, and additional questions I could use or alter to gather more information. I recorded the conversations on audio tapes for further review upon my requirement analysis phase (Weller & Rommey 2001). I was able to conduct a few telephone interviews and, all had similar though, limited advantages as the face to face. They are efficient for in-depth analysis during interviews. They offer an age on the interviewer and reduce cases of biasness. They were efficient at time as I did not have to commute up and down. I also recorded (audio) conversations for further references and reviews (Weller & Rommey 2001). The downside of the interviews I conducted based on the techniques was that; they were time-consuming. I only had to interview a person at a time. I could not ask personal questions relating the Olympic or to the individuals as the interviewees were reluctant to respond to them. In some interviews, I felt I was inefficient enough to achieve my objectives from them. In the end, I was unsatisfied with the results. The interviews were time consuming and ultimately not suitable for personal questions. In an effort to reduce the above confines, sample questioners to summarize the interviews could have been issued to the interviewees and relevant personnel of the London Olympic Games Organizing Committee (LOGOC). The use of numerous interviewers to ease the work burden and save time on the data gathering phase of the requirement analysis is also advised. System Design This is a process that entails the definition of the modules, the architecture, the interfaces, the components and data of a given system. The design should conform to the requirements of the expected system. The expected outputs of the system shall be both soft and hard copy (screen display and printouts respectively). As for the displays and screen output, the output specifications were; user interface for the application (GUI). The forms designed to act as both input and output interfaces. There were reports to be generated that were to be displayed on the stadiums screens. These reports were the; events timetable, score and leaderboard information, categories and venue of sports within the stadium. Also, the forms were to act as source of information for the commentators for the event. As for the hardcopy printouts, there were registrations forms for the athletes, list of athletes per their participated games. Recordings and standings of games and activities are to be printed and issued to people of interest (the London Olympic Games Organizing Committee personnel) as well as spectators for the events. Registration forms for potential athletes were also in hardcopy form and issued to participants for registration purposes. Labels for the event are to be printed based on each event and used to publicize the event. As for the input specification of the system, forms are to be designed based on the database tables created. The forms were to be the interface for the input design for the system. The forms designed were; FRM QryathleteEvent, FRM Qry Male Athletes, FRM QryMale Atheletes, FRMathlete ID, FRMCompetitions, FRMEvents and Switch board. These mention forms are to be designed to manipulate (input/update/query/delete) from the tables; Athletic ID, Competitions, Events, Switchboard Items. The validation techniques to be adapted by the system shall include unique (primary key) fields. Each registered athlete shall have a unique identification number (athlete ID). This number is be used to identify each athlete and their registered events. Scheduling of the events shall be based on the number of participants and their availability in case the athletes have numerous events to participate. The system shall also be designed to prevent mischievous entries to events by athletes. System Review This is assessment and evaluation of the system before deployment. Numerous tests and assessments are conducted by the developer and some end users to check of numerous aspects of the developed system (Shelly & Rosenblatt, 2012). The final system was able to achieve its desired functional requirements. From the functional requirement specification document, that was as a deliverable for the requirement analysis phase it is used in the design. The system was to be able to store athletes’ details and, the numerous events they will be will be participating. Thus, the developed system has a list of tables to store this information. Forms that shall act as the input interface to the tables designed. The forms are clearly labeled and, have some validation checks upon writing to the tables. I also conducted additional system tests on the application. The tests carried were; functional and non-functional testing. The functional tests objectives were to verify the functions and actions of the application. As for the non-functional tests, they were to cover aspects of the system that aren’t related to either user actions or functions. These aspects can be; scalability of the application, general performance, the capability for the system to perform under numerous constrains and security aspects of the system. Lastly I carried out a usability testing to check on the ease (usability) of the system. This entailed checking the user interface and its ease of access and use by new individuals to the system. The input forms are designed in a simple and a readability way to ease usability. This was achieved by use of clearly visible labels alongside input boxes. They were clearly spaced to avoid any congestions and confusion when inputting data (Sloss, Symes & Wright 2004). Ultimately I am certain that I met the functional requirements of the London Olympic Games Organising Committee (LOGOC) system. In addition to that, I included some additional non-functional requirements to the system to improve and utilize its efficiency and usability. References Shelly, G. B., & Rosenblatt, H. J. (2012). Systems analysis and design. Boston: Course Technology Cengage Learning. Sloss, A. N., Symes, D., & Wright, C. (2004). ARM system developer's guide: Designing and optimizing system software. San Francisco, CA: Elsevier/ Morgan Kaufman. Weller, S. C., & Romney, A. K. (2001). Systematic data collection. Newbury Park, Calif: Sage Publications. Read More