Return to Answer

Whenever I hear student complaining about the approach taken by a professor, I advise them to watch Karate Kid 1.

Half of the film is about stupid tasks that a karate professor is making his student do and the student complains that he desperately wanted real lessons to learn to defend oneself. Spoiler alert (but it’s ok the film is 30 years old): Then in a situation of need and stress, the student suddenly realises that he’s able to effectively defend himself thanks to the reflex acquired during the stupid activities.

Requirement engineering is exactly alike. You can of course use directly modern Use Case 2.0 or User Story mapping. You can go kanban if you want. And you can also use plain old detailed use-cases with painfully detailed test cases of your professor. That’s ugly, but in your course you don’t have real users to experiment with other approach either.

Anyway, keep in mind that although you will not necessarily need this rather rigid practice, the underlying ideas are still relevant in many situations. Whether you do an up-front requirement specification in a traditional waterfall or v-model project or whether you elicit requirements just in time within iterations of an agile development, the key competence remains the same: to understand what a user really needs and to express the criteria to be verified for ensuring that the development meets that requirement.

Finally, these rather heavy documentation practices might be required in highly regulated industries where software is known to put millions of lives at risk (e.g pharma industry under GMP obligations).

One thing I fundamentally disagree with your professor is the repetitive character of requirement engineering. Requirements are not guessed out of the blue, but discussed and agreed with customers and users. And this is far from boring and repetitive but on contrary full of anecdotes and extremely enriching: if you want, you can learn everyday something new just working on requirements with users. And in my own opinion, nothing is more rewarding than the smile that means “yes! exacty! finally a person that understood my work” (actually there is: when the same smile remains when the software is delivered) :-)

Edit: Another thing that is not so great although still popular is some circles is what you call the worst part. Not only is this microstep by microstep cumbersome, it is also forcing decision on the design of the user interface made by people who are not necessarily skilled in user interface design and even less in user experience. Jacobson the inventor of UC recommended in his earlier work before Use Case 2.0 to prefer “essential use cases”, where there is no steps but only intents, focusing in this way on goals and leaving UX to experience designers. Try as an exercise to rewrite a couple of your UC using this technique, to understand the difference.

Whenever I hear students complaining about the approach taken by a professor, I advise them to watch Karate Kid 1.

Half of the film is about stupid tasks that a karate professor is making his student do and the student complains that he desperately wanted real lessons to learn to defend oneself. Spoiler alert (but it’s ok the film is 30 years old): Then in a situation of need and stress, the student suddenly realises that he’s able to effectively defend himself thanks to the reflex acquired during the stupid activities.

Requirement engineering is exactly alike. You can of course use directly modern Use Case 2.0 or User Story mapping. You can go kanban if you want. And you can also use plain old detailed use-cases with painfully detailed test cases of your professor. That’s ugly, but in your course you don’t have real users to experiment with other approach either.

Anyway, keep in mind that although you will not necessarily need this rather rigid practice, the underlying ideas are still relevant in many situations. Whether you do an up-front requirement specification in a traditional waterfall or v-model project or whether you elicit requirements just in time within iterations of an agile development, the key competence remains the same: to understand what a user really needs and to express the criteria to be verified for ensuring that the development meets that requirement.

Finally, these rather heavy documentation practices might be required in highly regulated industries where software is known to put millions of lives at risk (e.g pharma industry under GMP obligations).

One thing I fundamentally disagree with your professor is the repetitive character of requirement engineering. Requirements are not guessed out of the blue, but discussed and agreed with customers and users. And this is far from boring and repetitive but on contrary full of anecdotes and extremely enriching: if you want, you can learn everyday something new just working on requirements with users. And in my own opinion, nothing is more rewarding than the smile that means “yes! exacty! finally a person that understood my work” (actually there is: when the same smile remains when the software is delivered) :-)

Edit: Another thing that is not so great although still popular is some circles is what you call the worst part. Not only is this microstep by microstep cumbersome, it is also forcing decision on the design of the user interface made by people who are not necessarily skilled in user interface design and even less in user experience. Jacobson the inventor of UC recommended in his earlier work before Use Case 2.0 to prefer “essential use cases”, where there is no steps but only intents, focusing in this way on goals and leaving UX to experience designers. Try as an exercise to rewrite a couple of your UC using this technique, to understand the difference.

Whenever I hear student complaining about the approach taken by a professor, I advise them to watch Karate Kid 1.

Half of the film is about stupid tasks that a karate professor is making his student do and the student complains that he desperately wanted real lessons to learn to defend oneself. Spoiler alert (but it’s ok the film is 30 years old): Then in a situation of need and stress, the student suddenly realises that he’s able to effectively defend himself thanks to the reflex acquired during the stupid activities.

Requirement engineering is exactly alike. You can of course use directly modern Use Case 2.0 or User Story mapping. You can go kanban if you want. And you can also use plain old detailed use-cases with painfully detailed test cases of your professor. That’s ugly, but in your course you don’t have real users to experiment with other approach either.

Anyway, keep in mind that although you will not necessarily need this rather rigid practice, the underlying ideas are still relevant in many situations. Whether you do an up-front requirement specification in a traditional waterfall or v-model project or whether you elicit requirements just in time within iterations of an agile development, the key competence remains the same: to understand what a user really needs and to express the criteria to be verified for ensuring that the development meets that requirement.

