Dear all,
I am currently, working on a project that needs requirements gathering. I do not have previous experience in collecting requirements and as such, I would like to summarise my thoughts in the hope that you may have some valuable advice to offer.
I have already started with a joint interview session with all stakeholders. The aim of this interview was to get a general appreciation of what the system does and the 'actors' that interact with it. I found out that the system has three user-types, two internal and one end-user while there are also a couple of external systems that need to integrate with it.
Now, my plan is to run individual discussions/workshops with each stakeholder separately so tha to run through each scenario. More specifically, I am planning of listing the activities each role should be able to accomplish and run through the journeys. I am hoping of capturing all this with Activity Diagrams and possibly some wireframe sketches on the whiteboard in order to help stakeholders with visualising this service. Then, I am planning of writing a requirements list, prioritise it (according to moscow) and write the use cases (diagram and specifications).
Is that a good plan? Not sure what should happen next. Do I involve our Designer here by asking him to design a few high level wireframes? Do I need to create an ERD too?
Many thanks in advance
sp_key,
Looks llike you have decent approach.
Couple of comments:
1. Instead of individual meetings I suggest you run a workshop. Its best to have all stakeholders and decision makers in the room at once, so they can agree the requirements as you are eliciting them. This will save you rework later.
2. Recommend you hold of the wireframes until after you know the requirements. Best to understand what they want before providing a solution.
Kimbo
Hi Kimbo,
Many thanks for your valuable input.
Should I also include the developers early in the process? I am concerned that if I do I'll be putting constraints straight away as they'll be approaching the problem from a development point of view. On the other hand, if I don't I may be missing important information.
Once again, many thanks for your advice
Sp.
Hi:
In addtion to Kimbo's suggestion, I suggest that you formally identify the project's scope with a context diagram. Could save alot of costly changes later.
Do you need an ERDs? It depends on how complex your project, but, from my experience yes, at least a few. Key question here is what are you going to use as inputs to creating your ERDs. In the ideal (which is very seldom actually done) you would first create data flow diagrams, which would then be used to create a logical data dictionary, from which you would then create ERDs. Again, few create a logical data dictionary, but, knowing what one is - that is knowing the ideal - is very helpful, as with that knowledge, you are much better prepared to pragmatically do what you can.
Tony
Sp,
I try to avoid having developers in requirements meetings. In my experience, they will always try to limit the business's requirements to what they imagine they can build easily. This stops the business from saying what they really want. I like to promote some blue sky thinking early on, so people think outside of the box - it can produce some very creative results.
If you are forced to include developers than try to only have them in there as observers. If that doesn't work, escalate to your project manager. If that doesn't work, get another job :)
Regarding ERDs, as part of defining requirements, functionality, business rules, I often come up with a business domain definition. this is a set of classes that I define using a UML class diagram. ERDs are the old fashioned way but they work too.
brought to you by enabling practitioners & organizations to achieve their goals using: