This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

159.225 System Analysis and Modelling

159.225 System Analysis and Modelling

1 - 159.225 Assignment1

analysis, modelling and high-level design phases of the project.

Aware of content healthy and reduce translate to English - Translate and reduce AI similarity

Part1 - Assumptions & Background

Part2 - System Request

image.png

==Q1: Description and Background? (sponsor)== ==Q2: Missing Mail introduce== ==C1: Delete option report function== ==C2: Assume different system has been used by IT depatement for a while==

Project Sponsor: John smith from IT unit

Business Need: Five charities have been merged, each with its own system for tracking donors, donations, and communication. Complaints received from operations staff regarding complex processes and difficult management; and from donors regarding missing information, lack of feedback channels after donations, and delays in tracking donations; as well as the absence of a unified email system, making it difficult to attract potential donors.There is a need to create a system with single, unified database and mail function.

Business Requirements: The new system should be able to integrate donor details from all five previous systems, including information on potential and actual donors. It will track all donations made to the merged charity, regardless of the original charity's source. The system will also contain a integrated mail function as conmmunicating method to consolidating various methods used by individual charities


Business Value: reduce the administrative burden of managing multiple systems (by 40% in 5 month)

attract potential donors

rapid responce as well as tracking donations for donors (Satisfaction will increased by 30%.)

Special Issues or Constraints: Two large - scale systems have complete documentation, the other two have only user - facing documentation. Technical knowledge for these two systems may rely on staff demonstration, which could cause delays in the integration process.

Part3 Technical Feasibility analysis

image.png

==Q4: WRONG DEFINATION of The function area== ==C6: Assume external IT support still avaliable== ==C7: Assume all five charity has same process of donation==

The functional area: 
Risk in the functional area is LOW
Analysts are organized from previous charities, and only those who have worked for five years or more can join the team. The analysts include both IT and non-IT departments and can fully oversee the system.
For features with missing user documentation, staff can clarify core functionalities through operational demonstrations (such as the template logic of the email generation system and the field definitions of the donation tracking system). By organizing workshops to record operational processes and create data flow diagrams, the issue of missing technical documentation can be addressed.

The technology area: 
Risk in technology is LOW
Previous large charitable organizations have been integrated into the existing organization, and the IT personnel are familiar with the technical stack involved in the system, with complete user and technical documentation.

Project Size area:
Project size is modreate
The project team should be composed as much as possible of IT members with long work experience and high-level expertise. avoiding the involvement of inexperienced individuals and non-stakeholders (10-15 members).  
Duration: The project duration is 10 months, which is within the reasonable range for a medium-sized system integration project

Compatibility area:
The risk in compatibility is LOW
The systems of the two large organizations are relatively well-established. The system is built on the foundations of the two largest charitable organizations. and the new system can be well integrated with these large organizations. The other three organizations have only implemented part of the features of the large systems, but the main business processes are similar. The compatibility of the technical infrastructure is moderate.

Part4 Project Management Plan

image.png

charity.png

1. Project Initial and Strategy - Planning (April 2025)

Duration: 2 weeks
Tasks:
  - System Request (April 17, 2025 - April 21, 2025)
  - Feasibility Analysis (April 17, 2025 - April 21, 2025)
  - Define Project Scope (April 17, 2025 - April 21, 2025)
  - Organize Project Team (April 21, 2025 - April 25, 2025)
  - Develop Project Management Plan (April 25, 2025 - April 28, 2025)

Dependencies: None
Milestone: Project initiation complete (April 28, 2025)
Responsible Role: Project Sponsor

2. Requirement Gathering - Analyzing (May 2025)

Duration: 4 weeks
Tasks:
  - Develop an Analysis Strategy (May 5, 2025 - May 9, 2025)
    - Model the Current System (May 5, 2025 - May 9, 2025)
    - Formulate the New System (May 5, 2025 - May 9, 2025)
  - Collect and Analyze Requirements (May 12, 2025 - May 19, 2025)
  - Create Use Case Diagrams and Descriptions (May 26, 2025 - May 29, 2025)
  - Validate and Approve Requirements (June 2, 2025 - June 5, 2025)

Dependencies: Project initiation complete
Milestone: Requirements approved (June 5, 2025)
Responsible Role: Business Analyst, Project Sposor

3. System Design (June 2025)

Duration: 3 weeks
Tasks:
  - Develop Design Strategy (June 9, 2025 - June 12, 2025)
  - Design Architecture and Interfaces (June 13, 2025 - June 16, 2025)
  - Select Hardware, Software, and Network Requirements (June 16, 2025 - June 20, 2025)
  - Develop Program Design (June 20, 2025 - June 26, 2025)

