Code is often refactored to simplify it and make it easier to maintain. A similar activity can be taken to clean up the requirements. Like code refactoring, refactoring requirements does not increase the number of features or fix bugs. The intent is to reduce complexity and ambiguity in the requirements so they are easier to manage and to improve the ability of the team to support and maintain the system.
When refactoring requirements look for duplicate requirements, ambiguous requirements, requirements that are difficult to test, and requirements that appear to contradict other requirements. This is also a good time to re-examine the Requirements Management Plan to see what should be added or removed. There may be attributes that track information the team doesn’t use, or traces between requirements that are never examined. Each item in a Requirements Management Plan requires overhead to maintain, so if it’s no longer needed it should be removed. Conversely, there may be some difficulties the team has had in managing requirements. This is a good time to add appropriate attributes, traces, or activities that will better support the environment.
Reference: IBM Rational Unified Process
Quote:
When you feel the need to write a comment, first try to refactor the code so that any comment becomes superflouus.
Martin Fowler
بانوی باران
۲۲ آبان ۱۳۹۱ در ۰۰:۰۰واقعا ممنون
متن روانی بود برای من که حوصله انگبیسی خوندن نداشتم