The reviewer should be able to take each point in the requirements document and find the associated implementation in the design. The reviewer should ignore the quality aspects of the implementation at this point, and only verify whether a requirement is addressed or not. Other questions of the scorecard give you an opportunity to express your concerns about the quality of the design.

Rating 1 - Missing requirement(s) prevent the design from fulfilling the goal of the requirements.
Rating 2 - The design addresses all requirements to solve the problem for which the component was requested, but is missing major features from the requirements document.
Rating 3 - The design addresses all of the  requirements and potentially includes minor additional functionality. The design solves the problem for which the component was requested but either does not provide enhancements on top of the requirements, or the added functionality does not alter the customer’s experience with the component.
Rating 4 - The design addresses all requirements and provides new and substantially useful and pertinent functionality

The reviewer should judge whether the algorithm descriptions are complete, accurate and contain enough information for the developer to properly implement the algorithms. Please note that this review question should judge only the correctness of the algorithm and how well the designer relates the algorithm – the grammar and spelling should NOT be included in this question.  The algorithms stated can be actual code, pseudo-code or even simple textual descriptions, as long as the designer effectively relates the point of the algorithm.

Rating 1 - The component specification is missing a description for any of the algorithms defined in the requirements, or external research is required to understand how to implement any of the algorithms.
Rating 2 - The component specification includes all the algorithms defined in the requirements. However, the description contains logical errors or easily leads to misinterpretations or is generally written in a style that is hard to understand – generally requiring many readings to fully grasp the algorithm. The developer may need external research to fully understand the algorithm.
Rating 3 - The component specification includes all the algorithms defined in the requirements and optionally any ‘complicated’ sections of the design. The description is fairly clear with, at most, minor errors and includes everything needed by the developer to implement without any external research.
Rating 4 - The component specification includes all the algorithms defined in the requirements and any ‘complicated’ sections of the design. The description is clear, contains no logical errors, and can be understood from a single r

The reviewer should be able to take each requirement and find a use case covering it. Use cases must not be too high-level or too low-level. Additional functionality beyond the requirements must be covered by use cases as well.

These rules should be considered when judging the use cases:

a) A use case is something an actor wants the system to do
b) Use cases are always started by an actor
c) Use cases are always defined from the point of view of an actor
d) Use cases are always described by a verb phrase

When a single use case covers multiple unrelated activities, it is considered too high-level. A good indicator of this is a single use case covering multiple points in the requirements document.

Too low-level is defined as multiple use cases covering related activities. For example, providing a use case for each constructor or each version of an overloaded method are considered too low-level.

Use cases must not reveal the intended implementation. For example, a use case of “Read Configuration” should not specify how it reads the configuration (i.e. it should not say “Read Configuration via Configuration Manager,” unless the component provides other user-selectable alternatives for obtaining the configuration without the Configuration Manager).

This question does not address the presentation of the diagrams; only the logical content needs to be considered.

Rating 1 – Only a minority (<= 49%) of the requirements are covered by the use cases.
Rating 2 – A majority (> 49%) of the requirements are covered but at least one requirement is missing and/or the use cases are too high (or low) level in detail as explained above.
Rating 3 – All the requirements are covered at a proper level of detail as explained above.
Rating 4 – All the requirements are covered at a proper level of detail as explained above, and the designer made proper use of in

Sequence diagrams should be included when there are interactions between objects that need to be demonstrated or where interactions are not immediately obvious or where method documentation may benefit from a supplemental diagram.

Interactions involving five or more objects (both system and/or component) are considered complicated.  Designers may include SDs with less than five objects, but they are not required to do so.
This question does not address the presentation of the diagrams; only the logical content needs to be considered for this question.

Rating 1 – Only a minority (<=49%) of the complicated interactions are covered by the sequence diagrams. Identify all complicated interactions without the diagrams in your comments.
Rating 2 – At least one complicated interaction is missing a sequence diagram, or a majority (>49%) of the diagrams are misleading or incorrect. You must either identify the missing interaction or add explanations of how to fix misleading or incorrect diagrams in your comments.
Rating 3 – All the complicated interactions are covered by sequence diagrams, but at least one of the diagrams is incorrect or misleading (missing participants or missing calls on any of the diagrams make that diagram grossly incorrect). You must add explanations of how to fix misleading or incorrect diagrams in your comments.
Rating 4 – All ‘complicated’ interactions have been described by corresponding sequence diagrams, and none of the diagrams are incorrect or misleading. This rating permits minor issues such as mislabeled methods or mismatched parameters or return values to exist in the diagr

