Course Artefacts

Besides the main project results, we expect you to produce a number of artefacts in the course of the Software Engineering Project. These artefacts 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 for the project report
  • Project report
  • Poster

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. The document must be approved by the customer.

Deadline

  • Final Approval by Customer: Fr. 29.11.2024
  • To meet this deadline, an earlier version should be completed and submitted for feedback well in advance.

SEP Project Report and Draft

This report describes your project as well as the development process you follow throughout the semester. The report must cover the areas listed below.

By 17.12.24, prepare a short draft of your project report and submit it to your mentors. For each section outlined in the report description, 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.

By 28.02.25, submit the full report.

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.

  • 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.

9. 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

By 07.03.25 hand in a poster that illustrates your work. It should contain the following information:

  • Project Title: Use the project title as poster title. If your project also has a logo, provide it, too. Put TU Darmstadt’s logo next to the project title.
  • Team: Present your team in a way you feel comfortable with. For instance by a photo and your first names
  • Customer: Present your customer with their name and logo.
  • Project: Describe the project you worked on and the problem you solved. Also describe the main deliverable of your project.
  • Technologies: Provide an overview of key technologies you used. For instance, which programming languages and frameworks did you use? Did you rely on any specific build or dev/ops tools or environments? We suggest to present each technology by an icon and name.
  • Key Features: Provide an overview of the key features of your project. If you deem it appropriate, include screenshots of the tool/website app/etc you developed.
  • URL, QR-code: In case your finished project or the source code are publicly available, please include a link or QR code.
  • Format: The poster should be DIN A2 with sufficient margins to fit within the hallway frames. Please submit both a digital version and a physical copy.