Our approach to creating diagrams for the Neighborhood Assistance Board platform evolved significantly throughout the project lifecycle, reflecting our growing understanding of software design principles and collaborative development:

In Meeting 6 , we initially aimed to create the sequence, class, context, and use case diagrams by assigning roles among the group members, and we completed the role distribution accordingly. Since the creation of sequence diagrams required the other diagrams to be prepared first, we decided to draft all the diagrams except for the sequence diagrams. These drafts were a crucial step for us, as they helped us better understand the project and provided a solid foundation for our future work.

After solidifying our requirements and detailed scenarios, we recognized the need for more structured and implementation-focused diagrams. We restructured our approach by:

• Starting with shared responsibility: Initially, in Meeting 7, we adopted a collaborative approach where all members contributed to sequence diagrams to maximize exposure and learning.

• Assigning individual use cases: We distributed specific use cases among team members, ensuring individual accountability and deep focus on distinct functionalities.
  This also helped us parallelize the work efficiently.
  Example: Ali was responsible for "Post Assistance Request", Musa for "Register", etc.

• Pairing sequence diagrams with use cases: We shifted from group-created sequence diagrams to an individual approach where each member developed the sequence diagram for their assigned use case, ensuring stronger alignment and deeper understanding of system interactions.

• Ensuring requirement traceability: Each diagram was explicitly linked to relevant requirements and scenarios, forming a tightly integrated documentation system from analysis to design.

• Following a sequential development flow: As agreed in Meeting 7, we followed a sequential workflow where we first developed context and use case diagrams, then class diagrams, and finally sequence diagrams—ensuring each diagram builds logically on top of the previous one.

This transition reflected our team’s commitment to treating diagrams not as static documentation but as living blueprints that directly support implementation.

#	Use-Case	Assignee(s)
1	Ban User	Erdem
2	Register	Musa
3	Post Assistance Request	Ali
4	Update Assistance Request	Üveys
5	Cancel Assistance Request	Yusuf Kaan
6	Rate and Review	Ahmet Eren
7	Attach Photos to Task	Alperen
8	Confirm Task Completion	Abdullah
9	Select Assignee	Ebru
10	Recover Password	Eray
11	Change Profile Information	Batuhan

1. Tool standardization: All diagrams were created using [Lucidchart/Draw.io/etc.] to ensure consistent styling and collaborative editing.
2. Naming convention: All diagram files followed the pattern [DiagramType]_[MainFocus]_v[Version].png (e.g., UseCase_TaskCreation_v1.2.png).
3. Review checklist: Each diagram was reviewed against a standardized checklist covering technical accuracy, completeness, and adherence to UML standards.

1. System boundary definition: The context diagram clearly delineates the boundaries of the Neighborhood Assistance Board system.
2. External entity identification: All external entities that interact with the system are identified.
3. Data flow representation: Major data flows between the system and external entities are represented.
4. Simplicity focus: The context diagram maintains a high-level view without delving into internal system components.

1. Actor specificity: All actors corresponded to specific user roles defined in our requirements, as shown in our Use Case diagram which clearly distinguishes between Guest User, Registered User, and Administrator.
2. Use case atomicity: Each use case represented a single, coherent user goal (e.g., "Register," "View Public Requests," "Volunteer for Request").
3. Relationship clarity: "Extends" and "Includes" relationships were used purposefully to show relationships between use cases, such as how "Rate and Review" is included in the "Confirm Task Completion" process.
4. System boundary: Our diagram clearly identifies the "Neighborhood Assistance Board" system boundary, distinguishing between user actions and system responsibilities.
5. Scenario alignment: As decided in Meeting 6, we ensured that use case diagrams were aligned with user scenarios, with scenarios being finalized after the use case diagram drafts were completed.

