The document discusses requirements for developing an activity management system. It states that requirements should specify what the system needs to do, not how it will be done. True requirements include features that are mandatory or optional, performance specifications, and protocols for interacting with other systems. The document notes that existing problem statements often mix requirements with design decisions, and the analyst must separate these and challenge pseudo-requirements. It then provides an overview of the existing manual system, the proposed new automated system, advantages of the new system, module descriptions, and a feasibility analysis.
The document discusses requirements for developing an activity management system. It states that requirements should specify what the system needs to do, not how it will be done. True requirements include features that are mandatory or optional, performance specifications, and protocols for interacting with other systems. The document notes that existing problem statements often mix requirements with design decisions, and the analyst must separate these and challenge pseudo-requirements. It then provides an overview of the existing manual system, the proposed new automated system, advantages of the new system, module descriptions, and a feasibility analysis.
The document discusses requirements for developing an activity management system. It states that requirements should specify what the system needs to do, not how it will be done. True requirements include features that are mandatory or optional, performance specifications, and protocols for interacting with other systems. The document notes that existing problem statements often mix requirements with design decisions, and the analyst must separate these and challenge pseudo-requirements. It then provides an overview of the existing manual system, the proposed new automated system, advantages of the new system, module descriptions, and a feasibility analysis.
The document discusses requirements for developing an activity management system. It states that requirements should specify what the system needs to do, not how it will be done. True requirements include features that are mandatory or optional, performance specifications, and protocols for interacting with other systems. The document notes that existing problem statements often mix requirements with design decisions, and the analyst must separate these and challenge pseudo-requirements. It then provides an overview of the existing manual system, the proposed new automated system, advantages of the new system, module descriptions, and a feasibility analysis.
Download as DOCX, PDF, TXT or read online from Scribd
Download as docx, pdf, or txt
You are on page 1/ 6
Activity Management System
SYSTEM ANALYSIS The first step in developing anything is to state the requirements. This applies just as much to leading edge research as to simple programs and to personal programs, as well as to large team efforts. Being vague about your objective only postpones decisions to a later stage where changes are much more costly.
The problem statement should state what is to be done and not how it is to be done. It should be a statement of needs, not a proposal for a solution. A user manual for the desired system is a good problem statement. The requestor should indicate which features are mandatory and which are optional, to avoid overly constraining design decisions. The requestor should avoid describing system internals, as this restricts implementation flexibility. Performance specifications and protocols for interaction with external systems are legitimate requirements. Software engineering standards, such as modular construction, design for testability, and provision for future extensions, are also proper. , you need a system which not only tracks the information, the performance parameters of each of the people, but should also be robust, scalable, secure and user-friendly. Many problems statements, from individuals, companies, and government agencies, mixture requirements with design decisions. There may sometimes be a compelling reason to require a particular computer or language; there is rarely justification to specify the use of a particular algorithm. The analyst must separate the true requirements from design and implementation decisions disguised as requirements .The analyst should challenge such pseudo requirements, as they restrict flexibility. There may be politics or organizational reasons for the pseudo requirements, but at least the analyst should recognize that these externally imposed design decisions are not essential features of the problem domain. A problem statement may have more or less detail. A requirement for a conventional product, such as a payroll program or a billing system, may have considerable detail. A requirement for a research effort in a new area may lack many details, but presumably the research has some objective, which should be clearly stated.
Most problem statements are ambiguous, incomplete, or even
inconsistent. Some requirements are just plain wrong. Some requirements, although precisely stated have unpleasant consequences on the system behavior or impose unreasonable implementation costs. Some requirements seem reasonable at first but do not work out as well as the request or thought. The problem statement is just a starting point for understanding the problem, not an immutable document. The purpose of the subsequent analysis is to fully understand the problem and its implications. There is no reason to expect that a problem statement prepared without a fully analysis will be correct.
The analyst must work with the requestor to refine the requirements so they represent the requestors true intent. This involves challenging the requirements and probing for missing information. The psychological, organizational, and political considerations of doing this are beyond the scope of this book, except for the following piece of advice: If you do exactly what the customer asked for, but the result does not meet the customers real needs, you will probably be blamed anyway. Existing System This system is manual system only. Here, have a facility to store the insurance record. If you want to compare the insurance images with the existing images it is manual process. This process is very slow to give the result. It is very critical to find the insurance company record. Proposed System To overcome the drawbacks that were in the existing system we develop a system that will be very useful for any investigation department. Here the program keeps track of the record number of each slice during the construction of identifiable insurance company record and calculate maximum number of slices of the similar record number. Based on this record number the program retrieves the personal record of the suspect (whose slice constituted the major parts of the constructed company record) on exercising the locate option.
ADVANTAGE
The specifications were more on the conceptual side.
Provided product design support where basic requirements were understood and analyzed, workflow and features were brainstormed to come to the best possible design and implementation after elaborate discussions with the client. Communication and co- ordination with the client was the key to decision making on the feature details.
Working with , the client continues to benefit from
excellent talent a and reduced overall cost for the software product development along with growth in their business. * Future Relationship established a strong relationship with the client firm, having been involved in another project in evaluation system in same technology. This is already into development of the second version of the systems, which have many new features implemented. *Business owners can keep track of customer projects and manage them by creating tasks and assigning them to employees. They can also add specifications and documents to the projects.
*Another key feature is the ability to evaluate employees. Our AMR can write reports for each employee. These reports give information about average work time, average task time, deadline tracking, break times and detailed information of each particular task they have worked on.
Business owners can also keep track and schedule time off for employees
MODULE DESCRIPTION
Well structured designs improve the maintainability of a system.
A structured system is one that is developed from the top down and modular, that is, broken down into manageable components. In this project we modularized the system so that they have minimal effect on each other. This application is designed into five independent modules which take care of different tasks efficiently 1. USER INTERFACE MODULE 2. ADMIN MODULES 3. CLIENT MODULES FEASIBILITY REPORT
Feasibility Study feasibility study is a high-level capsule version of
the entire System analysis and Design Process. The study begins by classifying the problem definition. Feasibility is to determine if its worth doing. Once an acceptance problem definition has been generated, the analyst develops a logical model of the system. A search for alternatives is analyzed carefully. There are 3 parts in feasibility study. Operational Feasibility: Question that going to be asked are Will the system be used if it developed and implemented. If there was sufficient support for the project from the management and from the users. Have the users been involved in planning and development of the Project. Will the system produce poorer result in any respect or area ? This system can be implemented in the organization because there is adequate support from management and users. Being developed in PHP so that the necessary operations are carried out automatically .Technical feasibility: Does the necessary technology exist to do what is been suggested Does the proposed equipment have the technical capacity for using the new system? Are there technical guarantees of accuracy, reliability and data security? The project is developed on Pentium IV with 256 MB RAM. The environment required in the development of system is any windows platform . The observer pattern along with factory pattern will update the results eventually .The language used in the development is PHP & Windows Environment Financial and Economical Feasibility: The system developed and installed will be good benefit to the organization. The System will be developed and operated in the existing hardware and software infrastructure. So there is no need of additional hardware and software for the system.
