To avoid missing any important requirements, please review the following checklist carefully before submission.

Assignment Deliverables

Students are required to complete the following:

1. One blog post

   • Include a clear table of contents.
   • Make sure all required scoring items are covered.

2. One Software Requirements Specification (SRS)

   • Submit an electronic Word version.
   • Upload it to GitCode or GitHub and provide the link in the blog post.
   • It is recommended to also export the document as a PDF for easier access.
   • This document should further improve the requirements specification completed in the previous assignment.

3. One Requirements Analysis Presentation (PPT)

   • Used for the in-class presentation.
   • Upload it to GitCode or CSDN and provide the link in the blog post.
   • It is recommended to also export the presentation as a PDF.

---

Deadline

The deadline for this assignment is October 18, 2026, at 23:59.

Blog review may take time, so please publish your blog post in advance.

---

1. Assignment Content

1.1 Scoring Rules

The total score consists of three parts:

Total Score = Presentation Score + Blog Score + Document Score

The Presentation Score is calculated as follows:

Presentation Score = Peer Evaluation × 25% + Teaching Assistant Evaluation × 35% + Instructor Evaluation × 40%

More specifically:

• Peer Evaluation
  = Total score given by all other groups ÷ (Total number of groups − 1) × 25%

• Teaching Assistant Evaluation
  = Total score given by all teaching assistants ÷ Number of teaching assistants × 35%

• Instructor Evaluation
  = Total score given by the instructor(s) ÷ Number of instructors × 40%

For example, if Group 1 gives a score of 80 and Group 2 gives a score of 90, these scores are included in the peer-evaluation component.

---

1.2 Blog Content

1.2.1 Team Division of Labor

Describe the division of labor within the team and the contribution percentage of each team member.

Please use the following Markdown table:

Student ID	Task Description	Contribution

1.2.2 Software Requirements Specification

Provide the Software Requirements Specification as an attachment or link in the blog post.

Note: The full Software Requirements Specification does not need to be presented in the PPT.

Requirements

1. Refer to the relevant national standard for a Software Requirements Specification and prepare an SRS for your project.

2. In addition to following the required document format, the content should focus on the actual project and describe the software to be developed as clearly, completely, and accurately as possible.

3. Use a hierarchical structure. As the document goes deeper into each level, the description should become more detailed and specific.

4. Use consistent graphical symbols, terminology, and writing conventions throughout the document.

5. Define all abbreviations before or when they first appear.

6. The document should:

   • Include a table of contents.
   • Use consistent and professional Word formatting.
   • Combine text with appropriate figures or diagrams.
   • Maintain a unified visual and writing style.
   • Use appropriate fonts, font sizes, line spacing, and paragraph spacing.

7. Review the document from the reader's perspective:

   If someone who is unfamiliar with your software project reads this document, can they fully understand what the software is intended to do?

8. Whenever possible, interview or consult real users of the software project to ensure that the system reflects actual user needs and provides a foundation for the final usability of the software.

1.2.3 Team Organization and Schedule

Clarify the following:

• Team organization method.
• Division of labor among members.
• Approximate project schedule.
• Specific responsibilities of each member.
• Workload proportion of each member for this document task.

1.2.4 Team Collaboration

To strengthen teamwork and collaboration, describe how team members cooperate during the assignment.

This may include:

• Task allocation.
• Progress synchronization.
• Document collaboration.
• Communication methods.
• Integration and review of team members' work.

1.2.5 SRS Checklist

Before submission, check whether the following items are complete and consistent:

• Introduction.
• User scenarios.
• Class diagrams.
• Interface prototypes.
• Functional descriptions.
• Acceptance and verification criteria.
• Figures and tables.
• Text formatting.
• Overall document style.

The figures, text, formatting, and writing style should be unified and comply with the required specifications.

---

2. Assignment Evaluation Items and Scoring Rules

Total Score: 100 points