g. Model-View-Controller, Factory Pattern, Object Oriented design principles, follows J2EE specs or Microsoft Design Guidelines for Class Library Developers).

The reviewer should determine a few things: Are the patterns/methodologies used 'forced' (i.e. is there good justification for using the pattern or did the designer force the pattern into the design to say they used that pattern). Are the patterns/methodologies implemented correctly (this does not mean completely – the design may justify a partial implementation)? Did the designer show an understanding of the pattern/methodology? Did the designer recognize and document all the patterns used?

Rating 1 – The design consistently uses patterns/methodologies inappropriately, causing potential problems either in implementing the component or in implementing future enhancements to the component.
Rating 2 – An appropriate pattern/methodology was used but the designer showed a lack of understanding in the implementation of it. A pattern/methodology should have been used but was not (name the missing patterns and explain how the design would benefit from using them). A pattern/methodology was 'forced' (name the inappropriate patterns and explain why they are not applicable to the design).
Rating 3 – Appropriate patterns and/or methodologies were used but the designer missed some in the component specification (either missed completely or incorrectly labeled).
Rating 4 – Appropriate patterns and/or methodologies were used and were identified correctly in the component specification. The reviewer should also assign this rating if the design, appropriately, does not need any patterns/methodologie

The reviewer should consider what enhancement/features the next version of the component will likely be or what types of enhancements a client of the component will likely request. The reviewer should then review the future enhancements that the designer included in the component specification for their vision of what the next likely enhancements are. The reviewer should also consider how tightly coupled the classes were or what assumptions the design was built upon when considering how ‘substantial’ the modifications would be.

Rating 1 - The component would need a complete redesign to accommodate reasonable enhancements within the general scope of this component.
Rating 2 - The design could accommodate reasonable enhancements within the general scope of this component, but doing so would require substantial changes to the design.
Rating 3 - The design could accommodate reasonable enhancements within the general scope of this component with multiple simple changes.
Rating 4 - The design could easily accommodate reasonable enhancements to the compone

The reviewer should review the components recommended in the requirements documentation. The designer will need to provide justification (either in the component specification or in the component forum) if they choose not to use the recommendations. The reviewer should also review the TopCoder catalog for any components that could potentially be used in the component design. The reviewer should not be critical of the designer's use, assumptions or lack of details for components that are being proposed in the design or are currently in the design/development stage - as long as the designer has included verbiage in the component specification stating that the design may need to change based on the final 'look' of the dependent component. Please note that any components being proposed or changed by this design is dependent upon permission from the PM.

Rating 1 - The design did not use any of the recommended components and did not give any justification as to why.
Rating 2 - The design used at least one of the recommended components but not all and did not give any justification as to why. Likewise, assign this rating if the designer missed using likely components, used any other component incorrectly, or provided flawed justification as to why a component should not be used.
Rating 3 - The design used all the recommended components correctly but missed using other components that would make the design easier to implement without changing its overall approach.
Rating 4 - The design used all recommended and likely components that fit the designer’s approach correctly. Likewise, assign this rating if components were appropriately not use

Class structure and method names make usage of the API apparent to a new user. Each method has a singular purpose and causes minimal side-effects. Convenience methods should be carefully chosen to simplify the overall API. Excessive use of convenience methods should be avoided.

The reviewer should look at the demo section of the component specification to see the designer's vision of how the component will be used. The reviewer should then analyze how the API addresses the requirements and how easy it is to use the API to accomplish the requirements.

