I am developing a project using prototyping methodology. However, since end users are involved, I am thinking of user stories for requirements gathering. I can see that user stories are generally associated with AGILE methodology. So can I use it in a project that involves prototyping methodology?
since end users are involved, I am thinking of user stories for requirements gathering.
In line with the previous answer by Surkeet, user stories are written from the perspective of the user. Having them written in their language may make the communication between your development team and the user(s) smoother and based on a common vocabulary. The answer to this question is that "it depends". It really depends on the nature of your project. If the details of the user story (i.e. as a , I would like to so that ) is good enough for you, you have good-enough communication with your customer, and the nature your development tolerates iterations, then maybe user stories alone would be a good tactic to document and communicate requirements. However, there are cases where documenting requirements in terms of user stories is not enough. An example of that would the pressing need to agree on the non-functional requirements (a.k.a. quality attributes). An example of theses requirements is reliability, performance, and security. Especially in very large/critical systems that may fit an agile methodology, having to formally express non-functional requirements is a must. This is arguable and may start technical wars as some people do use user stories to document non-functional requirements.
So can I use it in a project that involves prototyping methodology?
Using user stories, however, is not the only tactic that you could use to develop effective prototype. Yes, it can be used to trigger the first iteration of prototyping and maybe govern the iterations of prototyping, but again it is not the only way. One could complement prototyping with different tactics that fits agile methodologies well such as storyboarding. Think of storyboards as an interactive, comic-like, representation of a given interaction to achieve a certain user-defined goal. The great thing about them is that they are graphical (as opposed to narrated bullet points of a use-case scenario), making them a powerful illustration tools. Here is a short article about the subject (link).
Also, I would recommend not thinking about Agile as a package that comes with techniques that you have to follow. Tailor the process to your needs.