|Order of Activities
||During the first (closed) phase:
- Requirements engineering happens as a first closed phase in a project.
- At the end of the phase, the requirements are complete and in full detail.
- Later changes (change requests) are treated as exceptions.
|Done iteratively and in parallel to design, implementation, and testing:
- Activities go alongside the complete software life cycle.
- Stakeholders give their feedback about product increments delivered early.
- Requirements will be changed and refined following that feedback.
|Roles in the Organization
||Activities are performed by predefined roles:
- The requirements engineer role is often separate from other roles.
- Team members often occupy just one role:
- Product manager
- Business analyst
- Software engineer
- Each belongs to his or her respective organizational unit.
|Activities are performed by interdisciplinary teams:
- Each team member will have multiple roles:
- Requirements engineer
- Software engineer
- Each team member has to develop the necessary skills
||Stakeholders are involved in specific phases:
- Requirements engineering
- Proof of concept A-Sample (e.g., prototype)
- Test of B-Sample (functions are operational, components are not completely approved)
- Field test with C-Sample (All components of a serial production)
- Pre-production with D-Sample (preproduction sample)
|Collaboration with stakeholders and customers is continuous:
- Identify the functional requirements on a business case level
- Improve and, as needed, split the requirements so that they are "Ready" according to the definition
- Discover and consider nonfunctional requirements
- Confirm that requirements are fulfilled
||Experts predict what the customer wants:
- Marketing experts:
- Analyze the market
- Create customer segments
- Define and advertise the product-features
- Up until the product is delivered, customer segments and needs can change.
|Customer feedback determines the evolution of the product:
- Fast delivery of a minimalistic, useful product
- Gather real feedback from real customers
- Define customer segments with more detail (personas)
- Understand the needs of the customer segments
- Develop an intuition for innovations that will meet the customer segment needs
- Deliver product improvements quickly and get feedback
||Complete and detailed, as early as possible:
- There are many assumptions that will only be validated much later
- The long project duration makes changes within the environments more probable
- Documentation will be outdated and produce a lot of maintenance effort
|"Just enough" and "Just in time":
- Documents only cover what will produce lasting value for the stakeholders or the team
- Documentation goes only up to the necessary depth of detail
- Documents remain current, accurate, and useful for longer
- Example: Test cases enhance and detail the requirement documentation
|Feedback and Rework on Requirements
||Tedious and long-lasting rework:
- "First shot has to hit the goal"
- More effort and more defects in the process of adapting of the requirements to stakeholder feedback, new findings, contextual changes, and risk
|Fast follow-up of small, incremental changes and developments to the product:
- Knowledge gained in one sprint will be considered in the next one
- Continuous, direct feedback will allow a fast adjustment of the requirements