Rating 1 - The API demonstrates an obvious lack of consistency, cohesion, or is generally hard to use. Tasks (as defined by the requirements) take multiple API calls to accomplish what should be done atomically.
Rating 2 - The API is not immediately obvious; one cannot understand how to accomplish the required tasks by looking at the class diagram and reading the demo section (provide the name(s) of the requirement task(s) not easily performed using the API).
Rating 3 - The API is obvious (by looking at the class diagram and the demo section) but could have been made simpler or more powerful/flexible (provide specific modifications to the API that would make it easier to use).
Rating 4 - The API is consistent, powerful, flexible, and is easy to understand. The design of the API is driven by a single concept, making the API easy to learn. The common tasks (as defined by the requirements) are easy to perform using the API

If the component is deemed thread safe, the designer should have documented their approach to thread safety in order to determine if the approach is sound.   The approach can come in two forms:

a) A high level overview written in the component specification and specific detail included in the class/method/variable documentation tabs.
b) A detailed approach written in the component specification and references to it written in the class/method/variable documentation tabs.

If the component is deemed not to be thread safe, the designer should document any reasons why the component is not thread safe and, if applicable, provide a high level summary of what could be done to make the component thread safe.

Rating 1 - There is no mention of whether the component is thread safe or not.
Rating 2 - The designer mentions thread safety but fails to provide the reasoning
Rating 3 - The designer mentions thread safety but is incorrect in the reasoning
Rating 4 - The designer mentions thread safety and provides correct arguments to back it up

The reviewer should determine whether the classes in the design attempt have too large of a scope (it tries to do too many tasks) or has too small of a scope (the task was broken down into too many classes). A good clue to a violation of this is whether the name of the class adequately encompasses the API of the class. If so, then the class is probably properly scoped (unless the name is too generic or too high-level).

Rating 1 - Multiple unrelated groups of related classes violate scope and must be refactored into smaller or larger classes. Describe in your comments the purpose of refactoring for each class or a group of related classes, and state its tangible benefits to the design.
Rating 2 - A single group of related classes violates scope and must be refactored into smaller or larger classes. Describe in your comments the purpose of refactoring, and state its tangible benefits to the design.
Rating 3 - The classes seem fine but at least one class could potentially benefit from being refactored. Describe in your comments the proposed refactoring, and explain what makes the refactored solution preferable to the designer’s solution.
Rating 4 - All classes are scoped wel

The reviewer should make a determination whether classes in the design could be grouped into separate packages. This category generally applies to complex components or components that allow for functionality to be plugged in (where the functionality should justifiably exist in a separate package).

Rating 1 - The component is sufficiently complex or uses pluggable classes that can justifiably be separated into sub-packages and was not.
Rating 2 - The designer separated some classes into separate sub-packages but either missed some classes or missed other sub-packages that could be justified based on the designer’s approach. For example, when one set of features was moved into a separate package, but another similar set was left in the main package.
Rating 3 - The designer created an unnecessary sub-package or the component could potentially benefit from an additional sub-package The reviewer should provide their reasoning when suggesting a sub package be eliminated or added.
Rating 4 - The designer appropriately used sub-packages or the design did not need any sub-package

) and scope (private, package, public, etc.) are appropriately used in the design in the classes/methods/variables. Attributes are appropriately used for .Net classes/methods/variables.

Have internally used classes been defined incorrectly as public? Has a public class improperly exposed protected or private members? Are classes that are intended to be abstract defined as such in the class diagram? Is the Serializable attribute used in lieu of implementing the ISerializable interface for standard serialization of .Net classes? It is strongly advised that variables have a private scope and only be accessible via get/set methods or C#'s property variables. C# reviewers should note that Poseidon does not have the proper choices to fully represent the C# modifiers and therefore should not be marked down if the designer either uses the closest java modifier OR specifies it in the documentation tab. Additionally, the effect of the final, virtual and other similar modifiers on class extendibility should be considered in this question. Each class and method should be designed for extension or marked as final.  This question addresses the logical aspect of providing the modifiers, not the presentation. When there are multiple ways to convey a modifier, not using all of them is considered a presentation issue. An abstract class must have an abstract checkbox on the attributes page, an abstract stereotype and a color of the abstract class. Any of the three methods is sufficient to convey that the class is abstract.

