Systems Analysis and Design Chapter 4

Systems Analysis and Design in a Changing World, Fourth Edition - Chapter 4

• Learning Objectives
  • Describe activities in the systems analysis life cycle phase.
  • Explain the impact of business process reengineering on analysis phase activities.
  • Differentiate functional and nonfunctional system requirements.
  • Identify various user types involved in investigating system requirements.
  • Describe information needed for system requirements development.
  • Determine system requirements through review of documentation, interviews, observation, prototypes, questionnaires, vendor research, and joint application design sessions.
  • Discuss the need for system requirement validation and the use of structured walkthroughs.
  • Analysis phase of SDLC skills needed.
  • Fact finding for investigation of system requirements.
  • Analyst should learn details of business processes and daily operations.
  • Analyst should become knowledgeable as business domain users to build credibility.
  • Analyst brings fresh perspective to problem modeling of business processes based on system requirements.

Analysis Phase in More Detail

• Gather information
• Define system requirements (functional and nonfunctional)
• Prioritize requirements
• Prototype for feasibility and discovery
• Generate and evaluate alternatives
• Review recommendations with management.

The Activities of the Analysis Phase

• The analysis phase activities are part of a larger project lifecycle and occur between the project planning phase and the design phase.

• Key activities include gathering information, defining system requirements, prioritizing them, creating prototypes, generating and evaluating alternatives, and presenting recommendations to management.

• These are followed by implementation and support.

• This overview is depicted in Figure 4-1.

Activities of the Analysis Phase and Their Key Questions

• Analysis phase involves information gathering, requirement definition, prioritization, prototyping, evaluation of alternatives, and review.
• Key questions are useful to guide these actions in a structured way.

Business Process Reengineering and Analysis

• A strategic approach to reorganizing a company.
• Streamlines internal processes to achieve maximum efficiency and effectiveness.
• Questions underlying business practices to identify areas for improvement.
• IT is a tool to enable this reengineering.
• Opportunities for process improvements can be discovered by systems analysis.
• Projects often incorporate components of BPR.

System Requirements

• New system capabilities and constraints
• Functional requirements
  • Activities the system must perform (use cases)
  • Based on procedures and business functions
  • Documented in analysis models
• Nonfunctional requirements
  • Technical environment or performance objectives
  • Usability, reliability, and security requirements

Stakeholders—The Source of System Requirements

• People interested in successful system implementation.
• Three primary groups of stakeholders:
  • Users: Those who use the system.
  • Clients: Those who pay for and own the system.
  • Technical staff: Ensure system operation.

Stakeholders Interested in New System Development

• A diagram (Figure 4-4) illustrates various stakeholder groups (executive users, middle managers, technical staff, external users, clients, business users, and information users) and their connection to new system development.

More on Users as Stakeholders

• Horizontal user roles: Information flow across departments.
• Vertical user roles: Information needs of staff, middle management, and executives.
• Business users: Day-to-day operations.
• Information users: Need current information.
• Management users: Need summary information.
• Executive users: Need strategic information.
• External users: May have access to the system.

Techniques for Information Gathering

• Analysis phase techniques to understand business functions and develop system requirements.
• Original structured approach, creates a model of the existing system and derives requirements from this.
• Current approach to identify logical requirements for the new system.

Relationship Between Information Gathering and Model Building

• Visual representation of the process (Figure 4-6) showing how information gathering techniques.
• Techniques like questionnaires, interviews, reviewing documentation, observing business operations, and researching solutions all work together in determining the requirements for the new system.

Themes for Information-Gathering Questions

• Themes for questions to gather information and how they relate to the business operations, processes.
• Essential to understand how processes are performed, what information is needed to perform these operations. Example themes from Figure 4-7.

Fact-Finding Methods

• Methods for fact-finding include:
  • Reviewing existing reports, forms, and procedure descriptions.
  • Interviewing and discussing processes with users.
  • Observing and documenting business processes.
  • Building prototypes.
  • Distributing and collecting questionnaires.
  • Conducting joint application design (JAD) sessions.
  • Researching vendor solutions.

Review Existing Reports, Forms, and Procedure Descriptions

• Source information from external organizations, trade publications, and internal business documents.
• To identify business rules, discrepancies, and redundancies, be cautious of outdated material.

Conduct Interviews and Discussions with Users

• Effective in understanding business functions and rules.
• Time-consuming and resource-intensive, potentially requiring multiple sessions to meet all users.

