Before the project team can successfully implement requirements, they need a clear understanding of the functional, non-functional and other key characteristics of those requirements. The elicitation phase of RAMP (Requirements Analysis and Management Process) describes the activities you perform to interact with stakeholders, to discover their essential product or application needs, and gain the understanding necessary to specify them in more complete detail. While the other activities discussed in this webinar series are important, eliciting and specifying the project requirements are the real heart of your work.
In this webinar you will learn how to:
• Plan requirements elicitation meetings with end users and stakeholders
• Facilitate requirements elicitation meetings with end users and stakeholders
• Interview end users and stakeholders to identify essential business needs
• Confirm the project goals, applicable processes, and required capabilities
• Gather requirements notes, capability details, and related information
I am listening to the webinar “RAMP”. Document, document and document the requirements. Agile methodology especially SCRUM seem to focus on communications (talk, talk and talk) among the team members and doesn’t emphasize on documentation. How do we effectively manage requirements? Any suggestions?
If the code passes the acceptance test, the requirements worked. Eliciting and communicating the requirements is vital; ‘documenting’ requirements should only occur as needed to effect communication. Agile methods produce documentation (user help, operations manuals) but only enough write requirement (or dessign) artifacts to build and test the solution.
A lot of this has to do with timing. If we spend a few months defining requirements, then a few more developing code, then a coupel of months testing — the requirements need to be written completely and clearly so that a tester can make sense of them 6 months after the conversation in which they were elicited. If the elicitation occurs in front of the developer and tester during the same week that we build and test the software, we don’t need much written down because everyone was in the meeting about this just a few days ago.
The corollary is size. If I’m describing a feature which can be implemented and tested in a couple of days, it probably isn’t very big, so even if we wrote it down, there wouldn’t be much there. It may take longer to type a testable description than it does to write the test — just create the test. When the software passes the test, move on to the next feature.
How would RAMP support that fast-cycle method?
What you are describing in the webinar is for waterfall, not iterative.
We use a unified process framework, and only detail requirements just-in-time, as needed — purposely avoiding detail up front. We gradually detail just portions of use cases (individual flows) across the sprectrum of requirements, building software as we go.
We don’t want analysts to be note-taking scribes writing everything down uncritically. We need them to be thinkers who challenge the requested features to learn the true needs behind those, so the development team is free to innovate a solution.
Does RAMP support that kind of graduated, incremental development of use cases over time?
Requirements Elicitation with RAMP http://bit.ly/cKpdSA
Really good post!
Nice article. Thank you for this info
Wonderful position!