Principles or Requirements Engineering Flashcards
8 principles of re
stakeholders
problems, reqs and solutions
value-orientation
shared understanding
validation
evolution
innovation
systematic work
stakeholders
Different viewpoints by different stakeholders must be taken into account, The viewpoints and needs of different stakeholders may conflict
- Requirements Engineering implies:
1. Discovering conflicts and inconsistencies
2. Negotiating
3. Moderating
4. Consensus finding
- But: also determine where variability is needed
problems, reqs and solutions
- Having a problem, we need requirements for a system that solves the problem
-
Traditional Requirements Engineering: the waterfall
- Start with a complete specification of requirements
- Then proceed to designing and implementing a solution
-
Specification and implementation are inevitably intertwined:
- Hierarchical intertwinement: high-level design decisions inform lower-level requirements
- Technical feasibility: non-feasible requirements are useless
- Validation: what you see is what you require
reqs vs. solution decisions
- Solution decisions inform lower level requirements
- Requirements and solutions are inevitably intertwined
What vs How in Requirements Engineering
Traditional belief:
WHAT = Requirements, HOW = Technical Design
Distinguishing requirements and solutions operationally
- If a statement is owned by stakeholders (i.e., changing it requires stakeholder approval), it’s a requirement
- If a statement is owned by the supplier (i.e. the supplier
may change it freely), it’s part of the technical solution
value orientation
- raditional Requirements Engineering: always write a complete specification
- But…
- Customers typically pay for systems, not for requirements
- Many successful projects don’t have a complete specification
- Good Requirements Engineering must create value
- Value comes indirectly
Value of a requirement
- The benefit of reducing development risk (i.e. the risk of not meeting the stakeholders’ desires and
needs) - minus the cost of specifying the requirement
assesment of risk
Low risk: little RE ↔ High risk: full-fledged RE
- Assess the criticality of the requirement
- Consider other factors
- Use requirements triage techniques
Risk-based RE
- Right question: “How much RE do we need such that the risk of deploying the wrong system becomes acceptable?”
-
Rule:
The effort spent for Requirements Engineering shall be inversely proportional to the risk that one is willing to take.
shared undertsanding
- a basic prerequisite for any successful development of systems
- Created, fostered and assured in Requirements Engineering
validation
picture
evolution
Keeping requirements stable while permitting requirements to change
innovation
- Don’t just automate – satisfying stakeholders is not enough.
- More of the same will not excite anybody.
- Strive for making stakeholders happy.
- Innovative requirements are the key.
systematic work
- Requirements need to be elicited, documented, validated and managed systematically
- using a suitable process
- with suitable practices
- Also applies for agile development, just with a different process and maybe different practices
- Systematic does not mean “One size fits all”
- Adapt your processes and practices to the problem
-
No unreflected reuse of RE techniques from previous
projects