Observe and Document Business Processes

• Observing and documenting may vary from office walkthroughs to performing actual tasks.
• There is no need to observe all processes at the same level of detail. Common sense and sensitivity must be employed with users.
• Documentation methods like UML notations for activity diagrams are useful for documenting workflows; see Figure 4-13.

Build Prototypes

• Preliminary working models for more complex system components.
• Types of prototypes include discovery, design, and evolving prototypes, each aiming for quick, operational prototypes, with specific, single objectives to accomplish.

Distribute and Collect Questionnaires

• Limited and specific information from a large number of stakeholders.
• Provide preliminary insight into business processes, but not suited for detailed information gathering.
• Closed-ended questionnaires direct responses, open-ended encourages discussion and elaboration.

Team-Oriented Methods and Techniques

• Team development approaches
  • Joint application development (JAD).
  • Rapid application development (RAD).
  • Agile methodologies.

Conduct a JAD/Facility

• Image (Figure 4-16) shows a physical workspace configuration suitable for team-based interactive work.

Joint Application Development

• User involvement is critical for successful systems.
• JAD is a method for user involvement
  • Various participants hold specific roles and responsibilities to ensure the development is successful.
• JAD has advantages and disadvantages.

Rapid Application Development

• A team-based technique that speeds up information systems development and produces a functioning system.
• Heavy reliance on prototyping and user involvement.
• Interactive process continues until the system is completely developed and users are satisfied.

Rapid Application Development Phases and Activities

• Requirements Planning (with roles users, managers, and IT staff).
• User Design (interaction, prototyping, JAD-type sessions).
• Construction (program and application development, unit/integration/system testing).
• Cutover (data conversion, testing, system changeover, and user training).
• RAD objectives are to cut development time and expenses by involving users in every phase of development.
• Successful RAD teams need IT resources, skills, and management support.

Rapid Application Development Advantages and Disadvantages

• Systems implemented quickly and cost savings possible.
• RAD focus on system mechanics can overlook strategic business needs.
• Less time for quality, consistency, and design standards.

Agile Methods

• Incremental approach to system development.
• Some developers may chose not to use CASE tools. Whiteboard display and sticky notes are alternatives.

Agile Method Advantages and Disadvantages

• Very flexible and efficient for dealing with change.
• Frequent deliverables validate projects and lower risk.
• Team members require intense technical and interpersonal skills.

Research Vendor Solutions

• Many problems already solved by other companies.
• Vendor solutions often have useful features and can lead to new ideas.
  • They may be state of the art, cheaper, and less risky than building solutions in house.
• Risks from relying on vendor solutions if the problem is not fully understood.

Useful Techniques in Vendor Research

• Vendor technical specifications are useful.
• Demos and trial systems provide hands on experience.
• References from existing clients help assess the vendor's performance.
• On-site visits offer a complete view of the vendor's operation.
• Printouts of screens and reports useful documentation of the system.

The Zachman Framework

• Zachman Framework assists in enterprise architecture.
• Helps managers and users understand the model.
• It ensures that overall business goals translate into successful IT projects.
• Clear, actionable, and meaningful information is delivered under elements of Who, What, Where, When, How, and Why; differentiates between current and potential future situations.

Validating the Requirements

• Ensure the gathered information is correct.
• Structured walkthrough ensures the accuracy and completeness of requirements.
• Implementing quality control early in the project is important.
• Verifying and validating system requirements, reviewing findings, and ensuring that models are based on the findings are crucial aspects of this process.
• System quality is the responsibility of the project manager, with the system analyst acting as a partner.

Summary

• Analysis phase activities, gathering information, defining requirements, prioritizing, prototyping, evaluating alternatives, and reviewing recommendations.
• BPR and Zachman Framework can assist with the analysis phase activities.
• Summary of gathering system requirements, noting they are functional and non-functional, and including users, clients, and technical staff. It is essential to gather information related to what information is needed, what are the business processes and operations, how are they performed, and what are the information requirements.
• Summary of techniques for gathering information includes reviewing reports, forms, conducting interviews or discussions, observing processes, building models, using prototypes, questionnaires, JAD, and research vendor solutions.

Explore the key activities in the systems analysis life cycle and their relevance in the analysis phase of SDLC. This quiz delves into the impact of business process reengineering, the distinction between functional and nonfunctional requirements, and various user types involved in requirement gathering. Test your knowledge on the methods of fact-finding and validation necessary for effective systems analysis.