Dependencies: Requirements approval
Milestone: Design finalized (June 26, 2025)
Responsible Role: System Architect

4. Continuous Iteration (June - July 2025)

Duration: 1 week
Tasks:
  - Execute Integration Testing (June 27, 2025 - June 30, 2025)
  - Conduct User Acceptance Testing (UAT) with Stakeholders (July 1, 2025 - July 3, 2025)
  - Fix Defects and Perform Regression Testing (July 3, 2025 - July 5, 2025)
  - Validate Non-Functional Requirements (Performance, Security) (July 5, 2025 - July 7, 2025)

Dependencies: Data migration completed
Milestone: Testing completed (July 7, 2025)
Responsible Role: System Architect, Data Engineer, Stakeholders (Donors)

Methodology

==C6: Five charities won’t change address==

image.png

Methodology: Agile Development - Scrum

Project Characteristics

- There are differences in the systems of charitable organizations of different sizes.
    
- Delivery within a specified time frame (10-month deadline).

- The system needs to create rapid responses in case of improving the donor experience.
    

Scrum focuses on cross-organizational requirement integration and iterative delivery. Some requirments may unclear due to difficuty communicating to potencial and auctual donors.
The project involves organizations of different sizes and technical levels in different area. There is need for clear short time schedule, Scrum can provide schedule visibility
The new system should reliable and plan long-term use. Scrum can provided long-term itration and fully test.

Team

image.png

image.png

image.png

==C5: Assume project Sponsor is Project Manger==

1. Project Manager (1 person)
Responsibilities: Oversee project execution, ensure the project is completed on time, within budget, and within the defined scope within 10 months. Facilitate communication with stakeholders and manage project risks.  
Reason: The project needs to ensure completion by having both the big picture and details, and it must coordinate team resources, manage complex system differences, and address stakeholder interests to ensure that integration meets business requirements. The project manager ensures that integration aligns with business needs by coordinating resources across different charitable organizations.

2. Business Analysts (2 people)
Responsibilities: Focuses on business issues.  
Collect and document requirements from five charitable organizations through workshops, interviews, and demonstrations. Review and design business processes to ensure they meet the requirements.
Reason: During the integration process, there may be issues with existing business processes being unreasonable, incompatible, or unable to meet the requirements. Business analysts need to integrate all functions and translate user needs (such as the unfamiliarity of small organization users with complex systems) into feasible technical requirements.

3.System Architects (2 people)
Responsibilities: Design the system architecture, focusing on scalability, security, and integration with legacy systems. Define data models and interfaces to unify different infrastructures.  
Reason: The project needs to integrate five different systems, including spreadsheets from small local charities and complex systems from two large charities. The system architects utilize the integration of large systems to incorporate the functionality of smaller systems. Their design ensures the system supports reporting functions and data import from spreadsheets.

4. Data Engineers (3 people)
Responsibilities: Responsible for data migration, including extracting, cleaning, transforming, and integrating donor and donation data from five systems into a unified database.  
Reason: The data formats across the five charities vary significantly, ranging from spreadsheets to full databases. Data engineers use technical documentation from large systems to extract data, while cleaning and transforming data from spreadsheets to meet a 95% data quality goal within three months.

5. UI/UX Designers (1 person)
Responsibilities: Design an intuitive and user-friendly interface for users from five charitable organizations, ensuring system usability and adoption.  
Reason: Small local charities lack IT staff, and employees are unfamiliar with complex systems. The UI/UX designer creates a simple interface that integrates the complex features of large systems, ensuring all users can easily navigate and use the system.

Requirement defination

image.png

Requirement definition: Charities System

Non-Functional Requirements

1. Performance:

1.1 system responses less than 2 seconds 

1.2 system handle 30 number of users 

1.3 system handle 5000 number of donations

1.4 system support for 20 additional charities.

2. Security:

2.1 system backup data once a week

2.2 system update user permissions once a month.

3. Usability:

3.1 system can be used in windows and ios environment

3.2 system can be used in computer phone and laptop

3.3 system support remote working and field operations.

4. Maintainability:

4.1 system update documentations everyday

5. Compliance:

5.1 system complies data protection and privacy laws (e.g., GDPR, CCPA).

5.2 system accessible to users with disabilities, follow the rules WCAG 2.1. 

Functional Requirements

1.Technical staff Actions:

1.1 Technical staff can create donor records.

1.2 Technical staff can update donor records.

1.3 Technical staff can delete donor records.

1.4 Technical staff can record donations from potential donors.

1.5 Technical staff can record donations from actual donors.

2.Searching:

2.1 Company managers can search using name ,address, or contact details

3.Email sending:

3.1 Mailbox managers can send email to potential and actual donors.

3.2 Mailbox managers can track email with potential and actual donors.

