This Meeting

1. Overall the SADD is great
2. Everything described in the SADD is documented and coherent
3. The SADD is very concise
4. Explained to Lachlan what a "maintainer" do
5. Lachlan's suggestions:
• To have a list of authors in the tittle page of every documents instead of listing the team members, as the team members are usually listed again in the introduction
• To have design decision files, just to see how the team decided to follow the particular design
• To have a glossary for the SADD
• It's great that the team follows the Booch method for their design.  It will be good if the team includes a list of references to Booch method - good to show that the team has done a lot of research
• How much detailed does the description of the proposed system should be in the SADD? - ask Anthony.  Or could the team just refer to the SRS for it?
• Emphasize on what the MultiMahjongClient module actually does
• Include some screen shots - from the prototype
• Different pages for images in the team's web site - point and click scenarios
• Responsibilities section can be more detailed, such as:
• including dot points of what it does under some circumstances
• list tasks that it must do, e.g. Under the CO class - it will do this under this condition.......
• enumerate each responsibility - for traceability
• Might be a good idea to add in pseudo-code standards in the SQAP
• A good idea to include scenario diagrams - good for flow control - ask Anthony
6. Connections between the Game and Server class, and UserGUI and Server are still a bit ambiguous
7. Definition of hands is still a bit ambiguous as hands can be understood in two ways:
1. A hand describes all the Mahjong tiles that a player has
2. A hand is also one round of a Mahjong game
8. It's still ambiguous what information is passed around between classes.  Even though the team is doing Object Oriented Modeling, where we pass objects and not data structures, it is still good to know what's been passed around - ask Anthony
9. Put methods, attributes, algorithms and pseudo-codes in SDD
10. The traceability of the document is very good - might want to add a section "Description of Requirements" in the traceability table.  Doesn't have to be long descriptions, half a dozen words will do.