4.1 Systems Analysis and Design for Application Development

Systems Analysis and Design

The stepwise process for evaluating and developing information systems by understanding the needs of the business to improve or develop effective and efficient functioning solutions to technical challenges is called systems analysis and design. You may recall from Chapter 1 Fundamentals of Information Systems that information systems combine the people, processes, data, hardware, and software needed to collect, store, process, analyze, and distribute data. Examples of information systems include order processing, inventory control, human resource management, and sales management systems. Consider one information system you have probably encountered already: a prescription order process linking a prescribing doctor to a pharmacy. In Figure 4.2, you can view the workflow of a prescription request traveling from the prescriber through an electronic health record system toward the pharmacy staff and its system. In this scenario, there is an intermediate interaction with an e-prescription vendor’s system that is designed to translate and process that request so the receiving pharmacy staff can satisfy the doctor’s request for a patient’s medication.

Figure 4.2 The prescription order process involves several systematic steps beginning with the prescriber sending a patient’s medicine order to an electronic health record database, which forwards it to a vendor, who then routes the order to a pharmacy’s internal system and staff, who finally provide the medicine to the customer. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license; credit capsule: modification of work “Pill – The Noun Project” by Noelia Bravo/Wikimedia Commons, CC0 1.0; credit hospital sign: modification of work “Ic local hospital” by Google Inc./Wikimedia Commons, CC BY 4.0)

Who would think there were so many steps involved with picking up a prescription from a local pharmacy? Starting at the doctor’s office, the physician submits a prescription order through an online ordering system to the patient’s preferred pharmacy. The pharmacy, upon receipt of the prescription order, processes the prescription accordingly by validating patient information such as insurance, reviewing the aspects of the order, preparing the medication, and conducting a final review before providing the patient with the medication and instructions for use. There are many systems at work in this scenario—systems that connect users (i.e., medical and pharmacy staff), hardware (i.e., computer, keyboard, central processing unit or CPU, and wireless routers), software (electronic health record or EHR, ePrescribe software, and pharmacy benefit management tools), and other devices, working together to provide services.

Businesses initiate systems analysis and design to assess workflows, identify improvements, and create efficient systems. Some companies have formal processes with a task force led by a senior manager, while others approach systems analysis and design on an ad hoc basis. Organizations may prioritize projects using various criteria, tools, techniques, and input from multiple departments in order to align projects with business objectives. These initiatives often lead to systems analysis that can inform future design changes.

Systems Analysis

The process called systems analysis identifies the opportunities that can be discovered by examining business problems and develops possible solutions an organization may implement to address these problems. Systems analysis generally involves the following three activities: understanding the current business problem; determining the system requirements, constraints, and information needs; and generating a systems analysis report (Figure 4.3).

Figure 4.3 Understanding the current business problem; determining system requirements, constraints, and information needs; and generating a systems analysis report are the three basic components of systems analysis. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license; credit left: modification of work “Noun Planning 1325509” by Arafat Uddin/Wikimedia Commons, CC BY 4.0; credit middle: modification of work “Noun Project problems icon 2417098” by Template, TH/Wikimedia Commons, CC BY 3.0; credit right: modification of work “Noun project - Meeting with laptops” by Slava Strizh/Wikimedia Commons, CC BY 3.0)

Understanding the Current Business Problem

In defining the business problem, detailed information about the information system is gathered and analyzed using a variety of tools and techniques. To understand the business problem, the systems analyst first identifies stakeholders. A stakeholder is an individual or group who has a vested interest in or concern about a business decision. They may be internal or external to an organization and may include the community, government entities, employees, customers, investors, suppliers, or trade unions and associations. After identifying the stakeholders, the systems analyst begins the task of gathering information about the system to gain a better understanding of its functionalities and any challenges it currently faces. This information may include the purpose of the system, inputs and outputs, functional capabilities, number of users and levels of access, ease of use, accessibility, and challenges associated with its use.

Common methods used to gather this information or data include:

