Excellent! There is a lot of great practical info you can apply in real life. I would suggest instructors include some more info about SPM in the framework of startups (rather than client framework).
It is very good knowledge. But my English poor for that, was, sometimes. So was hard to understand and catch information. As a result 90% for grade. It is ok. But it is ok.\n\nViam supervadet vadens
By G S R•
This course is good for foundations for requirement gathering. The documentation aspects are covered in detail. But still, the coursework on analysing, workflow and prioritization can be improved because this too plays an important role when dealing with Dev team.
By Dirk S•
The target group are students without any experience. The quiz's live are made to test your knowledge of the English language.
By German D H•
not as well put together as the previous ones - perhaps you should consider breaking it into smaller, manageable pieces.
By Sheldon D S•
The material / question sets does appear ambiguous with little context to answer questions confidently.
By Cecil R•
The exam questions could have been written more clearly.
By Neha P•
Questions in the last assesment were quite confusing
By Mikhail K•
Too high level course. Expected more from it.
By Néstor d J M G•
By Katherine P Z•
Incredibly frustrated by the peer grading system. I've been able to work on the course at relatively fast pace and have now completed all of the lectures, readings, quizzes and test but can't go on to the next course because not enough people have submitted the homework for me to grade. I understand the advantage of being able to "learn from others" but it doesn't outweigh the disadvantage of not being able to work at one's own pace .
By Lino J J•
I don't know how useful the ambiguous requirements exercise is when we only have one-way feedback. I also think that the ambiguous requirements exercise is the most important of the course, and the exercise missed the mark.
I would suggest you structure that exercise as a dialogue, where a PM is working with the customer to elicit requirements, and not give us a big long wish-list of functionality. Structured as a dialogue, you can show that a PM would ask, "You said that the game would make noise. When is the first time it makes noise? How often would game noises be made? Does it ever stop? What makes it stop? Why even have the game make noise in the first place? Are there different noises made during the course of game play/"
So, I can't recommend this particular course, and I'm concerned about what the capstone will look like if you give us an assignment where we're to make sense of functionality delivered as a block of text .