3. Scenarios

3.1 Evolution of Our Scenario Development Process

Our scenario development went through two distinct phases, reflecting our growing understanding of what makes scenarios effective for software development:

Initial Scenario Creation (24 February 2025)

Initially, a small team was tasked with creating scenarios according to our issue from February 24. These initial scenarios focused on identifying basic user needs and covering various use cases for our Neighborhood Assistance Board platform. While this approach helped us establish a baseline understanding of how users might interact with our system, the scenarios lacked the necessary detail to effectively guide implementation.

Enhanced Detailed Scenarios (20 March 2025)

After receiving feedback in PS sessions and lectures, we recognized the need for more detailed, requirement-linked scenarios. We restructured our approach by:

1. Assigning individual ownership: Each team member was responsible for developing one detailed scenario, ensuring all aspects of the platform were covered while distributing workload effectively.
2. Creating atomic, detailed scenarios: We moved from general use cases to detailed, step-by-step scenarios with specific user profiles and concrete examples.
3. Linking to requirements: Each step in our scenarios was explicitly connected to specific requirements, creating traceability between user needs and implementation.
4. Adding sequence diagrams: We complemented written scenarios with sequence diagrams to visualize the interactions between system components.

This transition reflected our team's growing maturity in understanding how scenarios serve as a bridge between requirements and implementation. The parent issue can be reached from: issue from March 20

3.2 Scenario Development Standards

To ensure consistency across all 11 detailed scenarios, we established the following standards:

1. Template structure: Each scenario followed a consistent format with sections for:

   • Actor details (including specific personas with names, ages, locations)
   • Preconditions
   • Main flow with numbered steps
   • Postconditions/outcomes
   • Related requirements (with direct links)

2. Specificity requirements: All scenarios needed to use concrete, specific data rather than hypothetical examples.

3. Linking convention: Each step in a scenario needed to reference at least one requirement from our requirements document using a consistent citation format.

4. Review process: Each scenario underwent peer review by at least one other team member before final approval.

3.3 Collaboration Methods

The transition from initial to detailed scenarios demonstrated our team's ability to:

1. Respond to feedback: We quickly adapted our approach based on instructor guidance.
2. Self-organize: Team members volunteered for specific scenarios based on their interests and understanding.
3. Maintain consistency: Despite individual ownership, our scenarios maintained a consistent format and quality thanks to our established standards.
4. Support each other: More experienced team members mentored others in scenario writing techniques.

3.4 Impact on Project Design

Our detailed scenarios had a significant impact on our design and implementation:

1. They revealed edge cases and potential user experience issues that weren't apparent in the initial requirements.
2. The sequence diagrams directly influenced our backend API design, ensuring we had necessary endpoints for all user interactions.
3. Several UI/UX decisions were directly driven by scenario analysis.
4. The scenarios provided concrete examples for database design, helping identify required entities and relationships.

3.5 Challenges and Resolutions

Despite our structured approach, we faced some challenges:

1. Ensuring complete coverage: Initially, we had gaps in our scenario coverage. We resolved this by mapping scenarios to requirements and identifying areas that needed additional scenarios.
2. Maintaining consistency: With 11 different authors, maintaining a consistent level of detail was challenging. Our solution was creating a detailed template and conducting thorough reviews.
3. Balancing detail with readability: Some scenarios became too detailed and lost focus on the main user journey. We addressed this by emphasizing the primary user goal in each scenario.

3.6 Lessons Learned

1. Detailed scenarios with specific personas and concrete data are much more useful for guiding implementation than general use cases.
2. Creating sequence diagrams alongside written scenarios helps identify technical implementation details early.
3. Assigning individual ownership while maintaining team review creates both accountability and consistency.
4. Explicitly linking scenarios to requirements creates valuable traceability for implementation and testing.

Our scenarios can be found in our project repository:

• Initial Scenarios
• Detailed Scenarios