• System documentation review: The system documentation describes the system and its parts. It is used to understand how the system functions as well as serving as reference information. It may include requirements documentation, user guides, source code, architecture and design descriptions, and frequently asked questions (FAQs). By examining system documentation, the analyst may uncover how the system was originally designed to perform and changes made to the system since its initial use within the organization. The analyst may find that existing documentation may not be current, accurate, and/or complete. In that case, the analyst can work to revise and update the documentation for currency, accuracy, and completeness. Information-gathering may also involve examining policy documents and regulatory rules shaping the needs of the system.
• Surveys: A survey is a common form of information gathering. It allows larger groups of users to respond to an inquiry about a system so they can provide insight into its use. Surveys are usually affordable to administer, take minimal time, and can involve a variety of stakeholders across the organization.
• Interviews: The systems analyst may conduct interviews of different systems users and roles. To prepare for these interviews, the analyst will identify the objectives for the interview, generate and administer interview questions, document the results, and evaluate interview responses. Interviews may be structured (i.e., use the same interview questions and methods) or unstructured (i.e., involve no set format or predetermined questions). Interviews may take longer than other methods of information gathering but are useful in gaining insights that may not present themselves in surveys.
• Observations: Making observations about an information system generally involves noting how users perform their functions through and in relation to the system and, in turn, how the system responds. Observations may be passive (e.g., watching users perform actions without interference or influence) or active (e.g., engaging with users and asking questions about the activities they perform). Web analytics or metrics may be used as a gauge of observations made. Inputs and outputs of the system are observed and then documented for further review and analysis.
• Data analysis: Once the system documentation is collected, it is systematically reviewed, cleansed, sorted, and condensed so that conclusions and insights can be drawn to help solve business problems. Generally utilizing qualitative and/or quantitative/statistical analysis techniques, data analysis can be an iterative process where the team may need to refine the data gathering process to gain a further understanding of the data presented.

Determining System Requirements, Constraints, and Information Needs

System requirements are the capabilities stakeholders request to make a functioning system that supports their business needs. They can be categorized as functional, nonfunctional, business, technical, legal/regulatory, and/or performance related. Generally, the systems analyst will collaborate with stakeholders to gather these requirements. Once collected and defined, requirements are then placed in categories and prioritized based on criteria important to the business. As you will learn in 4.3 Technical Design Methodologies and Practical Applications, systems analysts may go further and develop user interface designs that give a representation of how system requirements interact with the data rules and roles and even the constraints of the system functionality.

Access to system data about usage and functionality of the system is a key component to the user requirements. Reporting functionality that provides usage data at both the macro and micro levels can be helpful to assess both the system and the users of the system. One example of how system data serve as a key component of user requirements can be found in customer service call histories at data centers. Data about the details of a call (i.e., length, representative, day/time, reason for calling, resolution status) are usable for a variety of business purposes, including training, service improvements, and employee recognition. For example, the day and time associated with a call can point to a number of issues such as bandwidth availability or system processing issues, and this information can lead to changes in end-user training, needed system improvements, or identification of a group-specific issue. These system/user requirements and all supporting information are then reviewed, evaluated, and finalized with input from stakeholder users.

Ethics in IS

Values-Based Engineering

Today, algorithms and artificial intelligence are driving the techniques used for systems analysis, design, and development. This can lead to ethical concerns, eroding user trust. For example, a 2023 study revealed that Google’s job search tools returned more higher-paying positions to men rather than job seekers of other gender identities. In addition, job applicant tracking systems are often found to favor words in résumés more closely associated with men.¹ These systems have also placed nonnative speakers at a lower rank because of inherent bias from AI training on only one specific language.

The process of values-based engineering (VbE) helps to address these challenges within the approaches to analysis, design, and development. This is accomplished by defining, prioritizing, addressing, and integrating values into the requirements process. VbE is applicable to both functional and nonfunctional requirements through tools, standards, and best practice guidelines.

Generating a Systems Analysis Report

The systems analyst typically provides interim feedback to stakeholders throughout the process, and the final step involves generating a systems analysis report. This report is likely to include recommended solutions to address or resolve the information system problem, and these solutions may take the form of changes in business processes, including systems improvements, elimination, or changes.

Link to Learning

A systems analysis report often takes the form of a feasibility study. Review this example of a feasibility study template that might be shared with stakeholders. It also features a survey asking shareholders to assess the viability of a proposed project.

Tools in Systems Analysis and Design

Several tools play a part in systems analysis and design. Several of the most common are data dictionaries, simulations, pseudocode, structured English, and unified modeling language. A data dictionary is a database that houses the details of system data, its properties, entity relationships, and any reference documentation. A simulation is a model that mimics the operation of an improved or proposed system. The plain English steps for an algorithm or other system that cannot be used in a compiler are called pseudocode, and structured English is a sequence of decision rules that uses the English language with the syntax of structured programming and the convention of IF-THEN-ELSE. Another tool that can be used to lay out the blueprint at various levels in a system is a simplified modeling language called unified modeling language (UML).

