Overall Organization and Presentation

• Report should be coherent and well organized following the provided report template.

• Grammar, spelling, punctuation and formatting should be flawless, which allows the reader to focus on the message.

• Figures and tables should be numbered appropriately and captions should be used to explain the corresponding figures and tables.

System analysis:

• Requirements:

  • Important requirements should not be missed.

  • Requirement statements should be clear (there should be no ambiguity).

  • Requirement statements should be written using a consistent style.

  • Non-functional requirements should be measurable (fit criteria should be defined).

  • Requirements should be well-organized. Merely listing a large number of requirements without any organizing effort should be avoided.

  • Types of requirements should be defined (functional, non-functional, and design constraints)

  • Requirements should be abstract (avoiding making unnecessary design decisions).

• Use Case Model:

  • All use cases should be found. The elaborated use cases should meet all functional requirements.

  • Use cases should have unique, intuitive, and explanatory names.

  • The UC diagram should use correct UML notation.

  • Use case relationships should be correct (e.g., includes and extends relationships).

  • Use case descriptions are not required.

Design and Architecture:

• Architecture Design:

  • Logical layers/subsystem design should be clearly defined.

  • The design should show relationships/connections between layers/subsystems.

  • Appropriate architectural style should be chosen. The choice should be justified.

  • Alternative styles should be discussed (if applicable).

  • Constraints that affect the way the architecture can be implemented should be discussed (if applicable).

• Detailed Design:

  • Detailed class diagram should be based on the analysis classes identified earlier.

  • Detailed information of each class should be clearly defined such as:

    • Data attributes

    • Operations (parameter and return types should be defined)

    • Data structures

    • Algorithms (if applicable)

  • Database design should describe the necessary tables and columns.

Testing:

• The test approach should be thoroughly described. For each major set of features, the approach should specify the major activities, techniques, and tools which will be used.

• Functional testing should include fairly enough test cases.

• Some functional testing should be derived from use cases. Some test cases should be generated to cover enough scenarios of some use cases.

• Some functional testing should be derived based on inputs for some screens. For each input, equivalence classes should be defined and boundary values should be used to define the test cases.

• Some unit testing and code coverage (white box testing) should be demonstrated.

• Some usability testing should be demonstrated.

• A tool such as JUNIT, Clover, or Code Cover should be used for unit testing.

• Screen shots should be used to show results for some test cases.

• Screen shots should be used to show the output of applying the testing tools.

System implementation:

• Technologies used should be adequately described. These include database systems, programming languages, development platforms, runtime environments, servers, operating systems, etc.

• Mapping of code to requirements or use cases should be adequately described. Mapping description should include the names of methods or classes that implement the corresponding requirement or use case.

• In the Implementation Details subsection, the students should present a walkthrough through the main program logic. The students should include several screen shots showing the GUI interface and code snippets showing the program logic.

• The walkthrough should show the starting point and then should cover the program logic for the most important functions.

• The walkthrough description should be enough to help the reader understand the source code.

The following are characteristics of excellent work on the corresponding key criteria in the evaluation of the written report part of SWE 496 – Graduation Project Evaluation Form.

Overall Organization and Presentation

• Report should be coherent and well organized following the provided report template.

• Grammar, spelling, punctuation and formatting should be flawless, which allows the reader to focus on the message.

• Figures and tables should be numbered appropriately and captions should be used to explain the corresponding figures and tables.

QA Plan

• The quality plan should list the types of reviews (inspections, walkthroughs, etc.) that will be performed.

• Sample written reports of the review findings and follow up on the inclusion/correction of all findings should be included.

• The testing section should include a rough test plan. The test plan should also define several test cases for the important use cases.

Realistic constraints and risk assessment

• Constraints:

  • Relevant technical and/or resource constraints should be listed.

  • Listed constraints should be professional; personal and subjective constraints like “we have several courses this session” should not be mentioned.

• Risk Assessment:

  • Relevant technical, human resource, and project stakeholders and environment’s risks should be listed.

  • Likelihood and impact should be numerically stated.

  • Avoidance and/or mitigation plans should be determined.

  • Monitoring procedures should be clearly defined.

System analysis Requirements:

• Requirements:

  • Important requirements should not be missed.

  • Requirement statements should be clear (there should be no ambiguity).

  • Requirement statements should be written using a consistent style.

  • Non-functional requirements should be measurable (fit criteria should be defined).

  • Requirements should be well-organized. Merely listing a large number of requirements without any organizing effort should be avoided.

  • Types of requirements should be defined (functional, non-functional, and design constraints)

  • Requirements should be abstract (avoiding making unnecessary design decisions).

• Use Case Model:

  • All use cases should be found. The elaborated use cases should meet all functional requirements.

  • Use cases should have unique, intuitive, and explanatory names.

  • The UC diagram should use correct UML notation.

  • Use case relationships should be correct (e.g., includes and extends relationships).

  • UC descriptions of basic and alternative flows should be clear and correct. In particular, use case preconditions and post-conditions should be stated correctly.

  • UC descriptions of basic and alterative flows should be abstract (avoiding making unnecessary design decisions). In particular, statements like ‘click a button’, ‘move mouse’, ‘open window’, etc. should be avoided.

• Analysis Class Model:

  • An interaction diagram (sequence diagram) should be used to develop the analysis class model individually for every important use case.

  • Analysis class diagram should use correct UML notation.

  • Analysis class diagram should include all necessary boundary, control, and entity classes.

  • Analysis classes should include all necessary attributes and operations. Attribute types and method signatures need not be defined at this stage.

Design and Architecture:

• Architecture Design:

  • Logical layers/subsystem design should be clearly defined.

  • The design should show relationships/connections between layers/subsystems.

  • Appropriate architectural style should be chosen. The choice should be justified.

  • Alternative styles should be discussed (if applicable).

  • Constraints that affect the way the architecture can be implemented should be discussed (if applicable).

• Detailed Design:

  • Detailed class diagram should be based on the analysis classes identified earlier.

  • Detailed information of each class should be clearly defined such as:

    • Data attributes

    • Operations (parameter and return types should be defined)

    • Data structures

    • Algorithms (if applicable)

  • Database design should describe the necessary tables and columns.

Mock-up Interface:

• User interface mockups should be used to illustrate the most important use cases.