9 Fundamental Rules for Requirements Engineering Tasks

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

rating: +1+x

If you want to know more about a topic, simply tag the article with a 'morePlease' or 'examplesPlease' tag!

BlinkListblogmarksdel.icio.usdiggFarkfeedmelinksFurlLinkaGoGoNewsVineNetvouzRedditYahooMyWebFacebook

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License