These tools are useful in creating diagrams of various system functions and relationships to gain deeper understanding during systems analysis. A data flow diagram (DFD) is a graphical representation of the information flow of a process or system. Another helpful diagram type is a UML diagram, which can show lower-level user interactions with the system as well as a high-level overviews of several activities working together in the system. A UML diagram represents a broad category of tools that are commonly used in systems analysis and design. These diagrams outline how a system will function from a user’s perspective, and they feature use cases, sequence diagrams, activity diagrams, state diagrams, and class diagrams.

• Use cases: A use case describes those individuals who will use and interact with the system. In the scenario from Figure 4.2 of getting a prescription filled, the use case would map out how each user (the patient, the doctor, the pharmacy, the insurance company) interacts in the system. UML diagrams can also be accompanied by a written use case, which includes details about the interaction of the users with the system rather than simply a visual representation.
• Sequence diagrams: A sequence diagram is used to illustrate a particular part of the system, not the entire system. They are specifically used when parts of the system must work in a certain order (Figure 4.4). Returning to the sample scenario, for the patient to eventually pick up their prescription, a doctor must first write that prescription and send that information to the pharmacy. Those system actions have to occur in that order. A patient cannot go to the pharmacy and get their medication prior to the prescription order coming from the doctor. The sequence diagram provides a general overview of the sequential process in the system.
• Activity diagrams: An activity diagram is used to represent how several use cases are coordinated together in a system. They are used to visualize more complex activities in the overall system (Figure 4.5).
• State diagrams: A state diagram is similar to an activity diagram; however, it is used to visualize behavior in a system based on the state the system is in. For example, the prescription ordering system might behave differently if the medication ordered by the doctor belongs to a certain class of controlled substances. The state diagram would then include the additional reporting procedures or other related activities that are required before the medication can be released to the patient (Figure 4.6).
• Class diagrams: A class diagram provides the building blocks for the system. These diagrams show each class and its associated attributes. The diagrams also show the relationship between classes in the system. For example, in the prescription ordering scenario, the patient is a class with attributes such as name, address, and insurance provider. The pharmacy itself is also a class, with attributes that might include location and medications stocked.

Figure 4.4 To easily understand how part of a system works, a sequence diagram can be helpful. This simplified sequence diagram shows how a patient can get a prescription. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Figure 4.5 An activity diagram illustrates complex activities in the system for better understanding. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Figure 4.6 A state diagram illustrates different behaviors of the system dependent on the state the system is in. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Software Development Life Cycle and Agile Software Development

The software development life cycle (SDLC) is a framework that defines the stages of software development, from its inception to its retirement, providing a blueprint of the tasks to be completed for each stage of the cycle (Figure 4.7). Following the recommended SDLC process will lead to a quality product that was created in a systematic and disciplined fashion. The six stages of the SDLC process are analysis, design, development, testing, deployment, and maintenance.

1. Analysis: In the analysis stage, time is spent with the customer to collect relevant information needed to develop the product, keeping the potential design and code in mind. Business analysts and project managers are generally involved in this activity, especially when meetings with the customer will generate user requirements or aspects of a solution, stated by stakeholders, that are needed to support specific needs and expectations of a business process or product. Systems analysts make sure to discuss each aspect of the requirements with the stakeholder to remove ambiguity and to increase clarity and understanding.
2. Design: During the design stage, the user requirements are used as inputs for the design approach. The developer reviews this information to assess the prepared software against the requirements of the end users. Design specifications are created, reviewed by stakeholders, and approved for development.
3. Development: The development stage is sometimes called the implementation or coding phase as this is where these activities begin. The design is translated into source code or computer-legible language—meaning the developer builds the system in a coded language using coding guidelines and programming tools. This stage is the longest in the SDLC life cycle.
4. Testing: Once the development stage is complete, testing of the design is initiated to validate the system functions against the requirements and to identify any bugs or defects within the coding. Often, this occurs within a separate testing area, away from the development and production environment for the product. Developers review the feedback and fix identified problems, updating the components for retesting.
5. Deployment: During the deployment stage, the product is released for customer or stakeholder use. Some testing is also completed in the production environment, which now houses the new product and the approved, validated coding. Documentation on product use generally accompanies this release.
6. Maintenance: The maintenance stage occurs after the product is deployed and is functioning within the production environment, when intermittent patches and fixes may be needed to improve the usability of the product. Additionally, any proposed enhancements may occur during this maintenance period.

Figure 4.7 The SDLC is a cyclical framework that defines the stages of software development, from its inception to its retirement, providing a blueprint of the tasks to be completed for each stage of the cycle. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Agile Software Development