1. User role representation: As decided in Meeting 6, our class diagram does not have separate Volunteer and Requester classes, as all users can perform both roles. This design decision was explicitly made to reflect the flexible nature of user roles in our system.
2. Attribute completeness: Classes included all attributes necessary for implementation with appropriate data types, as demonstrated in our comprehensive class diagram where each entity (like RegisteredUser, Task, Notification) contains complete attribute definitions with proper data types (String, int, Date, etc.).
3. Method specificity: Methods included parameter types and return values (e.g., "+login(email, password) : boolean" in the RegisteredUser class).
4. Relationship precision: All relationships specified multiplicity (e.g., 1.., 0.., 1) and included descriptive association names (e.g., "creates," "receives," "has").
5. Package organization: Classes were organized into logical groups reflecting our implementation architecture, with clear separation between user management, task management, and supporting functionality.

1. Actor-system consistency: Actors in sequence diagrams matched those in use case diagrams.
2. Alternative flows: Complex interactions included alternative flows for error cases and edge conditions.
3. Individual ownership model: As decided during our project evolution, each team member created the sequence diagram for their own assigned use case, ensuring deep understanding of each scenario.
4. Scenario alignment: Following Meeting 7 decisions, each sequence diagram was directly tied to a specific scenario developed for each use case.
5. Dependency on preceding diagrams: As established in Meeting 7, sequence diagrams were developed after use case and class diagrams were finalized, ensuring consistency across all diagram types.

Our diagram development process demonstrated effective team collaboration through:

• Evolving ownership structure: Initially, as per Meeting 6, different members led the creation of different diagram types. Later, we transitioned to an individual ownership model where each member was responsible for:

  • A specific use case
  • The corresponding scenario development
  • The sequence diagram visualizing that scenario

• Comprehensive use case coverage: We ensured all major system functionalities were represented, with each use case assigned to one team member.
  Example: Ali was responsible for “Post Assistance Request”, Musa for “Register”, etc.

• Structured peer review cycles: Diagrams underwent structured internal reviews, with team feedback leading to meaningful changes such as clearer relationships and better naming conventions.

• Internal knowledge transfer: Team members with stronger UML experience supported others by explaining proper notations, guiding relationship modeling, and sharing best practices, improving overall diagram quality.

• Phased diagram development: Following the plan from Meeting 7, we adopted a sequential development approach:

  • Context and use case diagrams were finalized first
  • Then class diagrams were built based on these foundations
  • Finally, sequence diagrams were developed once scenarios and structures were fully clarified

• Standardized scenario and mockup workflow: After Meeting 7, we introduced a shared template for scenario development, which included a full workflow:

  • Scenario text
  • Corresponding sequence diagram
  • Related mockups
    This ensured consistency across all contributions while preserving individual ownership.

Our diagrams significantly influenced our implementation approach:

1. Context diagrams established clear system boundaries and identified all external entities interacting with our system, helping focus development efforts.

2. Use case diagrams helped prioritize feature development and establish clear acceptance criteria for each functionality. For instance, the clear separation of user roles (Guest User, Registered User, Administrator) in our diagram directly informed our authentication and authorization implementation.

3. The relationship structure in our Use Case diagram between core functionalities like "Post Assistance Request" and its extensions ("Update Assistance Requests," "Cancel Assistance Requests," "Attach Photos to Tasks") guided our implementation of the request creation workflow.

4. Class diagrams directly informed our database schema design and API structure. For example, our comprehensive class diagram clearly defines the relationship between RegisteredUser and Task entities, showing that a user "creates" tasks and "has" a feed. This directly translated into our database schema and API endpoints for user-task interactions.

5. The enumeration types defined in our class diagram (TaskStatus, TaskCategory, VolunteerStatus) established standardized values used consistently across both frontend and backend implementations.

6. Entity relationships mapped in our class diagram (such as the connection between Task, Review, and RegisteredUser) ensured consistent data flow throughout the application.

7. Sequence diagrams guided our API endpoint design and frontend-backend communication protocols. By having each team member create the sequence diagram for their assigned use case, we ensured deep understanding of both the user interaction flow and the technical implementation requirements.

