Requirements versus requirements management
How does requirement gathering and elicitation differ from requirements management?
Requirement elicitation refers to the process of understanding what a client wants and conveying this information to the project team so the client's needs can be addressed. Characteristics of atomic requirements are as follows: correctness, completeness, clarity, testability, and design independence.Requirements management refers to the active management of the needs of a project. This includes things such as:
- Organizing individual requirements into a mosaic that represent an initiative.
- Identifying requirement gaps or situations where a high-level requirement exists but lower-level ones do not. These situations identify areas where further probing may occur (recall in a previous post Defining requirements by priority I stated that areas with minimal or low benefit might not be investigated at all. That's why I say, may.) This provides visibility into the state of the requirements and can be extended into the design aspects of a project or beyond.
- Understanding how a change (or change request) to a requirement will impact other requirements; upstream and downstream. This is a function of traceability.
- Ensuring consistency for a set of requirements. No contradictions please.
- Reuse of components throughout. There will only be one place to make a change.
Requirements management can be done manually in something like MS Word or MS Excel, but the cost in terms of maintenance will be very high. As such, I would suggest you make use of tools such a Rational RequisitePro or Telelogic DOORS. These tools allow you to link between individual items and traverse the linkages easily. Traceability is what allows for the benefits of requirements management. However, to make requirements management useful, you must master the skill of gathering requirements first.
Think of it this way, view the gathering of a requirement as the construction of a single instrument. View requirements management as the symphony of many instruments working together in harmony.
2 comments:
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.
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..
I agree with you. Perhaps, I've oversimplified my analogy and thus miscommunicated what I was trying to say.
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.
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.
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.
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.
Requirements management has the following objectives:
1) Provide structure that allows you to organize requirements. Which in turn makes it easier to identify conflicts and communicate.
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 traceability is maintained. This is harder to do without some sort of requirements management product like Telelogic DOORS, CalibreRM or RequisitePro.
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.
Marcus
Post a Comment