Organizations continue to identify efficiencies in the software development process and are increasingly using the Agile methodology. Agile is an overarching term describing the iterative and incremental delivery of quality products and value to stakeholders using team collaboration, flexibility, and continuous planning. Agile software development is an adaptive approach to software development that considers uncertainty in changing environments and allows “Agile” teams to respond to changes quickly by delivering smaller, consumable work packages. The need for a software development approach that allowed for this flexibility, value, and collaboration was identified by a group of like-minded individuals who created the Manifesto for Agile Software Development, which features four Agile Manifesto values (Figure 4.8).

Figure 4.8 The Manifesto for Agile Software Development was created by seventeen like-minded software developers whose combined thoughts and ideas led to the development of this adaptive approach to manage software development work. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

This approach emphasizes valuing certain aspects of software development over others:

• Individuals’ interactions are valued over processes and tools. The Agile approach focuses on bringing the right stakeholders together to find a solution. Collaboration is at the forefront of the development process.
• Working software is valued over comprehensive documentation. Although documentation is needed, the end goal is a functioning system that meets the needs of the stakeholders with valued-added documentation components. The documentation required should not get in the way of providing a functional system.
• Customer collaboration is valued over contract negotiation. Often with negotiations, one party feels like the winner, while the other feels as if they lost. Agile software development utilizes collaboration throughout the process to build a teamwork mentality to create the most value for the stakeholders.
• Responding to change is valued over following a plan. Traditional development processes often follow a rigid timeline where changes typically result in additional costs and delays. The Agile approach incorporates changes into the planning process through evaluative feedback from stakeholders. This often means that the timeline and plan evolve, and the development of the system evolves.

Historically, software development has been performed using the SDLC. This approach is very systematic and is process oriented, moving from one stage to the next in the process. There are some parallels between the two methods, however. Both SDLC and Agile software development involve planning documentation, feedback, and testing of the system. With the Agile approach, however, there is much greater flexibility to incorporate changes and end-user feedback at all points in the development process. The SDLC approach can be used with any size project, whereas the Agile method is, at times, better suited for smaller-scale projects. With SDLC, no changes are typically made after the initial stages, and there is little interaction with the end user (customer). In contrast, end users are consulted at regular intervals in the Agile approach. Finally, with SDLC, the project moves through stages, whereas the Agile approach uses the term “phases” to better illustrate the fluid nature of the process as the development progresses.

Imagine scaling up a point-of-sale (POS) system to accommodate the needs of a new boutique, opening both an online storefront as well as a physical location. Fenner Street Boutique is set to open in the downtown area of a midsize community that has invested in attracting unique shops for residents and visitors. The boutique has a five-year goal to open a new location in a neighboring city with long-term plans for franchising. The POS system will be used for inventory control and managing both the on-site and online sales. The Agile approach would be particularly well-suited for such an application because there is uncertainty about the five-year goal and the inventory that will be sold online and in the store. The Agile approach is more suited to accommodate the uncertainty and will allow the business owner to incorporate needed adjustments as the business model develops after opening. The business owner will be involved in the development and share crucial information with the team about how the POS system will be used now and in the future. The process allows for the speed, flexibility, and creativity that is needed for growing business.

The main tenets of the Agile Manifesto hold value for applications beyond simply software development. The Agile framework has migrated to a wide variety of applications in business development, including marketing, finance, and human resources.

How Does Agile Development Work?

Although the Agile approach’s process may seem unclear in its flexibility, there are central components of the development process that are key to success. Rather than stages or steps, the components can be best viewed as phases.

• A first step in the development process involves planning and preparation to bring together the right individuals to work on the team. This team might also include key stakeholders from the organization to ensure their input is at the forefront of the systems development, as illustrated in Figure 4.9.
• An assembled Agile team, consisting of a small group of individuals assigned to the same project or product, creates the plan for completing the identified requirements and a final product. The team identifies the features that will make up the final product and the order in which these features will be delivered. These features are referred to as the product backlog (or road map).
• After the product backlog is established, the work of developing the software begins.
• Regular meetings with the Agile team and the product owner are held to gauge the status of work in progress. User stories are the functional components of the work that are defined in conjunction with the product owner or stakeholder. Each of these stories is expected to add to the completed final product.

Figure 4.9 shows the continuous evaluative nature of the Agile approach. The system that is eventually launched is developed with stakeholder input, reevaluation, and adjusting as necessary to provide a solution to meet the needs of the product owner.

