Requirements engineering of a developer

Goran Madzar

22/06/2020

During one of my recent requirements engineering training courses, a hardware developer demonstrated in a homework assignment that he understood the topic and was capable of writing requirements. I found the requirements so well-written that I absolutely had to publish them on the blog. Many thanks to Ferdinand, the author of the requirements. I have made slight modifications, particularly to the names, to comply with data protection regulations.

Req1: The FERDINAND shall be involved into not more than 2 PROJECTs at the same time:

Hint: having more than one PROJECT: means working not parallel but serial at one PROJECT after the other.

Req2: The FERDINAND shall not work more than 8 hours a day.

Req3: The FERDINAND shall not work more than 5 days a week.

Req4: The priority of tasks shall be announced from RESPONSIBLE PERSONS in this sequence:

  1. CEO
  2. CTO
  3. Project Manager

Req5: The FERDINAND shall not be able to program code in any project he is involved. (FERDINAND is a hardware developer).

Req6: The FERDINAND shall have a defined interface to SW called Björn.

Hint: Commands can be given by speak, phone, mail or document.

Hint2: the commands shall be in a HW compatible language.

Req7: the FERDINAND shall be able to drink beer during work time specified in Req2+3.

Req8: The FERDINAND shall have an alarm signal when he is drinking more than 2 beers during work time specified in Req2+3.

Hint: Alarm signal can be spoken or Email and goes like “Wäääh!”

Re9: The FERDINAND shall have an error signal, if more than 2 RESPONSIBLE PERSONS have access to him at the same time:

Hint: Error signal can be spoken or Email and goes like “I’m all licking it..”

Req10: The FERDINAND shall have a safety function called LEGs. This safety function shall be activated if Req1-7 are violated by third.

Hint: LEGs can be used to run away or to give an ass kick.

Even though the requirements could be optimized in one place or another, my conclusion is still quite positive. As you can see, requirements engineering can be used in every situation, and it's not necessarily a dry subject ;-). If you also have good specifications, I'd be happy to hear about positive examples. For example, please leave a comment.

Best regards

Goran Madzar


Written by Goran Madzar

A passionate MEDtech engineer! My team and I provide engineering services to medical technology manufacturers to help them develop and market their products! Feel free to contact me via LinkedIn or email. I look forward to meeting you.


More articles

  • 26/02/2026
  • General, hardware, quality

According to the German Resuscitation Registry 2024, 370 people per day in Germany suffer a sudden cardiac arrest. That's over 136,000 cases per year, mostly occurring outside of hospitals. ...

Read more
  • 12/02/2026
  • General, hardware, mechanics, technology, testing, validation

How are sensors for cardiopulmonary resuscitation validated? In our case, we specifically asked this question for a sensor used to measure compression depth during resuscitation. Why is a CPR feedback sensor validated? ...

Read more
  • 05/02/2026
  • General, Hardware, Requirements Engineering, Software, Zephyr

What difference can a CPR feedback system make to cardiopulmonary resuscitation? In the event of cardiac arrest, the transport of oxygen to the body's cells stops immediately, leading to irreversible damage. The cells die. ...

Read more