Rating 1 - The design demonstrates obvious lack of understanding or ignores modifiers fully. For example, variables with accessor methods are declared public or key methods of the API are declared private.
Rating 2 - The design misidentifies a majority (>49%) of the modifiers or scope.
Rating 3 - The designer misidentifies a minority (<49%) of modifiers or scope.
Rating 4 - The designer identifies the modifiers/scope appropriatel

.Net Custom exceptions follow the Microsoft Design Guidelines on defining custom exceptions and have the appropriate constructors and are marked as Serializable.

Has the designer appropriately reused existing system exceptions and appropriately defined custom exceptions for the rest? The reviewer should also imagine they were using this component in an application. If a custom exception is thrown, does it give enough information to the application to react appropriately? Example: an inappropriate custom exception would be some high level exception that is thrown for multiple, unrelated, reasons.

Please note that TopCoder Software has decided that java components should not throw NullPointerException.  When null is illegally passed to a method which doesn’t accept it, Java components should throw IllegalArgumentException and C# components should throw ArgumentNullException.

Rating 1 - System exceptions were re-used where a specific custom exception should have been defined. Appropriate custom exceptions were not defined or a single generic exception is used throughout the component for every custom reason.
Rating 2 - Appropriate custom exceptions were defined but for multiple, unrelated reasons or system exceptions were reused inappropriately.
Rating 3 - Custom exceptions were used appropriately for multiple, related reasons but do not give specific reason details beyond the included text or the design inappropriately identified a null argument exception.
Rating 4 - System exceptions were reused appropriately. Custom exceptions were used appropriately and give reason details beyond simple text. Custom exceptions were used appropriately and for a single specific reason alone. Custom exceptions were not appropriate for this desig

Are the type assignments correct and what you'd expect?  Are the method signatures as descriptive as possible?  Are method parameters and return value object types statically identified, or is the user expected to cast to the appropriate type?  Please note that TopCoder Software has made determination to prefer statically defined parameter and return values rather than to require the component user to cast objects to the appropriate type.  When Collections are used, are they used appropriately?  Was the best (in terms of performance and overhead) Collection implementation used for the component's internal representation?

Rating 1 - A majority (>49%) of types are used incorrectly (not including array to collection stuff). That is, a string used where an integer should be etc.
Rating 2 - At least one type is used incorrectly (same limitation as Rating 1).
Rating 3 - The types are appropriate and arrays are used where collections should have been.
Rating 4 - The types are appropriate and the collection interfaces are used where appropriate (i.e. arrays are used when justified). Method parameters and return types are statically identifi

Relationships to system classes (ie classes that are installed with the normal distributions - this does not include J2EE classes) do not need to be shown unless they are part of an extends or inherits relationship.

Are all relationships shown? Are the relationship attributes assigned appropriately (ordered, aggregate, composite, etc.)? Do they contain proper labels? Two ways of doing associations are appropriate:

a) Define a variable for the association, draw the association and label it with the variable.
b) Define the association and label it with a variable name - no variable needs to be shown for the relationship in the class.

Please note that extends/implements associations do not need the realization/generalization stereotypes assigned to them since the type of relationship inherently defines that.

Interfaces can have associations from them if that association is part of the contract as stated by either the interface signature or by the documentation.  Those associations then need not be duplicated in each implementation.  

Rating 1 - A majority (>49%) of relationships between internal classes and/or external TopCoder components are missing from the class diagrams, or more than 90% of relationships are missing attribute information.
Rating 2 - A minority (<=49%) of relationships between internal classes and/or external TopCoder components are missing from the class diagrams, or system classes are missing.
Rating 3 - Class diagrams show all relationships between internal classes and external entities (both TopCoder components and system classes). A small number of the association attributes (<10%) are either missing or incorrect.
Rating 4 - Class diagrams show all relationships between internal classes and external entities (TopCoder components or system classes) and all association attributes are cor

Does the name provide a hint as to what the function of the entity is? Does the name follow system language and TopCoder standards (capitalization, underscores, etc.)?

