Dacopan project MEETING MINUTES
Mar 9th, 2004
Meeting
Mar 9th, 2004, at 16:15
Department of Computer Science, room C475
Attendance
Markku Kojo, customer
Alejandro Fernandez Rey
Carlos Arrastia Aparicio, secretary
Jari Aarniala
Jarkko Laine
Jonathan Brown
Turjo Tuohiniemi, instructor and chairman
Vesa Vainio
Absent
nobody was absent
1. Start
Mr. Tuohiniemi started the meeting at 16:15.
2. Assessment of the situation
It's one week after the publishing of the Review of the Requirements
Specifications Document. In this meeting a reviewing session with the client
to find out errors will take place.
Parallely the group also work in some drafts for the user interface, data
structures and other components for the animator.
3. Discussion
All the sections present in the document were presented to explain their
purposes and commented all the erroneous aspects giving a correction or solution
to be changed in the document.
To follow this document there is a list with all the sections and description of
the type of errors at the end of the document. The errors present in the
document are these:
General errors and corrections
Type Description
3 Clarify the limits of the work that will be implemented in the project
by prioritizing some requirements and assign optional priority to others
1 Add glossary section to make clear the terms used in the document.
Errors specific to subsection
# Sect Type Description
1 3 In paragraph 6 change definition of networking scenario to
'outline of the behavior' and also explain how the priorities
are related with the future extensions.
2.1 3 Unify terms 'intermediate file' and 'protocol events file'.
2.1 6 Bullet 3: explain the meaning of 'support' with respect to the
protocols that will be analyzed.
2.1 4 Bullet 4: The analyzer is able to detect errors in time
differences and the order of the protocol exchanges should not
be based on IP identifiers.
2.1 3 Bullet 5: Do not discard packets received in different order
that they were sent. Pay attention on it in the design phase.
2.2 1 Add in this section some information about the animation types
2.2 1 Bullet 2 does not contain information about the two types of
speed that can be set in the animator. One based in time and
another one based in messages transferred.
2.2 12 Some of the items presented here have not been prioritized.
Bullets 4 and 5 should be marked as optional
2.2 4 Bullets 6 and 9 are redundant. Number 9 contains more detailed
information and will be kept.
2.2 2 Bullet 11 should be removed. Requirements about the delays are
already present in the analyzer.
2.2 12 Some of the items presented here have not been prioritized.
Bullets 4 and 5 should be marked as optional
3.1 2 Correct in graphic 'tcpdump file log contain all the data
needed'. Variables are not present in the tcpdump files
3.1 2 Correct in graphic 'tcpdump file log contain all the data
needed'. Variables are not present in the tcpdump files.
change where says that 'protocols event file can be edited with
an external text editor' by 'it can be edited by hand'
3.2 5 Delete the last part of the section. From 'possible problems for
the SE...'. This information is not relevant here and can be
moved to another section by agreement with the Petrozavodsk
group.
3.3 3 Delete the expression 'user requirements'.
3.3.1 2 The end host log not only catch header files. It also gathers
other information.
3.3.1 5 Do not limit fuzzyly the number of records that the analyzer can
process. Delete the last sentence of this subsection. And add
more accurate information later.
3.3.2 3 It should be specified that additional input logs are used when
more than 2 hosts are analyzed.
3.3.3 2 Delete the last sentence: '...diference in the times are stored'
3.4.1 1 Paragraph 1. Specify reference to the 'networking scenarios'
document.
3.4.1 5 Paragraphs 2 and 3 can be deleted. The information that contain
is also included un paragraph 4.
3.4.1 2 Paragraph 4. Delete the sentence: 'The file formats do not
support manual editing'
3.4.2 12 Prioritize the non-functional requirements for the animator,
(e.g. Languages is an optional requirement)
3.4.4 1 Detail that the platforms wher the animator will be run must
support Java 1.4
3.4.4 8 Make optional the requirement of releasing the application as an
applet or web startable application.
4 1 Add an introduction explaining the purpose of the networking
scenarios and also the meaning of the different priorities
assigned to the document.
4.1 13 Move the notes in this subsection into a new subsection.
4.1 13 Separate scenarios with commas instead of dashes in the section
with the scenarios using the variables.
4.1 8 Some of the variables are difficult to calculate (dupack) some
of this variables is better if the user introduces the values
manually.
4.1 8 RST flag is not a variable and should be removed from here.
4.2.1 5 Options of header fields are not useful to show.
4.2.3 1 MSS negotiation should be visualized.
4.2.4 1 Specify more details.
4.2.5 3 Delete the sentence: '... dataflow is bidirectional...'
4.2.6 3 Delete in '...tells the client more than just...' the expression
more than just.
4.2.6 3 Add the expression 'recovery through fast retransmit' to make
clear how the recovery is done. If not it can cause conflicts in
understanding recovery in scenario 333 (TCP packet loss).
4.2.6 1 Add dupack threshold in variable list.
4.3.1 3 Add the expression 'recovery through RTO' to distinguish this
scenario from scenario 362 (TCP recovery through fast
retransmit)
4.3.1 3 Delete the last sentence '... if not, after a timeout...'
4.3.2 2 Delete from variables: request and reply headers
4.3.2 1 Specify that no embedded objects will be included into this
scenario.
4.4 6 Move from priority 3 to priority 2 scenarios 101 (4.4.1) and
322 (4.4.2)
4.4.1 3 The important layer for this scenario is not the 'link layer
the correct value to present here should be 'ARP layer'
4.4.2 3 An unclear explanation makes this scenario similar to 333
4.4.3 2 Delete RST flag from variables list
4.4.4 2 Delete from variables: request and reply headers
5 1 An introduction should be added for this section explaining the
scope and purpose of the use cases
5 12 Add information about variations and prioritize them.
5.2 4 Merge use cases 5.2.7, 5.2.8, 5.2.9, 5.2.10 into two use cases
named 'change settings' and 'save settings'
6 3 Calculate events (as tcp states) is more a responsability for
the user who adds them as comments or replace the default
comments written by the analyzer.
6 3 Make clearer the difference between protocols event file and
scenario file in sections 6.2-6.4.
6.1 3 In this section something similar to the use case 5.2.1 is
presented with a confusing error handling strategy. Disscuss
with the P-Group what to do.
7 1 Add introduction for this section.
7.1.2 3 Add to mandatory requirements visualization of packet loss.
7.1.2 3 Rewrite optional bullets, because they can be ambiguous. Review
terms 'at least' and avoid using numeric values here, changing
them with the relevant fields.
7.1.2 1 Distinguish different events in the animation: sending,
transferring, reception. Select what do you need to show in
each of these phases.
7.1.7 5 Do not specify how exactly the notes must be presented.
7.2.3 12 Make the breakpoints optional in this animation.
7.4 6 Explain how is shown the meaning of cwnd in this animation type
9 3 Some of the arrows presented in the graph are confusing. Review
and correct them
4. Action points
- Corrections in the document should be done.
- A meeting to discuss animation types with the customer has been arranged
for tuesday March 16th.
- The members of the group will continue working on the design drafts for
the next meeting.
5. End
Mr. Tuohiniemi ended the meeting at 18:05
Appendix:
This is the list with descriptions of the different types of errors that
has been used to clasify the errors found in the document. It's based in the
requirements checklist present in the Huphrey's book ("Managing the Software
Process", Addison-Wesley, 1989)
1. "Complete" -- All items needed to specify the solution
to the problem have been included.
2. "Does not contradict with what you know" -- Each item is free
from error.
3. "Precisely written" -- Each item is exact, there is a single
interpretation, the meaning of each item is understood, and the
specification is easy to read.
4. "Consistent" -- No item conflicts with another item in the
specification.
5. "Relevant" -- Each item is pertinent to the problem and its
solution.
6. "Verifiable" -- During program development and acceptance
testing, it will be possible to determine whether the item has been
satisfied.
7. "Traceable" -- Each item can be traced to its origin in the
problem environment.
8. "Reasonable" -- Each item can be implemented with the
available techniques, tools, resources, and personnel and within the
schedule constraints.
9. "Explains problem, not solution" -- The requirements
specifications are a statement of the requirements that must be
satisfied by the problem solution, and they are not obscured by
proposed solutions to the problem.
10. "Easy to change" -- The requirements specifications are
expressed in such a way that each item can be changed without
excessive impact on other items.
[11. This one has been left out.]
12. "Has been prioritized" -- Each requirement has been given an
implementation priority and it is clear whether or not the requirement
will be implemented during this project.
13. "Others" -- Other issues that do not fall into any category
presented above.
Back to DaCoPAnDocumentation