2.1 Blog Writing — 20 points

[Course Objective 7]

• 5 points: Correctly provide links to:

  • The Software Requirements Specification.
  • The Requirements Analysis PPT.

• 5 points: Use Markdown to format the blog properly.

• 4 points: Analyze possible key points and challenges encountered during the assignment.

• 6 points: Describe:

  • The division of labor among team members.
  • The contribution percentage of each team member.

2.2 Team Collaboration — 16 points

[Course Objective 6]

To strengthen teamwork and collaboration, describe the collaboration methods used by team members in the blog.

The description may include:

• How tasks are assigned.
• How team members communicate.
• How documents or code are collaboratively maintained.
• How progress is tracked.
• How work is reviewed and integrated.

2.3 Software Requirements Specification — 44 points

[Course Objective 2]

The document should clearly describe the design ideas, problems encountered, and solutions adopted during the implementation process.

Item	Points
Introduction	4
User Scenarios	10
Class Diagram	10
Interface Prototype	10
Functional Description	5
Acceptance and Verification Criteria	5
Total	44

If some content cannot be completed at this stage, clearly indicate this in the document.

After the relevant work is completed, improve the document accordingly and explain the updates in a later assignment blog post.

2.4 Presentation — 20 points

Course Objective 2 — 8 points

• 2 points: Purpose, significance, and background of project development.
• 6 points: Project research and development content, including the class diagram.

Course Objective 6 — 4 points

• 4 points: Execution of the team plan, division of labor, and workload proportion.

Course Objective 5 — 8 points

• 4 points: PPT quality.
• 4 points: In-class presentation.

---

3. Rules and Formatting Requirements

3.1 Blog Table of Contents

To facilitate reading and grading, provide a table of contents at the beginning of the blog post.

The blog should contain at least the following major sections, or sections with equivalent meanings:

• Team Division of Labor
• Software Requirements Specification

You may personalize the exact wording of the headings.

---

3.2 Basic Information at the Beginning of the Blog

To help instructors or teaching assistants from other institutions understand the course context, include the following information at the beginning of the blog:

Item	Content
Course	<Course Link>
Assignment Requirement	<Assignment Requirements Link>
Team Name
Assignment Goal	<Specific Goals>
Other References	...

---

3.3 Submission Rules

• The blog submission time is determined by the submission time shown on the course assignment page.
• Files that need to be submitted through GitCode are evaluated according to the corresponding platform submission time.
• Assignments submitted before the deadline receive their actual score.

Blog Review

If the blog post has already been published but is still under review and temporarily returns a 404 page, you may submit the blog link to the assignment page before the deadline and wait for the review to be completed.

Upload or Network Problems

Late submissions caused by upload failures, network problems, or similar issues will not be accepted as exceptions.

Please complete the publication and submission process in advance.

Late Submission

Submitting within two days after the deadline is considered a late submission.

Late Submission Score = Actual Score × 50%

Completing the assignment but forgetting to submit it is treated the same as any other late submission.

Missed Deadline

Failing to submit the blog within two days after the deadline is considered a missed assignment.

Score: 0

Assignment Plagiarism

If the teaching assistant finds that two blog posts contain overly similar text, images, code, or other content, both submissions will be considered plagiarized.

Score: −100%

Note: This is a negative score.

Forgery of Submission

Submitting an incomplete blog post only to occupy a submission slot will be considered a forged submission.

Score: 0

Early Submission

For assignments submitted in advance, students are encouraged to actively respond to feedback from teaching assistants and instructors and make corresponding revisions before the deadline.

Improvements completed before the deadline may be taken into account during grading.

---

4. Questions and Clarifications

If any assignment requirement is unclear, or if you have questions about the assignment, please ask in the QQ group or WeChat group.

---

Appendix: Reference Structure for the Software Requirements Specification

The following structure may be used as a reference.

Table of Contents

1. Introduction
   1.1 Purpose
   1.2 Project Background
   1.3 References

