tag:blogger.com,1999:blog-18719136.post114221152093041803..comments2023-05-16T05:26:36.701-04:00Comments on From start to end: Requirements versus requirements managementMarcus Ting-A-Keehttp://www.blogger.com/profile/03667986666160492725noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-18719136.post-1145338803439384812006-04-18T01:40:00.000-04:002006-04-18T01:40:00.000-04:00I agree with you. Perhaps, I've oversimplified my ...I agree with you. Perhaps, I've oversimplified my analogy and thus miscommunicated what I was trying to say.<BR/><BR/>To me a requirement is a construct based on a clients' elicitation of their wants (e.g., a client must explain what & why they want something.) You need to dig because sometimes people only tell you the symptoms of what ails them, not the actual problems they are trying to solve.<BR/><BR/>Requirements management deals more with the management of all of the elicited requirements so that the project can be understood, changes can be managed and inconsistencies eliminated.<BR/><BR/>I'm not sure I would say requirement elicitation is the first stage of the requirements gathering process. Would it be fair to say that prior to engaging on a project, you need to have a basic idea about the nature of the project? This helps you put context into what clients are saying.<BR/><BR/>For many projects you'll need to talk to different people each with their own ideas and vision. As a business analyst you have to meld these ideas together, clear up inconsistencies and communicate your requirements to business and IT groups.<BR/><BR/>Requirements management has the following objectives:<BR/>1) Provide structure that allows you to organize requirements. Which in turn makes it easier to identify <A HREF="http://rationalizedthoughts.blogspot.com/2005/11/good-requirements-part-iv-be_22.html" REL="nofollow">conflicts</A> and communicate.<BR/>2) It allows you to start looking at requirements in modular reusable parts (similar to object orientation.) You define the functionality in one place and can simply reference it in other places. So now updates are easier and <A HREF="http://rationalizedthoughts.blogspot.com/2005/11/good-requirements-part-vi-traceability.html" REL="nofollow">traceability</A> is maintained. This is harder to do without some sort of requirements management product like Telelogic DOORS, CalibreRM or RequisitePro.<BR/>3) We all know that requirements change. Requirements management allows you to identify different versions of a requirement. Using the traceability you can analyze the impact of a potential change. You can also maintain multiple versions of a requirement set. This is very important when more Agile development methodologies are employed.<BR/><BR/>MarcusMarcus Ting-A-Keehttps://www.blogger.com/profile/03667986666160492725noreply@blogger.comtag:blogger.com,1999:blog-18719136.post-1145254145355038122006-04-17T02:09:00.000-04:002006-04-17T02:09:00.000-04:00So when you mention that requirements are actually...So when you mention that requirements are actually differnt from requirements management, that obviously sounds so, but the stuff that confuses me is when you say requirements management is like symphony of many instruments, rather i would like to believe it has several steps which should be taken care of from the various available option but definately in a particular sequence.<BR/><BR/>As Requirement elicitation would be the first step towards the requirement gathering, wont it be easy for some one trying to learn the Requirement Gathering process to understand requirement elicitation as a part of Req. gathering process..vijayhttps://www.blogger.com/profile/02079196575856979985noreply@blogger.com