Requirements Engineering

Background Research

Before you start working on any kind of software, you should first always look at the project description first. This is to make sure that you know what kind of software you need to make. After looking into the project description, you should also do some research on the stakeholder of the project. Knowing your stakeholder will help you immensely by stopping you from misundertandings and small mistakes. 

 

To give you an example, when our team first got the project description, we quickly did some research on the topic as most of us didn't have expericence in the topic of the project. We also did some research on the stakeholders company to make sure we knew what kind of software they were expecting from us. The research we did was compiled into a report.



Dealing with Stakeholders

A software engineering project always has a stakeholder. A key part to success in the project is to keep the stakeholder updated and happy. This ensures that you won't have to waste time doing something that the stakeholder doesn't want. Before meeting the stakeholder, you should do some research and prepare potential plans and/or product to start discussions right away. 


Some of the things we summarized from our experiences of online meetings during the several meetups we had with our stakeholder (NIO):

Before the meeting:

  • It is important to confirm the time, meeting ID, and related materials with all team members.
  • Because reading large documents on-site is inconvenient, providing the documents in advance to the other party can be helpful, and it also shows that there will be a review during the meeting.

During the meeting:

  • The agenda can be directly displayed on the shared screen during the meeting for everyone to easily follow the meeting.
  • If there is a need for recording, always politely ask for permission at the beginning and only proceed after receiving said permission.
  • If the stakeholder prompts you to make a choice during negotiations, even if the decision is clear, it is better to answer with "we will discuss it with our team before giving you the answer" rather than making the decision there to avoid making wrong decisions.
  • If there is a notetaker, sharing the screen for mutual confirmation towards the end of the meeting can be beneficial. Conducting a meeting summary simultaneously helps prevent any deviations in communication.
  • Always remember to save the recordings of the meeting.

Some example of the meeting minutes we made from the meeting with NIO is on the right.




Below is a report about China's EV industry that we prepared at the beginning of the project for requirements. We expect this will be helpful to you.

Project specification


Research on NIO


Sample Agenda for Meeting with NIO



Sample Minutes for Meeting with NIO