What are key parameters should be considered while capturing project stakeholder's interest?
Clarification added May 20, 2008:
This is typically a exercise while doing a requirement workshop with clients. Apart from the functional and non-functional requirements, is there any means one can engage with stakeholder to know more details which might influence heavilly on overall architecture. Is there any deciplined way to capture such things during requirement discussion
Answers (4)
Shyam S.
Seasoned Technology Architect
Best Answers in: Enterprise Software (12), Computers and Software (3), Software Development (3), Energy and Development (2), Starting Up (1), Green Business (1), Computer Networking (1)
Some suggestions.
1. Map with clarity the project visions and goals (vision, business goals) - business use cases will help
2. Map technical components with business requirements.
You can use enterprise architecture tools like Enterprise Architect to so detailed mapping.UML is recommended for capturing these details.
Another technique that I havde personally used is mapping (1) & (2) with QFD.
Hope this helps.
I can't come up with a useful list of parameters, but I highly recommend getting a general idea about requirements before the meeting, and providing the users with a few (very rough) options, perhaps a previous project. A lot of times when you're dealing with a client not directly involved in designing software, it's hard to get a clear view of expectations from just a question and answer session. Having something tangible to look at can really open up the client about his ideas, and help him focus on what exactly he wants.
Richard Z.
Consultant: QFD Red Belt, Six Sigma Master Black Belt, ToC Jonah
Best Answers in: Project Management (8), Quality Management and Standards (3), Software Development (3), Planning (2), Business Development (1), Organizational Development (1), Manufacturing (1), Market Research and Definition (1), Engineering (1), Product Design (1), Computers and Software (1)
I would suggest that the most important thing to understand about stakeholders is not "what" they want (functional and non-functional requirements), but "why" they want what they (think they) want (customer needs). And it is important to realize that most stakeholders are untrained in any requirements giving method -- so you will not get a complete set of requirements just by asking them for their requirements...
If their most important needs are clearly understood and quantified (and accurate priorities are required for this) then you can both check the stated requirements they gave you (stakeholders can make requirements errors too) and also derive unstated requirements (what they would have ask for if they were trained requirements-suppliers).
With a framework like modern Quality Function Deployment (QFD) you can then either work from functional requirements to architecture options (normal "forwards" QFD), or see if your preferred technical architecture will meet the needs of your stakeholders (reverse QFD).
Links:
Arvind, focus on "why" and "what" and let the stakeholder *feel* your enthusiasm about her project; because, it's really HER project.
People says that use cases are the "what", but lof of authors says that's some kind of "how". Because they says what the system should do in a "how " manner. Streamlined object Modelling says you should start your project by bulding up the erquirements with analysis using conceptual classes diagram (not ERD diagrams, please!). The conceptual classes are evolutive and talks about things that stakeholders know, common terms, that's the main key.
Don't use it terms if the stakeholder is not from it world. And the other key parameter: you should have a product manager who has to learn everithing about the stakeholder bussiness, with this, the meetings will be fluid.
Hope it helps.
Greetings,
Víctor
