Download System Design: Inputs, Outputs, and Documentation and more Assignments Design and Analysis of Algorithms in PDF only on Docsity!
SYSTEM ANALYSIS & DESIGN - SYSTEM DESIGN
The design phase decides how the new system will operate. Many activities will be involved as the development team develops the system requirements. This chapter provides an outline of those design phase activities, which culminates in the creation of the system specification. We also describe three alternative strategies for acquiring the system that are available to the development team.
TRANSITION FROM REQUIREMENTS TO DESIGN The purpose of the analysis phase is to figure out what the business needs. The purpose of the design phase is to decide how to build it. System design is the determination of the overall system architecture—consisting of a set of physical processing components, hardware, software, people, and the communication among them—that will satisfy the system’s essential requirements.1 During the initial part of design, the project team converts the business requirements for the system into system requirements that describe the technical details for building the system. Unlike business requirements, which are listed in the requirements definition and communicated through use cases and logical process and data models, system requirements are communicated through a collection of design documents and physical process and data models. Together, the design documents and physical models make up the blueprint for the new system. We should note here that our focus is on the design of the technical system blueprint that will satisfy the system’s requirements. An important element of the final, complete information system, however, will be redesigned work flows and procedures that users will follow when using the new system. Business analysts often turn their attention to the design of these components at this stage of the project, while systems analysts focus on more technical design elements. Ultimately, the redesigned business processes and procedures will be communicated in user documentation and training materials, which we discuss in Chapter 12. The design phase has a number of activities that lead to the system blueprint. (See Figure 7-1.) An important initial part of the design phase is the examination of several system acquisition
strategies to decide which will be used to meet the requirements of the system. Systems can be built from scratch, purchased and customized, or outsourced to others, and the project team needs to investigate the viability of each alternative. The decision to make, to buy, or to outsource influences the design tasks that are performed throughout the rest of the phase. The project team carefully considers the nonfunctional business requirements that were identified during analysis. The nonfunctional business requirements influence the system requirements that drive the design of the system’s architecture. Major considerations of the “how” of a system are operational, performance, security, cultural, and political in nature. For example, the project team needs to plan for the new system’s performance: how fast the system will operate, what its capacity should be, and its availability and reliability. The team needs to create a secure system by specifying access restrictions and by identifying the need for encryption, authentication,
It is the phase where the SRS document is converted into a format that can be implemented and decides how the system will operate.
In this phase, the complex activity of system development is divided into several smaller sub-activities, which coordinate with each other to achieve the main objective of system development.
Actual or pseudocode for each module in the program. A prototype for the proposed system.
Types of System Design
Logical Design Logical design pertains to an abstract representation of the data flow, inputs, and outputs of the system. It describes the inputs (sources), outputs (destinations), databases (data stores), procedures (data flows) all in a format that meets the user requirements.
While preparing the logical design of a system, the system analyst specifies the user needs at level of detail that virtually determines the information flow into and out of the system and the required data sources. Data flow diagram, E-R diagram modeling are used.
Physical Design Physical design relates to the actual input and output processes of the system. It focuses on how data is entered into a system, verified, processed, and displayed as output. It produces the working system by defining the design specification that specifies exactly what the candidate system does. It is concerned with user interface design, process design, and data design.
It consists of the following steps − Specifying the input/output media, designing the database, and specifying backup procedures. Planning system implementation. Devising a test and implementation plan, and specifying any new hardware and software. Updating costs, benefits, conversion dates, and system constraints.
Architectural Design It is also known as high level design that focuses on the design of system architecture. It describes the structure and behavior of the system. It defines the structure and relationship between various modules of system development process.
Detailed Design It follows Architectural design and focuses on development of each module.
Conceptual Data Modeling It is representation of organizational data which includes all the major entities and relationship. System analysts develop a conceptual data model for the current system that supports the scope and requirement for the proposed system.
The main aim of conceptual data modeling is to capture as much meaning of data as possible. Most organization today use conceptual data modeling using E-R model which uses special notation to represent as much meaning about data as possible.
Entity Relationship Model It is a technique used in database design that helps describe the relationship between various entities of an organization.
Terms used in E-R model ENTITY − It specifies distinct real world items in an application. For example: vendor, item, student, course, teachers, etc. RELATIONSHIP − They are the meaningful dependencies between entities. For example, vendor supplies items, teacher teaches courses, and then supplies and course are relationship. ATTRIBUTES − It specifies the properties of relationships. For example, vendor code, student name.
Derived Attributes
Total Participation of E2 in R
Cardinality Ratio 1:N for E1:E2 in R
Three types of relationships can exist between two sets of data: one-to-one, one-to-many, and many-to-many.
File Organization It describes how records are stored within a file. There are four file organization methods Serial − Records are stored in chronological order (in order as they are input or occur). Examples − Recording of telephone charges, ATM transactions, Telephone queues. Sequential − Records are stored in order based on a key field which contains a value that uniquely identifies a record. Examples − Phone directories. Direct (relative) − Each record is stored based on a physical address or location on the device. Address is calculated from the value stored in the record’s key field. Randomizing routine or hashing algorithm does the conversion. Indexed − Records can be processed both sequentially and non-sequentially using indexes.
Comparison
File Access One can access a file using either Sequential Access or Random Access. File Access methods allow computer programs read or write records in a file.
Sequential Access Every record on the file is processed starting with the first record until End of File (EOF) is reached. It is efficient when a large number of the records on the file need to be accessed at any given time. Data stored on a tape (sequential access) can be accessed only sequentially.
Direct (Random) Access Records are located by knowing their physical locations or addresses on the device rather than their positions relative to other records. Data stored on a CD device (direct-access) can be accessed either sequentially or randomly.
Types of Files used in an Organization System
the system. In large companies, a technical support team that includes technical writers might assist in the preparation of user documentation and training materials.
Advantages It can reduce system downtime, cut costs, and speed up maintenance tasks. It provides the clear description of formal flow of present system and helps to understand the type of input data and how the output can be produced. It provides effective and efficient way of communication between technical and nontechnical users about system. It facilitates the training of new user so that he can easily understand the flow of system. It helps the user to solve the problems such as troubleshooting and helps the manager to take better final decisions of the organization system. It provides better control to the internal or external working of the system.
Types of Documentations When it comes to System Design, there are following four main documentations − Program documentation System documentation Operations documentation User documentation
Program Documentation It describes inputs, outputs, and processing logic for all the program modules. The program documentation process starts in the system analysis phase and continues during implementation. This documentation guides programmers, who construct modules that are well supported by internal and external comments and descriptions that can be understood and maintained easily.
Operations Documentation Operations documentation contains all the information needed for processing and distributing online and printed output. Operations documentation should be clear, concise, and available online if possible.
It includes the following information − Program, systems analyst, programmer, and system identification. Scheduling information for printed output, such as report, execution frequency, and deadlines. Input files, their source, output files, and their destinations. E-mail and report distribution lists. Special forms required, including online forms. Error and informational messages to operators and restart procedures. Special instructions, such as security requirements.
User Documentation It includes instructions and information to the users who will interact with the system. For example, user manuals, help guides, and tutorials. User documentation is valuable in training users and for reference purpose. It must be clear, understandable, and readily accessible to users at all levels.
The users, system owners, analysts, and programmers, all put combined efforts to develop a user’s guide.
A user documentation should include
During systems implementation, an analyst must review system documentation to verify that it is complete, accurate, and up-to-date, and including any changes made during the implementation process.
Design Strategies
Top-Down Strategy The top-down strategy uses the modular approach to develop the design of a system. It is called so because it starts from the top or the highest-level module and moves towards the lowest level modules.
In this technique, the highest-level module or main module for developing the software is identified. The main module is divided into several smaller and simpler submodules or segments based on the task performed by each module. Then, each submodule is further subdivided into several submodules of next lower level. This process of dividing each module into several submodules continues until the lowest level modules, which cannot be further subdivided, are not identified.
Bottom-Up Strategy Bottom-Up Strategy follows the modular approach to develop the design of the system. It is called so because it starts from the bottom or the most basic level modules and moves towards the highest level modules.
In this technique, The modules at the most basic or the lowest level are identified. These modules are then grouped together based on the function performed by each module to form the next higher-level modules. Then, these modules are further combined to form the next higher-level modules. This process of grouping several simpler modules to form higher level modules continues until the main module of system development process is achieved.
Structured Design Structured design is a data-flow based methodology that helps in identifying the input and output of the developing system. The main objective of structured design is to minimize the complexity and increase the modularity of a program. Structured design also helps in describing the functional aspects of the system. In structured designing, the system specifications act as a basis for graphically representing the flow of data and sequence of processes involved in a software development with the help of DFDs. After developing the DFDs for the software system, the next step is to develop the structure chart.
Control Module − It is a higher-level module that directs lower-level modules, called subordinate modules. Library Module − It is a reusable module and can be invoked from more than one point in the chart.
We have two different approaches to design a structured chart − Transform-Centered Structured Charts − They are used when all the transactions follow same path. Transaction–Centered Structured Charts − They are used when all the transactions do not follow the same path. Objectives of Using Structure Flowcharts To encourage a top-down design. To support the concept of modules and identify the appropriate modules. To show the size and complexity of the system. To identify the number of readily identifiable functions and modules within each function. To depict whether each identifiable function is a manageable entity or should be broken down into smaller components. Factors Affecting System Complexity To develop good quality of system software, it is necessary to develop a good design. Therefore, the main focus on while developing the design of the system is the quality of the
software design. A good quality software design is the one, which minimizes the complexity and cost expenditure in software development. The two important concepts related to the system development that help in determining the complexity of a system are coupling and cohesion. Coupling Coupling is the measure of the independence of components. It defines the degree of dependency of each module of system development on the other. In practice, this means the stronger the coupling between the modules in a system, the more difficult it is to implement and maintain the system. Each module should have simple, clean interface with other modules, and that the minimum number of data elements should be shared between modules. High Coupling These type of systems have interconnections with program units dependent on each other. Changes to one subsystem leads to high impact on the other subsystem.
Low Coupling These type of systems are made up of components which are independent or almost independent. A change in one subsystem does not affect any other subsystem.
The worst degree of cohesion Coincidental cohesion is found in a component whose parts are unrelated to another. Logical Cohesion − It is where several logically related functions or data elements are placed in same component. Temporal Cohesion − It is when a component that is used to initialize a system or set variables performs several functions in sequence, but the functions are related by timing involved. Procedurally Cohesion − It is when functions are grouped together in a component just to ensure this order. Sequential Cohesion − It is when the output from one part of a component is the input to the next part of it. Input / Output & Forms Design
Input Design In an information system, input is the raw data that is processed to produce output. During the input design, the developers must consider the input devices such as PC, MICR, OMR, etc. Therefore, the quality of system input determines the quality of system output. Welldesigned input forms and screens have following properties − It should serve specific purpose effectively such as storing, recording, and retrieving the information. It ensures proper completion with accuracy. It should be easy to fill and straightforward. It should focus on user’s attention, consistency, and simplicity. All these objectives are obtained using the knowledge of basic design principles regarding − o What are the inputs needed for the system? o How end users respond to different elements of forms and screens. Objectives for Input Design
The objectives of input design are − To design data entry and input procedures To reduce input volume To design source documents for data capture or devise other data capture methods To design input data records, data entry screens, user interface screens, etc. To use validation checks and develop effective input controls. Data Input Methods It is important to design appropriate data input methods to prevent errors while entering data. These methods depend on whether the data is entered by customers in forms manually and later entered by data entry operators, or data is directly entered by users on the PCs. A system should prevent user from making mistakes by − Clear form design by leaving enough space for writing legibly. Clear instructions to fill form. Clear form design. Reducing key strokes. Immediate error feedback. Some of the popular data input methods are − Batch input method (Offline data input method) Online data input method Computer readable forms Interactive data input Input Integrity Controls Input integrity controls include a number of methods to eliminate common input errors by end-users. They also include checks on the value of individual fields; both for format and the completeness of all inputs. Audit trails for data entry and other system operations are created using transaction logs which gives a record of all changes introduced in the database to provide security and means of recovery in case of any failure.
