ITM305 CH2 PDF - Systems Analysis Activities

Systems Analysis Activities 1. Gather Detailed Information ○ Methods: Interviews, questionnaires, reviewing documents, observing business processes, researching vendors, collecting comments and suggestions. 2. Define Requirements ○ Tasks: Model functional req...

Systems Analysis Activities 1. Gather Detailed Information ○ Methods: Interviews, questionnaires, reviewing documents, observing business processes, researching vendors, collecting comments and suggestions. 2. Define Requirements ○ Tasks: Model functional requirements and define non-functional requirements (How fast is it and how useful it is for example)(Making sure its a joy to use). 3. Prioritize Requirements ○ Categories: Essential, Important, and Nice-to-Have. 4. Develop User-Interface Dialogs ○ Focus: Design the flow of interaction between the user and the system. 5. Evaluate Requirements with Users ○ Approach: Engage users for feedback and adapt requirements based on their input and changes. Information Gathering Techniques 1. Interviewing Users and Other Stakeholders ○ Purpose: To gather detailed insights, requirements, and expectations directly from those involved or affected. 2. Distributing and Collecting Questionnaires ○ Purpose: To obtain structured feedback and data from a larger group of users or stakeholders. 3. Reviewing Inputs, Outputs, and Documentation ○ Purpose: To understand existing systems, workflows, and documentation to inform new system design and requirements. 4. Observing and Documenting Business Procedures ○ Purpose: To gain a practical understanding of current processes and identify areas for improvement. 5. Researching Vendor Solutions ○ Purpose: To explore available tools, technologies, and solutions that may meet the project's needs. 6. Collecting Active User Comments and Suggestions ○ Purpose: To incorporate user feedback and recommendations into the system design and development process. Themes for Information Gathering Questions Additional Techniques Observe and Document Business Processes ○ Watch and Learn: Gain insights by observing current processes in action. ○ Document with Activity Diagram: Use activity diagrams to capture and illustrate the flow of business processes (details in the next section). Research Vendor Solutions ○ See What Others Have Done: Investigate how similar problems have been addressed by others. ○ Sources: Explore white papers, vendor literature, and competitor solutions to understand available options. Collect Active User Comments and Suggestions ○ Feedback on Models and Tests: Gather user input on prototypes and test scenarios to refine and improve system design. ○ Users Know It When They See It: Utilize user feedback to validate design choices and ensure they meet user expectations. What Are Requirements? System Requirements ○ Functional Requirements: The activities the system must perform. Examples: functions that users carry out. Use Cases: Detailed descriptions of how users will interact with the system to achieve specific goals. ○ Non-Functional Requirements: Other system characteristics. Examples: How fast is it Constraints, performance goals, and overall system quality attributes. FURPS Requirements Acronym  Functional Requirements: The specific behaviors and functions that the system must perform. Usability Requirements: The ease with which users can learn, operate, and interact with the system. Reliability Requirements: The system's ability to maintain performance over time and under various conditions. Performance Requirements: The speed, responsiveness, and efficiency of the system. Security Requirements: Measures and controls to protect the system and data from unauthorized access and threats. + (Plus): Additional categories, which can include: ○ Supportability: Ease of maintenance and support. ○ Scalability: The system's ability to handle increased loads or expanded functionality. ○ Compliance: Adherence to regulatory and legal standards. Additional Requirements Categories Design Constraints ○ Description: Specific restrictions related to hardware and software that must be considered during design. Implementation Requirements  ○ Description: Requirements specifying the languages, tools, protocols, and other technologies to be used. Interface Requirements ○ Description: Requirements for how the system will interface and integrate with other systems. Physical Requirements ○ Description: Constraints related to physical facilities and equipment that support the system. Supportability Requirements ○ Description: Criteria for automatic updates, enhancement methods, and overall ease of maintaining and supporting the system. FURPS + DIIPS Stakeholders Stakeholders ○ Description: Individuals or groups who have an interest in the successful implementation and outcome of the system. Internal Stakeholders ○ Description: Individuals within the organization who are affected by or have an interest in the system. External Stakeholders ○ Description: Individuals or groups outside the organization who are impacted by or have an interest in the system. Operational Stakeholders ○ Description: Users who regularly interact with the system and use it in their day-to-day activities. Executive Stakeholders ○ Description: Individuals who may not interact directly with the system but are affected by its outcomes or have a financial or strategic interest in it. Some Analysis and Design Models Reasons for Modeling Learning from the Modeling Process: Gain insights and understanding through the process of creating models. Reducing Complexity by Abstraction: Simplify complex systems by creating abstract representations. Remembering All the Details: Ensure that all aspects of the system are documented and remembered. Communicating with Development Team Members: Facilitate clear communication and collaboration within the development team. Communicating with Users and Stakeholders: Ensure various users and stakeholders understand the system and its functionalities. Documenting for Future Maintenance/Enhancement: Provide a reference for future updates and maintenance of the system.  - Midterm: *Study the symbols, he will ask what it represents on the midterm* and actors - Midterm: * Which is an example of a temporal event* - Midterm: *Is this person an actor, stakeholder, or etc. in this scenario* Use Cases Definition: An activity that the system performs, usually in response to a request by a user. Purpose: Define functional requirements of the system. Decomposition: Analysts break down the system into a set of use cases (functional decomposition). Techniques for Identifying Use Cases: ○ User Goal Technique ○ Event Decomposition Technique Naming Convention: Use Verb-Noun format for naming each use case (e.g., "Place Order"). User Goal Technique: Specific Steps 1. Identify Potential Users ○ Determine all potential users for the new system. 2. Classify Users by Functional Role ○ Group users based on their functional roles (e.g., shipping, marketing, sales). 3. Classify Users by Organizational Level ○ Further categorize users by their organizational level (e.g., operational, management, executive). 4. Interview Users ○ Interview each type of user to gather a list of specific goals they have for the new system, including current goals and potential innovative functions. 5. Create Preliminary Use Cases ○ Develop a preliminary list of use cases organized by user type. 6. Resolve Duplicates and Inconsistencies ○ Identify and resolve any duplicates or inconsistencies in the use case names.  7. Identify Shared Use Cases ○ Determine where different types of users require the same use cases. 8. Review with Users and Stakeholders ○ Review the finalized list of use cases with each type of user and relevant stakeholders to ensure completeness and accuracy. Use Case Diagrams Definition ○ A Use Case Diagram is a UML (Unified Modeling Language) model used to graphically represent use cases and their relationships with actors. Unified Modeling Language (UML) ○ UML: A standardized modeling language used for specifying, visualizing, and documenting the design of information systems. Actor ○ Definition: In UML, an Actor represents an end user or another system that interacts with the system being designed. ○ Primary Actors: The primary actors are those who initiate the use cases and interact with the system to achieve specific goals. System Boundary ○ Definition: The System Boundary represents the limits of the total application, distinguishing what is part of the system from what is external to it. Automation Boundary ○ Definition: The Automation Boundary separates the computerized components of the application from the user interactions, illustrating which parts of the system are automated and which are managed by users.