Systems Analysis
Systems are unified components working synchronously to achieve an objective (Whitten & Bentley, 2007, p. 6). Systems analysts work with stakeholders to identify business problems, needs, and opportunities to determine the best way information technology, data, processes, and people can help to achieve objectives (Whitten & Bentley, 2007, p. 11). Effective systems analysis requires methodical application of a variety of technical competencies, interpersonal skills, and business understanding to understand and solve complex issues. System analysis involves a combination of creative and analytical component inspection of intricate structures to distinguish underlying patterns and interactions.
Systems Scope
System scope delves into the problems, opportunities, and directives associated with a proposed systems analysis and design. Problem statements specify all system requirements clearly, along with the benefits and possible solutions if modified. Each problem is prioritized by urgency and visibility as seen in Table 2 (Whitten & Bentley, 2007, pp. 170–173). Problem statements are used to negotiate baseline scope boundaries like data types, processes, and interface expectations. After scope details have been defined and negotiated, the project must be validated. If analysis proves to be a worthy undertaking, schedule and project plans are established.
Table 2
Problem Statement Form Example
System Business Roles
The problem statement is an excellent template for evaluating business roles in a system. Functional decomposition diagrams break the system into different components based on user requirements, as seen in Figure 16. The top level should identify the system. Subsystems branch down based on functions, from which the various processes branch. The processes are then used to develop use case narratives, which identify the business events, associated actor, and their intended relationship with each process. Appendix E is an example of a use case narrative layout used in system design projects (Whitten & Bentley, 2007, pp. 259–260). Each process requires a use case narrative to detail the specific requirements, users, and objectives for system processes.
Figure 16
Decomposition Diagram
System Process Modeling
All systems should deliver value to a client. Values are associated with the underlying business processes in which the system is designed to facilitate or improve. Modeling systems processes enables collaboration between system designers and stakeholders to clarify project requirements. Data flow diagrams translate scope objectives into actionable elements with simplicity. Basic elements of data flow diagrams can be seen in Figure 17. Detailing how users communicate with the system to perform the process related to system functions is an essential for effective design. When a user initiates an action with the system, they use data inform the system which process is to be performed. Depending on the process selected, information will flow into data stores, like when an update to information is needed, or the data stores will send data back. If data is retrieved for the purposes of a report, for example, the information moves from data stores back into the rounded process square, where it then is relayed to the user. Each part within the event is connected by the flow of data, which are the lines with arrows. The direction of the arrow indicates the path from one part of the event, into the next part. The data flow lines are labeled to indicate the data carried in the flow. To provide better clarity of the way data will flow, the subsystems should be visually distinct as in Figure 18.
Figure 17
Basic Data Flow Diagram
Figure 18
Data Flow Diagrams by Subsystem
System Diagrams
Visualizing system requirement through diagramming serves as a communication bridge between key stakeholders and designers. Figure 19 is a high-level activity diagram, which combines use cases and data flow diagrams to illustrate interactions between actors and the proposed system. Swim lanes are used to differentiate the actor from system responses and communication activities are indicated by lines. Rounded rectangle boxes indicate the actions, while diamonds note any point where a decision must be made (Whitten & Bentley, 2007, p. 390).
Figure 19
High-level Activity Diagram
ERD
With activity for processes clarified, a designer will begin developing diagrams modeling entity relationships (ERD). As seen in Figure 21, ERD entities are indicated by a box containing name and associated attributes. Primary and foreign attributes help systems uniquely identify the entity and are located on the left side of the entity box. Non-identifying attributes are located on the right side of the entity box. Relationships are the lines between each entity box. Where most prior diagrams indicate interactions by a line with an arrow indicating direction, ERD notation specifies degree of each relationship, as seen in Figure 20.
Figure 20
ERD Key
Logical ERD
Diagramming entities and relationships is most helpful when done in iterations increasing in detail at each phase. For instance, Figure 21 is a fully attributed logical system ERD. Entities names and attributes are noted in pseudocode to clarify entity roles and responsibilities. This has the advantage of outlining the proposed system in a way that business users without database knowledge can easily understand.
Figure 21
Logical ERD
Physical ERD
The functional requirements from a logical ERD provide a blueprint for the physical design ERD. The physical system design ERD goes into greater detail by including database appropriate naming schemes and data types necessary for each attribute, as seen in Figure 22.
Figure 22
Physical Design Perspective
Systems Design Methodologies
Approaches and methods to every aspect of technology vary as time passes and industry values are adopted or fall out of favor. Inevitably, new acronyms are developed, steps are outlined, and proponents praise the newest way of doing old things. In system analysis and design, one thing is absolutely clear, an underlying structure improves outcomes. Keeping that in mind, system analysts should be knowledgeable about a variety of different approaches in order to select the best framework to achieve project objectives. Most system development methods utilize common underlying principles, as seen in Figure 23 (Whitten & Bentley, 2007, pp. 70–76).
Figure 23
Design Principles
System Development Strategy
Systems construction is the development, installation, and testing of the environment in which the system will operate (Whitten & Bentley, 2007, pp. 684–688). During the initial systems design phases, existing infrastructure is examined to ensure new development compatibility. The designer works with network administration to modify system design where necessary. Databases are then built and tested to verify design meets business requirements. User testing and feedback is useful, as design modification to increase acceptance is easiest before deployment. If the system requires new software or programs, they should be written or installed, then tested to verify compatibility with existing infrastructure (Whitten & Bentley, 2007, pp. 686–688).
Systems implementation begins additional testing of all software and programs with the newly designed system. After successfully testing the new system, design specifications are used to determine optimum conversion strategy. Common strategies for transition include: abrupt cut-over, parallel conversion, location conversion, and staged conversion (Whitten & Bentley, 2007, p. 691). User acceptance and audit testing using the chosen conversion strategy and real data is conducted to address any remaining barriers prior to operationalizing the system. The next step is to install and populate system databases with necessary data. Training materials and system documentation are used to instruct end users how to operate the new system. Once the conversion has been successfully completed, designers transfer ownership to those responsible for supporting and maintaining the system (Whitten & Bentley, 2007, pp. 691–694).