information system homework
Project Submission Guidelines I355
Note that this material includes things previously submitted for grading. This re-submission gives you the opportunity to update and improve previous submissions for a better grade.
Grading Guidelines:
· Group Components: Problem Statement, use case diagram, class diagram, design class diagrams, and relational schema are graded as a team for all the members . That is, all the members will get the same grade for these components.
· Individual Components: Use case diagram and description, and system SQD, the full SQD is not required, are graded individually . That is, each member will get a different grade for these components. Members of a team, however, can help develop/review those model components each other, but each member is responsible for his/her own component for them. Note that the SQD must be based on the use case description developed by each member. Because these components are individually graded, you must specify your name at the top of each of these components for an easy identification.
Project Documentation
Title page (title of your topic, all the member names, term identification)
Contents (section heading and the page number the section begins)
Introduction (1 page summary of the whole project)
System Analysis
(1) The Problem Statement (Goal, importance, IN-scope, OUT-scope)
(2) Requirements
2.1 Functional Requirements
2.2 Data Requirements
2.3 Business Rules and Logic
2.4 Non-Functional Requirements (NFRs)
2.4.1 Usability,
2.4.2 Reliability
2.4.3 Performance
2.4.4 Security
2.4.5 Other NFRs
2.5 Other Important Assumptions
(3) Use Case Model
3.1 Actors and Their Goals
3.2 Use case diagram
3.3 Overview section of all use cases
3.4 Use case description for a primary use case and its included use cases (one primary use case per team member. Note that this includes all the included use cases of the primary use case. There must be a separate template for each included use case. Put each member name for each use case description)
3.5 Validation & Discussion (modeling decisions, alternative solutions to the model and other important clarification)
(4) Class Model
4.1 The class diagram with classes, associations and major attributes (Called Analysis class diagram or domain model). Generalization and aggregation can be used if right.
4.2 Selected Class definitions for those whose class names are not intuitive. (e.g., the meaning of a class name that is not intuitively understood should be explained. If you have any doubt – explain the name.)
4.3 Selected Association definitions for the following three cases: (a) when association names are not intuitive, (b) when there are two or more associations between the same two classes, and (c) recursive associations.
4.4 Validation & Discussion (modeling decisions, scenarios used, alternative solutions to the model and other important clarification of the class diagram)
System Design (For each member of the team, Item (5) must be repeated)
(5) A system sequence diagram of the chosen use case (Each member must show his/her own system sequence diagram for the use case description of the chosen primary use case. Use the main scenario of the primary use case. Put the member name on the top of the system SQD.)
(12) Evaluation of Analysis & Design (evaluation of the project, domain, diagrams, the UML and the modeling tools used, quality of the specification)
(13) Lessons learned (Write one or two paragraph for each team member)
(14) References (if in doubt, consult the library for acceptable formats.
(15) Appendix
A. Division of the work among team members
B. Unsolved problems (Any questions related to A&D activities you still have)
Validation & Discussion section should include:
· Explanation of the model so that readers can understand the model better rather than just a diagram
· Comparing multiple alternatives of the model and the justification of your chosen model
· Summarizing any remaining problems or issues regarding to the model
Evaluation of Analysis & Design should include
Evaluate the domain you selected, complexity of the problem, methods used, UML itself, Rose or Visio, team work, things to do more if you have more time, and things to do differently if you redo the project, etc
Project Deliverable and Submission
All the projects must submit a soft copy:
(1) The most important principle for project documentation is to make it a reviewer-friendly .
a. Add page numbers;
b. Add member name in front of use case description, and SQD.
c. Make diagrams readable; Enlarge the diagrams to the full page; show it in landscape format if necessary
d. In class diagram, make sure the multiplicity of each association must be shown clearly and distinguishable for each association.
(2) Create a single final report, in Word (not PDF), which consolidates all the diagrams in the right order as outlined above. That is, collect all the diagram files from all the members and copy and paste them into the final report file. Organize them with a clear label in a reviewer-friendly manner. Add page numbers.
(3) Use the naming convention of 355-yourLastName_or_team_name-acronym-of-your-project.docx. That is, by reading your file name, I should be able to easily identify your term and project topic. Email me the word file drott@drexel.edu
(4) Submit project and peer evaluation form (PEF) to via email. Use the naming convention of 355-PEF-yourLastName_and_team_name-acronym-of-your-project.doc
