The seventh assignment - team topic selection report and needs analysis

Complete the following two-part tasks:

 

1: Topic report

 

1. Publishing documents:  A team only needs to publish an article to the Yizhi team project, and the content is the team's topic selection report. The topic selection report should focus on the following aspects (30'):

  • Project Description
  • Innovation and Benefit [See Law of Construction Chapter 16: Innovation in the IT Industry]
  • User Analysis [see Method of Construction Chapter 10: Typical Users and Scenarios]
  • Real User Surveys [See Method of Construction Chapter 8: Requirements Analysis]
  • Market and Competition in the future [see Method of Construction Chapter 8: Demand Analysis]

2. Record a video: Record a video to describe your product, or find some real users for interviews, in any form. (15'), you can upload it to Youku and insert it into your course.

3. Classroom presentation: You can prepare a topic selection report PPT for classroom presentation, or you can directly use the blog for presentation; (50')

Special note: The topic selection report + requirements specification ( workflow , division of labor , and workload ratio of team members ) should be displayed at the same time in the classroom presentation.

4. Review preparation: prepare a review form (word electronic version + double-sided printed paper version, according to the above % ratio, the staff workload is the score ratio). (5')

suggestion:

  • (1) Scope and source of topic selection: Expound on the real, usable, and valuable (feeling as a plus) goal of the selected topic content.
  • (2) Programming language: not limited, but preferably all members of the same group use the same programming language, or give reasons;
  • (3) Format: PPT, easy to know or direct use of blog display;
  • (4) Time: 15 minutes for each group, including 7 minutes for presentation time and 8 minutes for responding to the questions and inquiries of each group. (The specific time will be adjusted according to the final number of groups)
  • (5) Scoring method:
    1. Each group submits a simplified review form for all groups (including its own), including:
      • a) Team number, project name, names of all team members, and review content;
      • b) The score of each group (percentage system);
      • c) Reasons for scoring, including: format, content, PPT, speech, advantages, existing problems (at least 3 points), suggestions, etc.; (respect other groups, score carefully, and ask for truth from facts, scores can truly reflect the quality of the report, and it is forbidden to be flat in one pot. Case);
      • d) Make your own table (word) and submit the word print version;
    2. Additional points for teachers: Provided to the group who asked positive questions, had quality questions, or had special surprises in the defense questioning;
    3. The team leader provides the proportional weight of each team member's current team work.

Reference link

Topic selection report reference template

http://www.cnblogs.com/buaase/p/4895900.html

http://www.cnblogs.com/easteast/p/6203452.html

http://www.cnblogs.com/CSLaker/p/5907123.html

Video reference link

http://www.cnblogs.com/yuaoi/p/5906969.html#_label2

Two: Requirements Specifications

Teamwork - Requirements Specification

Job description

1. Publish a document: A team publishes a document to the Yizhi project. word backup.

Essay description:

  • Describe the  workflow , division of labor , and workload ratio of team members for writing  requirements specifications ;
  • Provide  the Git link of the "Requirements Specification"  (markdown file and pdf file, tip: pdf can be obtained by the markdown to pdf tool).

The Requirements Specification requires:

1. Refer to the national standard text of "Software Requirements Specification" to write the software requirements specification for the corresponding project.

2. In addition to meeting the requirements of the normative text in form, the overall content must focus on the substance of the project, and ensure that the project to be developed is as clear, complete and accurate as possible.

3. It is described in layered form. With the deepening of the "layer", the details of the description are more specific.

4. Use consistent graphic symbols and text to describe content.

5. All abbreviations must be defined in advance.

6. With pictures and texts, the whole document has a unified style (for this md file, everyone in the team is required to make a corresponding commit, as the first attempt of team development).

7. Put yourself in the reader's position - if people who are not familiar with the software project can fully understand what the software does by reading this document.

8. Access the real users of the software project to ensure that the software truly reflects the needs of users and lays the foundation for the final availability of the software.

9. The subdivision functions, boundary ranges, etc. described in the requirements specification are limited to the functions that can be achieved at the end of the semester , and the final defense acceptance will be conducted against the requirements specification. The highlights and the functions expected to be completed in the future can be described in a separate chapter in the requirements specification.

10. For team collaboration and strengthening of division of labor, it is necessary to describe the specific division of labor of each member and the proportion of the workload of the entire document task.

11. Checklist: Introduction (5'), User Scenario (15'), Class Diagram (10'), Interface Prototype (15'), Functional Description (20'), Acceptance Verification Criteria (20'), Document Diagram, Uniform text, style and specification (15')

Reference link

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324946833&siteId=291194637