Documentation Review

Important Points to review before delivering

• Change Footer to include Group Number instead of all the users. (Or the other way around, as we wish).
• Don't put class diagrams in our documentation (is system diagrams of the architecture).

Remember

Section 9

QA -> Requirements
SCenario -> QA
V -> SC & QA

• View with at most 5 components
• View mus be easy to understand

Stakeholders

• Both teams are stakeholders.
• Identify the stake holders (teachers, both teams and virtual stakeholders like users admins the university etc).

Quality attributes

• Do not delete code in tables, put deleted whenever a quality attribute is deleted.
• Do not change quality attributes order, add new quality attributes at the end.
• Review accessibility and usability (AA)
• Put in the quality attributes, not how it is done but the behavior.

Quality Scenarios

• At least for every quality attribute one quality scenario.
• There can be a scenario for several quality attributes.
• Keep simple scenarios, code of the scenario and code of the constraint.

Views

• DO NOT MIX SCENARIO FOO1 AND FOO2
• Context view in one only diagram
• Context views for subsystems if they are too big. One root and children.

                  CV
                 /  \
              CV.1  CV.2

• ALL CONTEXT VIEW MUST HAVE A RATIONAL SECTION (if not we will fail)
• If the interfaces are inside a module that is used outside a systen, must appear in the corresponding view
• A view is the representation of only a subsystem
• Kafka is a component of our system
• Specify how every interface works. Explain that kafka interface is not a java interface but it its created by mvn, springboot...
• We are not responsible of kafka interface
• We must specify that those interfaces are not developed by us
• Every view must have a rational (Important)
• Do not share subsistems (common files )

*F014- Super important:

Document code and traceability