Figure 4.9 An Agile team manages the planning and prioritization of work to be undertaken toward a completed product, generally within a 1–4-week iteration. (credit: modification of work by Pietro Casanova, “Agile Processes: A Unifying Approach for the Future of Projects” (paper presented at PMI® Global Congress 2013 --EMEA, Istanbul, Turkey, April 24, 2013), Project Management Institute. https://www.pmi.org/learning/library/agile-approach-projects-market-globalization-5777)

Careers in IS

Agile Project Manager

Agile project managers lead Agile teams and deliver projects using the Agile methodology. Managing projects with an Agile method differs from traditionally managed projects as the Agile project manager guides the team through dynamic, fast-changing, and sometimes volatile environments with a good deal of uncertainty to achieve project targets. The skills required for this role include excellent communication and organizational skills, effective critical-thinking, the ability to work well within a team environment, and a strong understanding of Agile and project management processes. These positions can be found in a variety of organizations but are generally housed in IS departments.

Another element of Agile project management is sprint planning. A sprint is a time-based period, generally between 1 and 6 weeks, that represents a delivery cycle during which the specified work is completed and reviewed. During these sprints, the team will have a daily meeting, often called a stand-up, generally between ten and thirty minutes, to discuss progress made and challenges encountered. The team will also discuss the design needs of the work, which may occur before or during the first sprint. Additionally, teams will break down large tasks into subtasks for each sprint. For each sprint, an Agile team identifies, based on the skills of its team members, the user stories it will work on during the sprint, and it estimates the time required for completion. For example, the team may decide on a two-week sprint, aiming to complete two coding tasks, two testing tasks, and two documentation tasks. After this, the user stories are prioritized accordingly.

During the sprint, the team members will actively work on their assigned tasks and resolve any issues needing to be addressed. When an issue arises during sprints, it is added to the backlog and prioritized with the work already maintained in the backlog. At the completion of each sprint, the team generally has a usable and workable product, ready for the stakeholder or product owner to review during a sprint review meeting. Teams may be able to see the amount of work remaining through the use of a burndown chart, or a graphical representation of the work completed in a sprint and the work remaining over time. The team has a postsprint review to identify challenges and opportunities for the next sprint cycle. This process continues until the backlog of work is depleted and the functional components of the product are completed. Once the backlog of items has been addressed, the team will hold a retrospective meeting where members will discuss the sprints in detail and areas of improvement to apply to future sprints.

Advantages and Disadvantages of SDLC and Agile Software Development

In determining how to approach systems analysis, the advantages and disadvantages of SDLC and Agile should be considered. Some aspects of the processes might be better suited for specific types of projects, while others may not. The flexibility required in the nature of today’s business world and how businesses operate might require a hybrid approach to software development that includes aspects from both SDLC and Agile.

The structure in the SDLC approach can offer projects rigor, detailed documentation, a thorough examination of the risks and pitfalls in a design, and careful attention to budgetary considerations. However, SDLC is not designed for projects with a good deal of uncertainty in the beginning stages, nor is it suitable for projects in which unexpected changes might come up. This is where Agile software development’s more fluid approach can be beneficial. Through a more iterative approach and with close collaboration with end users, the design can be clarified, key stakeholders can be involved, and unexpected issues can be systematically tackled. Agile has been criticized for its lack of detailed documentation and the unpredictable costs that can result from its focus on speed and flexibility. But by using a hybrid approach, organizations can mitigate these weaknesses and utilize the strengths of each approach to meet their needs.

Consider the scenario of developing the POS system for Fenner Street Boutique to see how the hybrid approach works in practice. With the ribbon cutting and website launch already scheduled, the business owner faces a tight deadline and is particularly concerned about staying within budget. Because the POS system will be crucial for inventory control, it needs to be up and running before the store opens. The SDLC approach helps by providing clear deadlines and documentation, ensuring the system is scalable for future growth, and keeping budget considerations in mind. On the other hand, the Agile approach allows the owner to stay involved throughout the process and adapt as needed, such as adding the finalized logo once it’s ready.

Furthermore, as the owner is still deciding on the final inventory for both in-store and online items (including potential “online exclusive” products), there are uncertainties to address. Agile software development is ideal for handling such flexibility, giving the business owner a voice throughout the development process. In sum, SDLC offers the structure necessary to meet deadlines and budgets, while Agile allows the business the flexibility to make decisions as its vision evolves.

Roles and Responsibilities of the Analysis and Design Teams

Analysis and design teams may consist of several members using various tools and methods to create design-related solutions, such as designing a mobile application, building a website, or any other design effort. The size of the team will vary, as will its structure—from centralized design teams with hierarchical organization to flexible teams of contract resources. Both structure and size will be determined by the scope of the effort and the types of expertise needed. Table 4.1 lists the roles found on an analysis and design team.