Rating 1 - The name of one or more entities is totally misleading or incorrect for the entity's function. Note: the designer may challenge this if they can give sufficient justification as to why the name is appropriate. Only -public- names should be eligible for this rating.
Rating 2 - One or more names violate either system language or TopCoder standards. Only -public- names should be eligible for this rating.
Rating 3 - All names follow the system language and TopCoder standards, and the names cover the functionality of the entities; however another name may more fully describe the functionality. All names (private or public) are eligible for this rating.
Rating 4 - All names follow the system language and TopCoder standards and fully describe the functionality of the entity. All names (private or public) are eligible for this rating.

Please note that -public- is defined as:

- Public or protected class names
- Public variables or protected variables on public or protected classes
- Public methods or protected methods on public or protected

Does the designer duplicate functionality that is already provided by the language? Are properties, delegates, interfaces, inheritance, networking, etc. used appropriately? Does the design pay attention to releasing the non-used resources, for example by using the .Net Dispose pattern?

Rating 1 - Language features are consistently ignored.
Rating 2 - Language features are inconsistently ignored or consistently misused.
Rating 3 - Language features are incorporated consistently and occasionally misused or abused.
Rating 4 - Language features are used correctl

The reviewer should look at this from a component developer standpoint and not an application developer standpoint. This is not API documentation (e.g. javadoc) on how to use the class. This should contain helpful information to the developer on how to develop the class and if the class is mutable or not.

Rating 1 - Documentation is consistently missing or consistently unhelpful.
Rating 2 - Documentation is missing in at least one class or consistently provides little help to the developer.
Rating 3 - Documentation is complete and adequate to develop the component but requires the designer to answer additional questions by the developer.
Rating 4 - Documentation is complete and provides full details to the developer (the developer will likely not require any additional information from the designer)

) and any exceptions that may be thrown. C# Properties, delegates, indexers and events are considered methods for this question.

This documentation is for the component developer, not the component users. It should contain information which is helpful to the developer on how to write the method and its constraints. The designer does not have to explicitly say what is considered valid if this information is already contained elsewhere (in the tags or in the free-form text). Duplicating the valid/invalid information and exception information in both the documentation tags and free form text is not recommended. Algorithms and complex validation should be explained only in the free form text. The reviewer should assume that any value is valid/invalid if not specifically denoted as such by the exceptions text or free form information. Also note that specifying 'raised signals' in Poseidon is not required if the exception has been clearly denoted in the documentation tags or free form text.

Algorithms and complex validation should be explained only in the free form text. Note that specifying -raised signals- in Poseidon is not required if the exception has been identified in the documentation tags or free form text. For C# designs, the reviewer should verify that property setters handle argument validation and throw appropriate exceptions.

