Lecture 1: Introduction to Requirements Engineering File
 req. must be correct and complete
 Requirement – A condition or capability needed by
stakeholders to solve a problem or achieve an objective.
 A condition that must be met by a system or
system component to satisfy a contract,
standard, specification, or other formally
imposed documents.
 A documented representation
 Requirement Engineering – systematic and disciplined
approach to a specification and management of
requirement which:
 Understand relevant req.
 Documenting req.
 Check if req. meet quality criteria
 Achieve consensus among stakeholders
 Manage req. to minimize risk
 Scoping – to decide which part of work shall be handled
by the developing system.
 Requirement Types
 Functional – concern a result of behaviour that
shall be provided by a function of the system
 Quality (non-functional) – related to a quality
concern that is not covered by functional
requirements.
 Define the system’s: Performance,
Reliability, Usability, Maintainability,
Portability, Security (PRUMPS)
 Constraint (non-functional) – limits the solution
space that is necessary for meeting the given
functional requirements and quality
requirements
 Stakeholder – A person, a group of people or an
organization that has an influence on the requirements
of the developing system.
 E.g. Top management, Business/IT consultant,
Project Manager, Domain Experts,
Business/System Analyst, Requirement
engineer, Customers
 Requirement problem
 Does not reflect the real needs of the customer
for the system
 Inconsistent and incomplete
 Expensive to make changes after agreed
 Misunderstandings between customers, system
requirements and software engineers
 What happens when requirements are wrong? –
Systems will be late, unreliable and don’t meet
customers or business needs.
 Why should engineer requirements?
 req. are often unclear in the beginning
 Project must handle large numbers or req.
 System context – part of system’s environment
being relevant to understand the system and its
requirement.
 Requirements Engineering Process Model by K.
Pohl, Springer 2010
Figure 1 - System context: Requirement sources
 RE Processes
 Req. Elicitation – to obtain and refine
requirements from stakeholders
 Req. documentation – to document
formal statement of system req.
 Req. validation and negotiation – to
check, analyse req. and resolve conflicts.
 Req. management – to make req.
traceable, to prepare req. view, to
maintain consistency and to ensure
implementation.
 Software development process models
 Activities: Project Initiation (PI), Business
Modelling (BM), Requirements (R),
Analysis & Design (A&D), Implementation
(I), Test (T), Deployment (D),
Maintenance (M)
 Models:
 Waterfall model - Sequential
 Rational Unified Process (RUP) –
helps resources from being wasted
and to reuse of components.
 SCRUM – Agile; req. can be
documented according to the
sprint.
 Characteristic of RE: Analytical thinking, Empathy,
Moderation skills, Self-confidence, Conflict
resolution skills and Persuasiveness.