3.3 Mailbox managers can get others email feedback

4. Document 

4.1 Document managers can generate reports on campaign performance.

4.2 Document managers can migrate documents 

4.3 Document managers can categorize documents
Requirements analysis strategies

image.png

Requirement Analysis Strategies: Problem analysis, Outcome analysis, Duration analysis

reason: The project is sensetive to time it's must finished on time, excute on Duration analysis can make sure app can finished on time.
As an integerate project Problem analysis is necessary, modlling existing system and find requirements relavent to problem. 
New System should meet users need, It's necessary to excute Outcome analysis to make sure system is required by users
Require Gathering Techniques

image.png

Requirement Gethering Techniques: Using Joint Application Development (JAD) Method 
Stakeholders from the five organizations will be gathered together for a series of collaborative workshops based on the current charity organization process. The workshops will follow business assumptions (including guesses about the causes of current problems and methods to optimize business processes) and will propose a solution process.

During the workshops, employees will demonstrate system processes on-site, using practical operations to fill the documentation gaps of some organizations. Given that this project has a 10-month time limit, JAD allows for the synchronized verification of requirements across all organizations and real-time conflict resolution. This structured collaboration accelerates requirement gathering and reduces delays caused by repeated communication. Since this system needs to mitigate the risks associated with users' understanding of system usage, JAD ensures the project is designed with the user at the center and helps small organization employees become familiar with the large organization’s system.

Reason: As a integrate project actual donors need on board, requirements should focus on improvements and to-be
JAD allow to get Deep information and easy to combine information together with low cost. Most improtantly, usesr can highly involve in project

StakeHolder

Senior Management of integrade charity
    The existing system increases the difficulty of donor and organizational management, raising the management costs of the merged organization. The new system will optimize the organization's costs.
    
Donors and Potential Donors 
    The existing system is fragmented, and the donor experience is inconsistent. The merged new system will enhance the donor experience.
    
Organization Staff 
    The new system's email functionality will improve staff experience, since missing functionalities in some systems, staff face communication challenges with donors or potential donors, and inconsistent database data creates many difficulties in their work.  and a unified database will reduce maintenance costs.
    
Volunteers and Partners
    The new system will allow the charitable organization to respond more quickly to partners.

2 - Business Process Modelling with Activity Diagrams and Business Process Model and Notation (BPMN)

3 - Intro to Systems Analysis and Modelling

What is System

There are two jobs mainly for system

  • achieve goals
  • MOST IMPORTANTLY add value to existing system

A system generally contain 2 character, user and developer. Developer can get value from user and user needs will accomplished from system

For programmer build a system using code. before writing they need a plan.

SDLC

This is the MAIN concept of modelling requirement and analysis, which is the key part of hole lesson. we will talk deeply in later chapter

image.png

image.png

the workflow called Systems Development Life Cycle (SDLC), it’s a process of gradual refinement Each phase consists of a series of steps and Each phase is documented (deliverables) Phases are executed sequentially, incrementally, iteratively or in some other pattern

This 4 phase is BASIC concept, a common view is during entire develop life, developers should review and revisit in multi times, when and in which order?

Project Methodology

https://www.virtasant.com/blog/sdlc-methodologies

SDLC Methodologies are processes and practices used by software development teams in order to successfully navigate the Software Development Life Cycle (SDLC).

let’s skip old-fashioned methodology

Throwaway-Protyping

building initial ideas for different applications, interfaces, or functions, without necessarily having the intention of including them in the finished system.

the idea is to gather feedback, prove concepts, or undertake other research tasks.

image.png

image.png

Agile

image.png

Agile is the mainstream methodology used in modern software development The Agile methodology breaks a project down into multiple cycles, each passing through some or all of the SDLC phases.

Scrum

Scrum Framework provided a Practical way of Agile

image.png

image.png

kanban

kanban is another framework of agile

image.png

Kanban is a scheduling system framework, Kanban has a host of benefits when applied to Agile. You can limit WIP, focus on cycle time, and utilize just-in-time practices.

Kanban is sometimes compared to Scrum, which are similar in some ways, but are distinct frameworks:

  • Scrum utilizes fixed length Sprints cycles while Kanban is about continuous flow
  • Scrum is role focused, while Kanban doesn’t utilize roles
  • Scrum measures velocity, while Kanban focuses on cycle time
Extreme Programming

image.png image.png

Planning Phase

Process and Document in Planning phase

image.png

image.png

Planning Phase - Current we focus on Initiation

  • system request
  • feasibility analysis

image.png

System Request

A document that describes the reasons for and the value new system will add

This is the first step in the SDLC process

phases on System Request

image.png

image.png