8. Integration of scenarios, sequence diagrams, and mockups for each use case, as organized in our wiki, provided a comprehensive view that guided both frontend and backend development teams with consistent vision.

9. All diagrams collectively served as reference documentation during development sprints, reducing ambiguity and implementation errors.

10. The organized structure of our wiki with diagrams grouped logically facilitated easy access to relevant documentation during implementation, improving team efficiency.

Despite our structured approach, we encountered several challenges:

1. Ensuring consistency across individually created artifacts: With the decision in Meeting 7 to have each team member create their own scenario, sequence diagram, and mockups, we needed to establish templates and standards to ensure consistency. We developed standardized templates for scenarios to address this challenge.

2. Coordinating sequential development: Managing the dependencies between diagram types (with sequence diagrams dependent on completed use case and class diagrams) required careful planning and communication to ensure timely completion without bottlenecks.

3. Adapting to requirement changes: When requirements evolved, diagrams needed updating. This is reflected in our commit history, where we made significant revisions based on stakeholder input. We addressed this ongoing challenge by establishing clear change management procedures and responsibility assignments.

1. Diagrams are most effective when created collaboratively with input from various team roles, not just architects or designers.

2. Regular diagram reviews against implementation progress help keep documentation and code in sync.

3. Starting with simpler, high-level diagrams before adding detail helps maintain focus on core system relationships.

4. Explicitly connecting diagrams to requirements and scenarios creates a more cohesive project documentation ecosystem.

5. Investing time in diagram standards and templates early saves significant effort in later project phases.

6. Sequential development of diagram types (context → use case → class → sequence) creates more consistent and cohesive system documentation.

7. Cross-team knowledge sharing about UML standards and best practices improves overall diagram quality and utility.

8. Clear team assignments for specific diagram types leads to better specialization and more detailed diagrams.

9. Individual ownership of end-to-end scenarios (from use case to sequence diagram to mockups) promotes deeper understanding and better integration between diagrams and implementation.

10. Standardized templates for scenarios ensure consistency across individually developed artifacts.

11. Combining use cases, scenarios, sequence diagrams, and mockups provides a comprehensive view of system functionality from both technical and user experience perspectives.

All our diagrams are maintained in our project repository with an organized structure that facilitates easy navigation and access. Based on the screenshots of our wiki home page and sidebar, we have created a comprehensive navigation structure that groups related documentation.

We have organized our project documentation into logical sections in both the wiki home page and sidebar:

1. Requirement Analysis Section(Wiki Sidebar):

   • Requirements
   • Elicitation Questions
   • Scenarios
   • Customer Meeting
   • UML Class Diagram
   • UML Use Case Diagram
   • Scenarios & UML Sequence Diagrams (with expandable subsections for each use case)

2. Diagrams Section(Wiki Homepage):

   • UML Class Diagram
   • UML Use Case Diagram
   • Scenarios & UML Sequence Diagrams (with expandable subsections for each use case)

This hierarchical organization allows team members and stakeholders to quickly locate specific diagrams and related documentation, with clear relationships between scenarios, use cases, and their corresponding sequence diagrams.

Our project repositories:

• UML Context Diagram

• UML Class Diagrams

• UML Use Case Diagrams

• UML Sequence Diagrams

  Register

  • Register - Sequence Diagram
  Select Assignee

  • Select Assignee - Sequence Diagram
  Recover Password

  • Recover Password - Sequence Diagram
  Rate and Review

  • Rate and Review - Sequence Diagram
  Post Assistance Request

  • Post Assistance Request - Sequence Diagram
  Confirm Task Completion

  • Confirm Task Completion - Sequence Diagram
  Change Profile Information

  • Change Profile Information - Sequence Diagram
  Cancel Assistance Request

  • Cancel Assistance Request - Sequence Diagram
  Ban User

  • Ban User - Sequence Diagram
  Attach Photo to Task

  • Attach Photo to Task - Sequence Diagram
  Update Assistance Request

  • Update Assistance Request - Sequence Diagram