Finally, these rather heavy documentation practices might be required in highly regulated industries where software is known to put millions of lives at risk (e.g pharma industry under GMP obligations).

One thing I fundamentally disagree with your professor is the repetitive character of requirement engineering. Requirements are not guessed out of the blue, but discussed and agreed with customers and users. And this is far from boring and repetitive but on contrary full of anecdotes and extremely enriching: if you want, you can learn everyday something new just working on requirements with users. And in my own opinion, nothing is more rewarding than the smile that means “yes! exacty! finally a person that understood my work” (actually there is: when the same smile remains when the software is delivered) :-)

Whenever I hear student complaining about the approach taken by a professor, I advise them to watch Karate Kid 1.

Half of the film is about stupid tasks that a karate professor is making his student do and the student complains that he desperately wanted real lessons to learn to defend oneself. Spoiler alert (but it’s ok the film is 30 years old): Then in a situation of need and stress, the student suddenly realises that he’s able to effectively defend himself thanks to the reflex acquired during the stupid activities.

Requirement engineering is exactly alike. You can of course use directly modern Use Case 2.0 or User Story mapping. You can go kanban if you want. And you can also use plain old detailed use-cases with painfully detailed test cases of your professor. That’s ugly, but in your course you don’t have real users to experiment with other approach either.

Anyway, keep in mind that although you will not necessarily need this rather rigid practice, the underlying ideas are still relevant in many situations. Whether you do an up-front requirement specification in a traditional waterfall or v-model project or whether you elicit requirements just in time within iterations of an agile development, the key competence remains the same: to understand what a user really needs and to express the criteria to be verified for ensuring that the development meets that requirement.

Finally, these rather heavy documentation practices might be required in highly regulated industries where software is known to put millions of lives at risk (e.g pharma industry under GMP obligations).

One thing I fundamentally disagree with your professor is the repetitive character of requirement engineering. Requirements are not guessed out of the blue, but discussed and agreed with customers and users. And this is far from boring and repetitive but on contrary full of anecdotes and extremely enriching: if you want, you can learn everyday something new just working on requirements with users. And in my own opinion, nothing is more rewarding than the smile that means “yes! exacty! finally a person that understood my work” (actually there is: when the same smile remains when the software is delivered) :-)

Edit: Another thing that is not so great although still popular is some circles is what you call the worst part. Not only is this microstep by microstep cumbersome, it is also forcing decision on the design of the user interface made by people who are not necessarily skilled in user interface design and even less in user experience. Jacobson the inventor of UC recommended in his earlier work before Use Case 2.0 to prefer “essential use cases”, where there is no steps but only intents, focusing in this way on goals and leaving UX to experience designers. Try as an exercise to rewrite a couple of your UC using this technique, to understand the difference.

Whenever I hear student complaining about the approach taken by a professor, I advise them to watch Karate Kid 1.

Half of the film is about stupid tasks that a karate professor is making his student do and the student complains that he desperately wanted real lessons to learn fighting. Spoiler alert (but it’s ok the film is 30 years old): Then in a situation of need to defend himself, the student suddenly realises that he’s able to effectively defend himself thanks to the reflex acquired unknowingly during the stupid activities.

Requirement engineering is exactly alike. You can use modern Use Case 2.0 or User Story mapping directly. You can go kanban. And you can also use plain old use cases with painfully detailed test cases. That’s ugly. But keep in mind that although you will not necessarily need it, the ideas behind these practices are still relevant. Moreover these practices might be required in highly regulated industries where software is known to put millions of lives at risk (e.g pharma industry under GMP obligations).

Whenever I hear student complaining about the approach taken by a professor, I advise them to watch Karate Kid 1.

Half of the film is about stupid tasks that a karate professor is making his student do and the student complains that he desperately wanted real lessons to learn to defend oneself. Spoiler alert (but it’s ok the film is 30 years old): Then in a situation of need and stress, the student suddenly realises that he’s able to effectively defend himself thanks to the reflex acquired during the stupid activities.

Requirement engineering is exactly alike. You can of course use directly modern Use Case 2.0 or User Story mapping. You can go kanban if you want. And you can also use plain old detailed use-cases with painfully detailed test cases of your professor. That’s ugly, but in your course you don’t have real users to experiment with other approach either.

Anyway, keep in mind that although you will not necessarily need this rather rigid practice, the underlying ideas are still relevant in many situations. Whether you do an up-front requirement specification in a traditional waterfall or v-model project or whether you elicit requirements just in time within iterations of an agile development, the key competence remains the same: to understand what a user really needs and to express the criteria to be verified for ensuring that the development meets that requirement.

Finally, these rather heavy documentation practices might be required in highly regulated industries where software is known to put millions of lives at risk (e.g pharma industry under GMP obligations).

One thing I fundamentally disagree with your professor is the repetitive character of requirement engineering. Requirements are not guessed out of the blue, but discussed and agreed with customers and users. And this is far from boring and repetitive but on contrary full of anecdotes and extremely enriching: if you want, you can learn everyday something new just working on requirements with users. And in my own opinion, nothing is more rewarding than the smile that means “yes! exacty! finally a person that understood my work” (actually there is: when the same smile remains when the software is delivered) :-)