Let’s get clearify here

  • Who recommend to build - sponsor
  • Why to build - business need
  • What the build provided - business requirement
  • What value build provided - business value
  • Other

Notice: This is non-technic focus, emphasis on business aspects

Examples:

business need:

image.png

image.png

image.png

business requirement

image.png

image.png

image.png

business value

image.png

Feasibility

Once the need for system is finished, Project need more detail file

image.png

Time is a management issue, We ignored here Most team revise study during SDLC and revisit content at every check points Team may cancel the project or create substantial revisions

Technical Feasibility

image.png

image.png

  • familiar business application area
  • familiar with the technology, delay will cause when learning new technology
  • project size
  • compatibility, most cases we build a system on existing system

The assessment of a project’s technical feasibility is not cut and dried. In many cases, some interpretation of underlying conditions is needed

  • one is to compare prior projects undertaken by orgnization
  • another is to consult with IT professionals or external it consultants

Examples:

Business area

image.png

familiarity with technology

image.png

project size

image.png

compatibility

image.png

Analysis Phase

Required Gathering

The most critical step for SDLC. when trying develop a system. Good method of requirement gathering can prepared

high vs. low requirement

image.png

Techniques within Requirements-Gathering

image.png

Lab & Exercise 1

Documenting Lab1

Overview: A wealthy entrepreneur and art lover has decided to create an online system called ArtSpace, to assist in the display and sale of works of art. She has employed you to create a design for the system. The system is intended to bring together a range of different user groups who are interested in art sales and purchases: artists; art dealers; serious art buyers and collectors; and casual members of the public who may consider buying art works on occasion.

4 - Scenarios and Use Cases

Use-case

The use-cases symbol on the use case diagram shows what the actor wants to do. Not how that user goal is achieved,

Each Use-cases describe how event triggers actions performed by the system and the user. Everything can be thought of as a response to trigger event. When a trigger event occurs, the system performs the actions defined in the use-case.

Lab2

Tutorial 2: Gathering Requirements for your chosen Case Study (no formal submission needed)

This week you can do the requirements gathering for one of the design briefs (mentioned in Assignment 1 – where you have to choose the design brief based on your family name). List these requirements appropriately (e.g. create requirements definition report).

image.png

first try:

lab2.drawio.png

Lab3

What is UML? Why do we need this?

Unified Modeling Language, is a standardized modeling language consisting of an integrated set of diagrams, developed to help system and software developers for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems.

 techniques to automate the production of software and to improve quality and reduce cost and time-to-market.  techniques to manage the complexity of systems as they increase in scope and scale. In particular, they recognize the need to solve recurring architectural problems, such as physical distribution, concurrency, replication, security, load balancing and fault tolerance.  (UML) was designed to respond to these needs.   What does a use case diagram represent and what are the different elements of a use case diagram?

A Use Case Diagram in Unified Modeling Language (UML) is a visual representation that illustrates the interactions between users (actors) and a system.

It captures the functional requirements of a system, showing how different users engage with various use cases, or specific functionalities, within the system.

Actor, UseCase, SystemBoundary

What are we documenting when we place a use case on the diagram?

What are we documenting when we place an actor on the diagram?

Which of the following could be an actor found on a use-case diagram? Why? o Ms. Mary Smith

o Supplier

o Customer

o Internet Customer

o Data Entry Clerk

o Database Administrator

How is use-case diagramming related to functional modeling?

Why do we draw association lines between actors and use cases?

4.1 - lab3

Use-case Description

A user-side function model. not sequense model

Do not internal system components into user-side model. It’s no useful to users

an use action is connected with a straight line

5 -

方法签名 前置/后置/不变 image.png image.png

代码复用

image.png

设计模式

image.png

框架

image.png

不必重造轮子 新技术会携带风险

image.png

风险: 依赖不可控

优化代码

image.png

fan-out 和 fan-in image.png

image.png

触发器

image.png

对象设计不要用流程语言

Contracts 接口

image.png image.png

接口由约束和返回值组成

接口表述 image.png image.png

接口语言

image.png

接口中约束的类型

image.png

接口实例

image.png

6 -

系统架构

软硬间如何结合?软件如何运行

  • 架构种类
    • 软件架构
    • 硬件架构
    • 系统架构
    • 信息架构
    • 企业架构 image.png
  • 组件

image.png

什么是系统架构

image.png

使用CORBA语言的架构

经典的3层架构 image.png

经典的3层架构

image.png

经典的数据分发可能逻辑层很小 image.png

或者很大 image.png

展示层 需要接口与用户互动 image.png image.png

基于服务器架构,终端是笨主机 image.png

image.png

基于客户架构 image.png

image.png

CS架构 image.png

轻型客户端 - 云上应用 重型客户端 - 本地应用

image.png