Model - abstract representation of a system

• reduces complexity
• clear terminology
• enables communication between developers and experts
  • application domain
  • solution domain

Application Domain

concepts that software developers are not familiar with

Solution Domain

provides developers with many competing implementation technologies

1. Round corners mean it’s an activity
2. Normal corners mean it’s a artifact/product of an activity

Elicitation

1. How can we identify and quantify the purpose of the system?

• What are the requirements?
• What are the quality attributes?
• What are the external constraints?

2. How can we identify the system boundaries?

• What is inside the system?
• What is outside the system?

Type of Projects (engineering)

• Greenfield engineering
  • Development from scratch, no prior systems
  • Triggered by user needs
• Re-engineering
  • Re-design/implementation of an existing solution
  • Triggered by new/changing technologies or needs
• Interface engineering
  • Provide new services of an existing system in a new environment
  • Triggered by new/changing technologies or market needs

Type of Requirements

• Functional requirements
  • Define what the software is supposed to do (it’s functionality or features from the user perspective)
• Quality attributes
  • Describe how well the system performs or behaves (e.g., performance, security, maintainability)
• External constraints
  • Define limitations or conditions imposed on the system, often from outside (e.g., legal regulations, hardware platforms, budget, deadlines)

User Stories

• what the user does and needs: As a [actor/role], I want [an action] so that [benefit/value]
• specific
• focused
• completed within a single sprint
• Acceptance criteria - makes user story assessable and testable

INVEST

• Independent: avoid overlapping user stories
• Negotiable: basis for discussion between development team and product owner
• Valuable: for the user and the business & Vertical: we plan and develop features and not layers
• Estimatable: the user story on the product backlog represents the basis of the project plan
• Small: too large user stories must be partitioned into smaller ones to avoid increasing complexity and long implementations
• Testable: - if a user story is not testable, it might not of real value for the product, this also implies realizability

Acceptance Criteria