Rating 1 - Documentation is consistently missing or unhelpful.
Rating 2 - Documentation is missing in at least one method's documentation or consistently provides little help to the developer.
Rating 3 - Documentation is complete and adequate to develop the component but requires the designer to answer additional questions by the developer.
Rating 4 - Documentation is complete and provides full details to the developer (the developer will likely not require any additional information from the designer

The reviewer should look at this from a component developer standpoint and not an application developer standpoint. This should contain helpful information to the developer on how to use the variable and what constraints (null, range, etc.) the variable will have. The designer should mention if the value is mutable, is set in the constructor and potentially where it will be modified and/or used. An initial value is not required unless appropriate for the variable (where it’s a constant or needs to be initially set to a certain value to ensure properly operation of the class [with proper documentation to denote why]).

The variable constraints only need to be included where they may differ from those defined by any associated getters/setters (whether they be method or property based).

Collections should state at least the following information (regardless if it's also stated in the getter/setters):  whether the collection can be empty or not and what element types can exist in the collection (including whether null elements are allowed).

Rating 1 - Documentation is consistently missing or unhelpful.
Rating 2 - Documentation is missing in at least one variable's documentation or consistently provides little help to the developer.
Rating 3 - Documentation is complete and adequate to develop the component but requires the designer to answer additional questions by the developer.
Rating 4 - Documentation is complete and provides full details to the developer (the developer will likely not require any additional information from the designe

The sequence diagrams should demonstrate to an adequate degree what interactions occur as a result of a method call.

This question should only consider the sequence diagrams that have been included and should not in any way be affected by whether a sequence diagram is missing or should not have been included.

Rating 1 - Sequence diagrams do not show sufficient details useful to a developer (e.g. they show the API call from the application but nothing beyond that).
Rating 2 - The sequence diagrams show some interaction but not enough to be able to develop from.
Rating 3 - The sequence diagrams show enough detail to give the developer an idea of what occurs on the method call.
Rating 4 - The sequence diagrams clearly show the detail of what occurs on the method call and potentially provides helpful notes on things that cannot be displayed visually in the diagram

Is the demo section complete (does it demonstrate each requirement)? Was it written in a way that 'promotes' the component (i.e. clear, demonstrates flexibility, etc.)?

The reviewer should keep in mind that the demo is not a reference implementation.  The demo should only give the reader a quick, short demonstration of the major functionality of the component and should not include every method call.  “Major functionality” would be defined as the requirements specified in the requirements documentation.

The demo section only needs to be compilable in relation to the component's API and any other TCS component API that is exposed.  All other functionality (application provided methods, classes, objects, etc) shown can be assumed if commented properly and can include pseudo code if dealing with non-component API methods.  Examples of this would be:

a) -ACMEInterface appACME = some application provided object
b) -Date todayPlusOne = todays date plus 1 day

External setup information does not need to be included in the demo as long as comments provide enough information to understand what setup the demo relied on.

The output of the demo only needs to be shown (if possible) when absolutely relevant to the functionality of the component (ie the component's job is to output something specific).  Logging or processing output does not need to be shown.

Rating 1 - Demo section is missing or the existing demo section contains non-compilable errors (don't actually try to compile it - just view it to make sure it looks correct).
Rating 2 - The demo section demonstrates some but not all of the requirements or the demo section demonstrates class/methods/variables that don't exist in the design.
Rating 3 - The demo section demonstrates each of the requirements correctly.
Rating 4 - The demo section demonstrates each of the requirements correctly in a clear fashion using a likely customer scenario (i.e. sets up a scenario th

Was it written in a way that is easily understandable and doesn't require multiple readings to understand? This category should ONLY judge the grammar, sentence structure and spelling (i.e. the knowledge transfer piece). How well the designer explained the design structure or algorithms is addressed in a prior question.

Please note that spelling and grammar should only be denoted in those items that are visible to the customer.  This would include the component specification, the diagrams themselves (not the doc tabs) and any additional information attached to the submission (that is not developer oriented).

Rating 1 - Useless. The document is not helpful to readers trying to understand or implement the component because of missing sections with critical information, frequent spelling errors, extremely poor grammar, etc.
Rating 2 - Marginally usable. The document provided some helpful information, but required multiple readings because of missing or incomplete sections, frequent spelling errors, unconventional wordings, poor grammar, etc.
Rating 3 - Usable. The document has no missing or incomplete sections, and provides enough helpful information to implement the component. The document requires significant efforts to read because the style is inconsistent, the material is not well organized, or there are occasional spelling or grammatical errors.
Rating 4 - Helpful. The document is well organized, easy to read, and stylistically consistent; it has no missing or incomplete sections, and no spelling errors. Despite an occasional unconventional wording or a few grammar mistakes, the document provides significant help to anyone trying to understand or implement the component.

Did the designer make use of fonts and colors to appropriately denote elements in the diagrams? Was the specification formatted in a professional looking manner? Was the diagram laid out in an easy to follow manner (most important elements in the top left to least important at the right and bottom edges)? Were like items grouped together (i.e. implementations [including the abstract base] of some interface should be near the interface)? Did the layout help you understand the design? Note: multiple class diagrams are allowed but discouraged unless separate sub-packages were used or the design was sufficiently complex that multiple diagrams help in the understanding.

Rating 1 - The presentation looks amateur. The presentation not only lacks the above elements but also actively confuses the reviewer in trying to understand the design.
Rating 2 - The presentation lacks many of the above but doesn't add to any confusion in understanding the design.
Rating 3 - The presentation looks professional but has some rough edges that can be improved upon.
Rating 4 - The presentation looks professional, and polished, and contributes to understanding the design.  Minor errors (such as coloring, font size, etc.) are acceptable for this rating

Please detail any additional comments regarding the component design.  The reviewer must include their reasoning for assigning anything but a perfect score in this category.