Chuyển đến nội dung chính

Diagrams in System Analysis and Design

Diagrams in System Analysis and Design

In system analysis and design, diagrams are used to represent the different aspects of a system, its components, and their interactions. The main types of diagrams used in system analysis and design include:

  • Use case diagrams: This type of diagram is used to describe the functionality of a system from the user's perspective. It shows the different use cases (or scenarios) in which a user interacts with the system, as well as the actors (or users) who are involved in those interactions.
  • Activity diagrams: This type of diagram is used to represent the flow of activities within a system. It shows the sequence of activities and decisions involved in a particular process or use case.
  • Sequence diagrams: This type of diagram is used to represent the interaction between objects in a system. It shows the sequence of messages exchanged between objects in a particular scenario or use case.
  • Class diagrams: This type of diagram is used to represent the structure of a system. It shows the different classes that make up the system, their attributes, and their relationships with each other.
  • Deployment diagrams: Deployment diagrams are a type of diagram used in system analysis and design to illustrate the physical architecture of a system. They show how the different components of a system are deployed on hardware or software environments, such as servers, workstations, or cloud services.
  • Component diagrams: This type of diagram is used to represent the components of a system and their dependencies. It shows the different parts of the system, their interfaces, and how they interact with each other.

These diagrams are used to help system analysts and designers to understand the requirements of the system, design its components, and communicate their designs to stakeholders. Each diagram represents a different aspect of the system, and together they provide a comprehensive view of the system and its behavior.


[Australia]  261111 - ICT Business Analysts

Identifies and communicates with users to formulate and produce a requirements specification to create system and software solutions.

Description of Employment Duties:

  • Working with users to formulate and document business requirements
  • Identifying, investigating, and analyzing business processes, procedures and work practices
  • Identifying and evaluating inefficiencies and recommending optimal business practices, and systemfunctionality and behavior
  • Using project management methodologies, principles and techniques to develop project plans and to cost, resource and manage projects
  • Taking responsibility for deploying functional solutions, such as creating, adopting and  implementing system test plans, which ensure acceptable quality and integrity of the system
  • Creating user and training documentation, and conducting formal training classes
  • Developing functional specifications for use by system developers
  • Using data and process modeling techniques to create clear system specifications for the design and development of system software 
  • Acting as a central reference and information source, providing guidance and assistance in the system project decision making process

Nhãn:

Bài đăng phổ biến từ blog này

Activity diagram, Component Diagram and Deployment Diagram in System Analysis and Design

Activity diagram Activity diagrams are widely used in system analysis and design to model the behavior of a system, particularly for business processes and workflows. In system analysis and design, activity diagrams are used to model the steps or activities involved in a particular process or use case scenario. Activity diagrams in system analysis and design typically have the following characteristics: Start and end points: The diagram should begin with a start point, which represents the initiation of the process or use case, and end with an end point, which represents the completion of the process or use case. Actions: The actions or steps involved in the process or use case should be represented by rectangular boxes, and the actions should be organized in a logical sequence. Control flow: The flow of control between actions should be represented by arrows. Arrows should indicate the order in which actions are performed and the conditions that determine the path of the process or us
Đọc thêm

Suffix -ing -es -ed in English

-ING ID End with Rules For example (e.g.) 1 e End in 'e' - drop the 'e' then add 'ing' live > living drive > driving joke > joking 2 ie End in 'ie': - i > y - drop the 'e' then add 'ing' lie > lying die > dying 3 ee, oe, ye Just add 'ing' see > seeing, agree > agreeing tiptoe > tiptoeing dye > dyeing 4 w, x, y Just add 'ing' bow /baʊ/ > bowing fix /fiks/ > fixing say /seɪ/ > saying 5 vowel + consonant 1. (End in vowel-consonant) + One-syllable word 2. (End in vowel + consonant ) + stress (final syllable) > x2 final cosonant + _ing 1. put > putting sit > sitting cut > cutting run > running 2. beginning 6 c Add a -k + -ing mimic /ˈmɪm.ɪk/ > mimicking 7 consonant + vowel + -l [en] double -l + -ing [us] just add -ing travel > travelling [en] - traveling [us] 8 others Just add 'ing' rain > raining -ED ID End with Rules For example (e.g.) 1 e End in 'e
Đọc thêm