Summary

This document appears to be lecture notes or study material covering topics in system analysis and design, including requirement disciplines, models, and use case diagrams. The key concepts cover gathered information, defining requirements, prioritizing them, user interaction design, and validation. The material seems targeted at a software engineering or similar undergraduate level.

Full Transcript

INSY 55 Reviewer – Finals Models - provide a structured representation of system Types: Multiple choice, True or False, Identification components and their interactions. They help visualize and Debugging....

INSY 55 Reviewer – Finals Models - provide a structured representation of system Types: Multiple choice, True or False, Identification components and their interactions. They help visualize and Debugging. how the system operates, both logically and technically. Mathematical Models - Use mathematical Lecture 6 - Requirement Discipline equations to represent system behavior and Requirements Discipline - ensures that the project relationships. addresses the true needs of the business and users. It Descriptive Models - Describe system involves identifying, analyzing, and documenting the components, functions, and processes in written requirements for the system. or textual form. Graphical Models - Use visual diagrams to Gathered Information - Collect all relevant information represent system components, data flow, and about the system’s needs, functions, and constraints. interactions. Interviews - Conducting interviews with stakeholders to understand their needs. Common Types of Models: Surveys/Questionnaires - Distributing forms to Use Case Diagrams - Show interactions collect feedback from a larger group. between users and the system. Observations - Monitoring current systems and Data Flow Diagrams (DFD) - Visualize how processes to see where improvements are data moves through the system. needed. Entity-Relationship Diagrams (ERD) - Represent data and relationships in databases. Define Requirement - Clarify and formalize the requirements based on the gathered information. Techniques For Information Gathering: Functional Requirements - Describe what the Interviews – One-on-one discussions with system should do. stakeholders. Non-Functional Requirements - Outline how Focus Groups - Group meetings to gather the system should behave diverse perspectives. Document Analysis - Reviewing existing Prioritize Requirement - Rank the requirements based documentation. on factors like business value, feasibility, and urgency. Prototyping - Creating a basic version of the MoSCoW Method - Categorizes requirements system to gather feedback. into "Must have," "Should have," "Could have," and "Won't have." Validating The Requirements - Ensures that the documented requirements are accurate, achievable, and Develop User Interface Dialogs - Design the interaction aligned with user needs. between users and the system. These dialogs help visualize how users will interact with the system. Validation - reduces the risk of errors in the later stages of Prototyping - Creating mock-ups of screens to system development. simulate user interaction. Prototyping and Walkthroughs - Presenting a Wireframing - Basic structural layouts of user prototype of the system to stakeholders and interfaces. walking through the requirements. User Testing - Allowing users to interact with a Evaluate Requirements with Users - Validate the working model or prototype to verify that their gathered and defined requirements with the end-users to needs are met. ensure accuracy and completeness. Requirements Review - Conducting formal User Acceptance Testing (UAT) - Involving review sessions where stakeholders review and users in testing prototypes or systems against approve requirements documents. their needs. Focus Groups - Group discussions with Lecture 7 - Use Case Diagram stakeholders to refine requirements. UML use case diagram - is the primary form of System requirements - specify the detailed system/software requirements for a new software program functionalities and constraints of the system. These underdeveloped. requirements drive the entire design and development process. Use cases - specify the expected behavior (what), and Business Requirements - High-level goals and not the exact method of making it happen (how). Use objectives. cases once specified can be denoted both textual and Functional Requirements - Detailed actions visual representation. the system must perform. Standard Form of Use Case Diagram - is defined in the Non-Functional Requirements - Qualities of Unified Modeling Language. the system like performance, reliability, and security. Class Diagram - is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, operations (or methods), and the relationships among objects. Class - A description of a group of objects all with similar roles in the system. Structural features - define what objects of the class "know". Use Case Diagram Components: Behavioral features - define what objects of Actor - Someone interacts with use case. the class "can do". Use Case - System function. Communication Link - The participation of an Class Notation: actor in a use case is shown by connecting an Class Name - The name of the class appears in actor to a use case by a solid link. the first partition. Boundary of System - is potentially the entire Class Attributes - Attributes are shown in the system as defined in the requirements second partition. document. Class Operations - Operations are shown in the Extends - Depict with a directed arrow having a third partition. They are services the class dotted line. provides. Include - When a use case is depicted as using the functionality of another use case, the relationship between the use cases is named as include or uses relationship. Use Case Diagram with Relationships: Generalization - generalization relationship is a parent-child relationship between use cases. o Child Use Case - is an enhancement of the parent use case. Relationships Between Classes Association - represents a bi-directional relationship between two classes. It indicates that instances of one class are connected to Lecture 8 – Domain Classes and Related Concepts instances of another class. Typically depicted as a solid line Domain Classes - represent key concepts or entities in Directed Association - represents a the domain of the system being modeled. relationship between two classes where the Attributes - Represent properties of the class association has a direction, indicating that one Methods - Define the behavior of the class class is associated with another in a specific way. Characteristics Of Domain Class: Aggregation - a specialized form of association Attributes - Domain classes have attributes that that represents a “whole-part” relationship. It represent the properties or characteristics of denotes a stronger relationship where one class objects belonging to that class. contains or is composed of another class. Methods - Domain classes can have methods Composition - is a stronger form of that define the behavior or operations that aggregation, indicating a more significant objects of the class can perform. ownership or dependency relationship. Relationships - Domain classes can have Generalization (Inheritance) - Inheritance relationships with other classes, such as represents an “is-a” relationship between associations, aggregations, or compositions. classes, where one class (the subclass or child) inherits the properties and behaviors of another Identity - Domain classes have identity, class (the superclass or parent). meaning that each object of the class is unique o Inheritance - is depicted by a solid and can be distinguished from other objects. line with a closed, hollow arrowhead Multiplicity - Domain classes can have pointing from the subclass to the multiplicity, which specifies how many instances superclass. of another class are associated with each instance of the class. Realization (Interface Implementation) - Project Management Environments in System indicates that a class implements the features of Analysis and Design: an interface. It is often used in cases where a Requirements Gathering Environment class realizes the operations defined by an Design Environment interface. Development Environment o Realization is depicted by a dashed Testing Environment line with an open arrowhead pointing Production Deployment Environment from the implementing class to the interface. Key Project Management Considerations in System Dependency Relationship - A dependency Analysis and Design: exists between two classes when one class Scope Management relies on another, but the relationship is not as Resource Management strong as association or inheritance. It Time Management represents a more loosely coupled connection Risk Management between classes. Communication Management o Dependencies are often depicted as a dashed arrow. Deployment Environment - The physical or virtual space Usage (Dependency) Relationship - A usage where software applications are installed, configured, and dependency relationship in a UML class executed. diagram indicates that one class (the client) On-Premises - Hosted on local servers; utilizes or depends on another class (the Suitable for organizations with strict data control supplier) to perform certain tasks or access requirements. certain functionality. Cloud-Based - Hosted on cloud platforms; Offers scalability and flexibility. Benefits Of Class Diagrams Hybrid - Combines on-premises and cloud Class diagrams represent the system’s classes, resources; Ideal for gradual cloud migrations. attributes, methods, and relationships, providing a clear view of its architecture. Key Considerations: (above) They show various relationships between Scalability - Can the environment handle growth classes, such as associations and inheritance, in users and data? helping stakeholders understand component Reliability - Ensuring consistent uptime and connectivity. performance. Class diagrams serve as a visual tool for Security - Protecting data and access. communication among team members and stakeholders, bridging gaps between technical Extranet - A private network that securely connects an and non-technical audiences. organization with external parties like partners, suppliers, They guide developers in coding by illustrating or customers. the design, ensuring consistency between the Controlled access using authentication design and actual implementation. mechanisms. Many development tools allow for code Enables collaboration and data sharing. generation from class diagrams, reducing manual errors and saving time. Benefits of Extranets: Improved Collaboration - Partners can access Class Diagrams - shows the static structure of a software system, showcasing classes, attributes, methods, and project updates in real time. relationships. Streamlined Communication - Centralized platform for updates, requests, and feedback. CRUD Matrix - is an acronym that refers to the following Enhanced Security – Encrypts data transfers actions on an object (typically a data entity): Create - to and restricts unauthorized access. create and store new data. Read - to retrieve and read data Software Architecture - The high-level structure of a Update - to change or modify then store the software system, encompassing its components and data. their interactions. Provides a roadmap for development and Delete - to delete or remove the data deployment. Balances trade-offs between quality attributes Lecture 9-10: Design Activities and Environments like performance, security, and maintainability. Design Activities and Environments - in system Core Elements: (above) analysis and design are part of the System Development Components - Modules, services, or layers. Life Cycle (SDLC), a structured process for developing Connectors - Interfaces and communication information systems. mechanisms. Constraints - Rules and policies guiding Project Management - In system analysis and design, design. project management activities encompass planning, organizing, leading, and controlling the development process, including defining project scope, establishing timelines, assigning tasks, managing resources, and monitoring progress. Architectural Patterns and Styles Layered Architecture - Divides the system into layers Client-Server Architecture - Clients request services from a centralized server. Microservices Architecture - Independent services communicate over APIs. Event-Driven Architecture - Components communicate asynchronously through events. Model-View-Controller - Separates the application into model, view, and controller. Network Design - The process of planning and structuring a computer network to meet organizational or user requirements. Key Design Activities in Network Design: Requirement Gathering - Identify business and technical needs. Topology Selection - Decide on network layout: star, mesh, bus, or hybrid. Device Selection - Choose routers, switches, firewalls, and other hardware. IP Addressing and Subnetting - Allocate IP ranges and design subnets for efficient communication. Security Planning - Implement firewalls, VPNs, and encryption. Performance Optimization - Configure load balancing and redundancy. Best Practices for Network Design: Plan for Scalability - Design for future growth. Focus on Redundancy - Avoid single points of failure. Prioritize Security - Implement end-to-end encryption and robust authentication. Ensure Documentation - Maintain updated network diagrams and configurations. Use Industry Standards - Follow guidelines like ISO/IEC 27001.

Use Quizgecko on...
Browser
Browser