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