Requirements Engineering

"What" the system should do (as opposed to "how")

Understanding the problem to be solved + all the constraints around it

Activities:

1. Elicitation = gathering of requirements (interview, workshop, focus groups.....)

2. Analysis = to understand the requirements and establish coredesign + conferences (modeling, UI prototypes, techononlygy......)

3. Specification = documentation + precision (writing user stories, itemized requirements)

4. validation = establishing that you solving the "right problem" that the customer consultancy (customer reviews, getting structure problem/MVP)

ELement of requirements:

• purpose of the software/"mission statement"

• stakeholders (customer, users, regulators, developers, maintainers, ......)

• project scope (context digram, what is in + what is out)

• assumptions

• implement constrains

• requirements

Requirements :

1. functional requirements (what functions the system should perform)

2. quality requrements (aka non-functional requirements): how well a system should do given, such as safety requirement. Including intend qualities (developer side) and extend qualities (user side), such as usability, look and feel, security and function perfermance.

Necessary properties of requirements

1. unambiguous -> clear, single meaning

2. consistent -> no contracdictory statements

3. complete -> all relevant requirements stated

4. verfiable -> I am tell it/check for fail

5. free of implementation bias -> forcus on what not how

Challenges of RE

• Distributed knowledge

• Domain experts usually don’t have time

• Tacit knowledge

• Political problems

• Both the undertanding and the problems to change