TA Meeting

Attendance
everyone is accounted for

- Aaron addresses need to be more specific about the project planning

- Trevor addresses RAD and Project Planning documents
- initial mark out of 100 for both documents
- make most of suggested changes and will receive mark boost

- overall mark for first RAD 44/100
- many areas of improvement required

Section 1

- don't need to mention Mr. Huie in your document because he is the audience

- scope
- don't discuss any of the implementation details (you may not know details of implementation or would like to keep it open)
- similarly, no discussion of JDK, mySQL...etc...
** - keep it at a higher level (it wants an overview as opposed to technical requirements) **
- clients are usually non-technical

- minor grammatical errors
- spell check
- make sure it has a consistent sound to it (sounded like it had different style for each respective sections)

- STRESS ON HIGHER LEVEL DETAILING
- i.e. Generic call-center application with chat capabilities where users can chat with CSRs

- definitions of RMI stated yet it is not in doc, then don't define it in the glossary

- can mention Java in the portability section of the document

** - doublecheck scalable definition in glossary **

- if you don't cite references, then don't include the references
- if include comparative products, then can cite it

** - Overview Section should give client a real feel for what the system is going to do **

- state that it is a generic product since you don't know what product it is going to be serving
- explain what the CSR is supposed to do (i.e. support for a software or app.)

- don't rehash the table of contents in Overview section

- at the end of the introduction, include a diagram (like the system context diagram used later on in document) <-- NOT ESSENTIAL
- good to show the client what the system is going to be like

Section 2

- Product Perspective - use a better introduction (state in a more euphonic manner)

- can refer to doc with warning: This document assumes the client has understanding of sufficient technical level

- be more specific about managing Manager accounts

- customers are assumed to be novice users <- change

- User characteristics can go under scalability section

- if you feel that a section is irrelevant, then don't need to inlcude it...(i.e. constraints section, hardware limitations)
- constraints refers to i.e. must deploy on I.E. 2.0

- state assumptions in the scope of the document (Overview)
- i.e section 2 assumes that viewers have a technical background

- Trevor doesn't understand how an external website gets tied into the system

- list universalization of languages as an OPTIONAL FEATURE

- Customer information input is not a constraint

- don't need to include every section in the template if not necessary

- don't need to specify CICSR labs

- Windows doesn't include JVM anymore

Section 3

- grammatical errors

- be consistent with use case descriptions (i.e. if use point form then stick to it...if sentence form then...)

- databse is actually a software not a hardware

- minor UML syntax (state "includes")

- include title of Use Case descriptions

- list use case descriptions by numbers
- this is useful for the client to refer to

- order the use cases in priority
- base requirements are first and optional ones are last

- don't necessarily need a ManageAccount use case (i.e. change to fecthCSRAcconts)

- restate or be more specific on exit conditions

- Manager can manage other ManagerAccounts

- GenerateReports use case is really vague (ask Mr. Huie for more specifics on this deal)
- Mr. Huie wants us to do whatever he wants with the reports
- we can propose our own specs and specify that in the document

- entering chat is prerequisite for other use cases
- therefore, mention them

- viewChatStatistics is redundant use case to GenerateReport

- login Use Cases is just use case (can be combined into one)

- EndChat could be a separate use case

- Performance Requirements
- don't need to refer to implementation specifics
- "95% of chat processes shall be sent and received" don't need to make such bold claims

- terminal == user?? (i.e. can it support five chats at any one time)

- section 3.4 should be segregated on its own

- use table format

- can run on any runtime Java Environment (i.e. be careful about this cuz our implementation may not run on 1.0.1)

- some sections under constraints are not actually constraints

- minor grammatical issues in constraints section



Project Planning____________________________________________________________________________

- keep statements high level

- language should be consistent with SRS document

- i.e. "success of this project will be measured by..." <- vague sentence
- be more specific about the goals

- concentrate not only on delieverables of the course and not the chat project itself

- delieverables entail?
- source code, binary codes...etc...

- Mr. Huie and CICSR labs don't need to be included

- for the diagram, want to see details in the subsections (who's actually assigned which tasks)

- somethings may be easier to read in table format

- omit "reallocation of the team members as needed" <-- suggests to be more specific as opposed to sounding like we haven't thought about this

- design, QA, testing take time
- Kurt and client want id of tasks, how long it takes and who's assigned to these tasks

- needs some more detail in project planning

- need to use titling for section 4

- info stored in CVS (is that how you store docs, code?)

- how to maintain bug track list...(use bugzilla or excel spreadsheet)

- somethings under QA section are not relevant
- want to specify stuff like using JUnit, how to do platform testing, integration testing....how to make sure of each test types