Type: Rules
Gist
The RE in my projects follows these guidelines. They represent a fundamental, i. e. not negotiable set.
Rules
P1: Requirements are driven by business; technical aspects or solutions to problems never constrain requirements without a clear, documented cause.
P2: Requirements with high business value will be analysed and realised first.
P3: We avoid defects in the system instead of testing them out.
P4: (Potentially) controversal discussions take place as early as possible. Unclear, risky or hard to describe requirements are analysed early.
P5: Bandwidth will be maximised while communicating requirements and while communicating on requirements.
P6: If a rule, standard or other regulatory asset - whether it originates from the outside or inside of the project - hinders understandability of a requirement, the rule will be ignored.
P7: Solutions (Designs) to requirements can occur, but only as suggestions w/o any legal consequences.
P8: The (document) "Requirements Management Plan" will be improved continuously.
P9: ruleset.PrioritizeInEvoDevelopments applies
Related Pages
- how to determine if a- equirement is atomic
- send the call for tenders
- specifying goals
- Root Causes of Poor Requirements (on Inside Architecture)
If you want to know more about a topic, simply tag the article with a 'morePlease' or 'examplesPlease' tag!