2. Overall Description
   2.1 Objectives
       2.1.1 Development Intention
       2.1.2 Application Goals and Scope
       2.1.3 Product Prospects

3. Specific Requirements
   3.1 Class Diagram
   3.2 Properties
       3.2.1 Availability
       3.2.2 Security

4. Interface Prototype

5. Functional Description and Acceptance/Verification Criteria
   5.1 Detailed Functional Description
   5.2 Input and Output Format
   5.3 Interface Acceptance Criteria
   5.4 Functional Acceptance Criteria

---

Reference Example

1. Introduction

1.1 Purpose

The purpose of this project is to implement DES-RSA hybrid encryption.

For the development team, the project can improve Java programming skills and combine programming practice with knowledge of cryptography, laying a foundation for future professional study.

For potential users, the software provides a way to perform basic daily file encryption.

1.2 Project Background

• Software Name: DES-RSA Hybrid Encryptor
• Project Task Proposer: Teacher Lou
• Project Developer: AWN Team

1.3 References

• Teacher Registration System Requirements Specification
• "Buy Together" Requirements Specification

---

2. Overall Description

2.1 Objectives

2.1.1 Development Intention

Use UI technology to provide a graphical interface for DES-RSA hybrid file encryption, allowing users to complete file encryption through simple operations.

2.1.2 Application Goals and Scope

This system is intended for students interested in cryptography and supports basic encryption of .txt files.

2.1.3 Product Prospects

The current system provides relatively basic functionality, but the overall framework has been completed. Additional features may be added as the team learns more related knowledge.

---

3. Specific Requirements

3.1 Class Diagram

Provide the class diagram corresponding to the project design.

3.2 Properties

3.2.1 Availability

1. The system should be easy to operate and understand.
2. The interface should be simple and user-friendly.
3. The system should provide a certain level of fault tolerance and robustness.
4. When the user enters data in an incorrect format, the system should display a prompt and allow the user to enter the information again.

3.2.2 Security

Keys, ciphertext, and other files exported while the program is running should be stored in a secure folder.

---

4. Interface Prototype

The interface prototype has not yet been implemented and will be added later.

---

5. Functional Description and Acceptance/Verification Criteria

5.1 Detailed Functional Description

The system should support the following functions:

1. Import plaintext files from the local computer.
2. Allow the user to select the bit length of prime numbers p and q during RSA encryption.
3. Use 200 bits as the default length for p and q.
4. Export prime number p.
5. Export prime number q.
6. Export public key e.
7. Export private key d.
8. Export decrypted files.

5.2 Input and Output Format

• Imported plaintext file format: .txt
• Exported plaintext file format: .txt

5.3 Interface Acceptance Criteria

User Encryption Interface

Input File Area

• A display box in the center shows the name of the file to be encrypted.
• An Import File button is provided on the right.
• An Encrypt button is provided on the right.

Encryption Module

The interface should include:

• A selection box for the bit length of prime numbers p and q.
• A prompt indicating that the bit length of p and q should preferably be greater than 200.
• A button to generate prime number p.
• A button to export prime number p.
• A display box for p.
• A button to generate prime number q.
• A button to export prime number q.
• A display box for q.
• A button to generate the prime-number pair.
• Buttons to export modulus n, public key e, and private key d.
• A DES key export button.
• Corresponding display boxes for generated information.

Output File Area

• A display box shows the name of the encrypted file.
• An Export File button is provided for exporting the ciphertext.

User Decryption Interface

Input File Area

• A display box shows the name of the file to be decrypted.
• An Import File button is provided for importing the ciphertext.

Decryption Module

• An input box is provided for entering the password or corresponding DES key file.

Output File Area

• A display box shows the name of the successfully decrypted file.
• An Export File button is provided for exporting the plaintext.

5.4 Functional Acceptance Criteria

The system should correctly implement all functions described in the interface and functional requirements.