Course Artifacts

Besides the main project results, we expect you to produce a number of artifacts in the course of the Software Engineering Project. These artifacts allow us, to assess your progress and to guide you. At the end, they are used to grade your team’s performance. This includes the following:

• Specification Document
• (Draft) Project Report
• Poster
• Final Code Submission

The assignments are described in detail below. For the concrete submission deadlines, please refer to our course schedule.

Specification Document

Purpose

After your first meeting with the customer, your team will prepare a specification document (1-2 pages) outlining the project vision and any legal constraints, such as licenses. This document acts as a “contract” between your team and the customer, clearly establishing expectations for the project.

Process

During the first iteration (following the initial meeting with the customer), the team should complete this specification document based on discussions with the customer. The document should be ready to share with the customer and mentors for feedback ahead of the second customer meeting.

(Draft) Project Report

This report describes your project as well as the development process you follow throughout the semester.

Draft Report

The draft report has all the same requirements as the regular report, but includes less detail and is expected to be incomplete (since the project isn’t finished yet). For each section outlined below, aim to write approximately a third the number of pages specified. This draft will serve as an initial foundation for the full report and allow for early feedback on structure and content.

Formal and Structural Review

• Format and Structure: Ensure the document is well-structured, with effective use of whitespace, clear paragraph separation, and logical page breaks.

• Readability and Grammar: Write clearly, concisely, and with correct grammar. Aim for a logical flow and readability, free of excessive errors.

• Coherence and Flow: Ensure that the document follows a clear structure that guides the reader smoothly through each section. Paragraphs should be logically organized, concise, and easy to understand.

• Clarity and Conciseness: Focus on presenting key information clearly and concisely, using lists, tables or schemas whenever possible to provide structured and easy-to-understand overviews. Avoid hiding details in long and unstructured blocks of text in the chapters 2 - 7.

Your project report should cover the sections and content listed below:

1. Project Overview (1-2 pages)

• Project Vision: Provide a summary of the project’s purpose, target audience, and the main problem it aims to solve.

  This section should motivate the project by showing how it addresses a specific problem or need. Ensure that the vision is clearly explained, gives an overview of the solution to be developed, and establishes the context in which the project will integrate. For example, consider how the client envisions the project’s role over the next three years.

• Project Context and Goals: Define the initial and final states, explaining what existed before the project and what is expected by its end. Clarify what is important to the client and briefly introduce some key functional and nonfunctional requirements (explained in detail in section 3).

2. Team Communication and Agile Process (1-2 pages)

• External communication: Describe external communication with the client, including main contact points, frequency, and methods of communication. Specify expected communication channels, contact points, and response times. Consider both regular meetings and irregular meetings with special purposes.

• Internal communication: Describe the communication within the group, including team organization, role distribution, and coordination, and regular meetings.

• Development process: Describe your development process, starting from the initial informal client wish. Detail the requirements engineering, implementation process, and version control practices. Include steps for internal quality assurance checks (e.g., testing, code reviews, and pair programming), external validation (e.g., presentations and the acceptance or rejection of user stories), and how you manage changes to requirements during the project lifecycle.

You can reference and link to existing material on Agile, Scrum, Kanban, Version Control Processes, and describe adaptations made for the project. Please mention tools and technologies used for communication and development in the respective sections.

3. Functional and Non-Functional Requirements (2-4 pages)

• Domain Description: Explain the application domain, relevant terminology, user roles, and additional stakeholders to be used in the requirements. Describe how the application will benefit its users. Explain user roles and how they interact with the system. Also identify other stakeholders affected by the project. Clarify any constraints, and ensure the relationships between components and users are clear.

• Functional Requirements: Describe the core functionalities the project must provide, including specific features and use cases.

• Non-Functional Requirements: Outline quality attributes and constraints, for example: performance, security, usability, and scalability or similar high-level goals of importance for the client. For each QA attribute, reference steps from the development processes defined earlier that help ensure this attribute, and list specific steps to uphold for this attribute, for example code reviews with checklists that are match the quality attribute (self-designed or referencing some publicly available guidelines), goals you have for automated tests, and additional quality checks. Specify the process for addressing any violations of these criteria.

(Every functional and nonfunctional requirement should have a objective, measurable criteria for being completed. Avoid being vague. In the best case, an acceptance criteria is so objective enough, that an independent neutral party could decide whether it has been completed or not.)

4. Technical Environment

Some of your requirements mentioned by the client may not fit the structure of functional and nonfunctional requirements mentioned above.

• Architecture Diagram: Include an architecture diagram to illustrate the system’s structure, components, and relationships. Clearly indicate which parts of the system are existing and which are planned, and show how different user roles will interact with the system.

• Architecture Description: Provide a high-level description of the system architecture. Explain how the system components work together and interact with the user roles.

• User-Interface: For example, it may be that your client didn’t specify the user interface in the form of a functional requirement. In this case here is place for you can deviate from the usual structure and instead show mock-ups of the planned user interface. Otherwise describe the nature of how users interact with the (e.g., desktop application, web app, or console application).

• Other: …

• Key Development Decisions: Summarize important decisions regarding tools or approaches that influenced implementation.

5. Deliverables and Deadlines (1-2 pages)

• Schedule: Specify the project begin and end.

• List of Deliverables: List and describe each deliverable, its completion date, and its specific format (e.g., code, documentation, test results, installation packages). For each deliverable, specify what is required, the expected amount, and how it will be submitted (e.g., via a link, physical media, or a code-sharing platform). Besides a completion date, also consider some time earlier a deliverable submission “dry-run” date, where the client can take a last look at the deliverables and mention any last wishes before the project end.

• Production and Testing Requirements: To ensure that the software can be used in the future, list and describe specific platforms, tools, libraries, and technologies, software dependencies and versions, and requirements for running it, for development, production and testing. Explain the environments and tools used for development and testing, including hardware requirements if any.

6. Risk Management (1-2 pages)

• Risk Identification and Mitigation: Identify project risks, their potential impact, their likelihood and how they will be mitigated. Document risks with their likelihood, potential impact, and strategies for managing them. Explain how these strategies for managing and mitigating risks have influenced the development processes you explained earlier. For example, here are two important risks:
  • Team Availability: What happens if a team member is absent for an extended period due to illness?
  • Resource Availability: Identify critical resources (e.g., lab access, system administrators, or cloud services), and assess their availability. Consider the impact of resource unavailability on the project.

7. Legal Considerations (0.5-2 pages)

• Usage Rights and Licensing: Define whether and how usage rights will be assigned to the client. Specify any software licenses (e.g., open source).

• Confidentiality and Agreements: Clarify any confidentiality agreements or restrictions. Define what can be expected from the client regarding communication and support.

8. Reflection and Key Learnings (1-2 pages)

• Project Retrospective and Key Insights: Reflect on the project as a whole, discussing successes, challenges, and lessons learned. Discuss how you addressed the challenges you experienced and relate it to your risk mitigation strategies. Summarize what worked well, what could have been improved, and the major takeaways from the project experience.

• Actionable Recommendations: Suggest concrete, actionable improvements to address challenges. Focus on processes, tools, communication, scope. Highlight how these changes could benefit future teams or similar projects.

Poster

Hand in a poster that illustrates your work. It should contain the following information:

Final Code Submission

Submit the final version of your project’s source code via https://next.hessenbox.de by sharing the archive with your group mentor. The archive should include everything needed to build and run the project (if applicable). Make sure the repository is clean, well-documented, and contains a README with setup instructions.

If you have additional assets that belong to your project (design files, datasets, etc.), include them in the archive or link them, as appropriate.