XB_0032 Requirements Engineering
Module 1
➤1.2 Introduction to Software Engineering and Software Development Processes
• Software Engineering: Engineering discipline that is concerned with all aspects of software
production from the early stages of system specification through to maintaining the system after is has
gone into use.
• How this systematic approach is implemented depends on a few things:
- The organization developing the software
- The type of software
- The people involved in the development process
• Software manages complexity, is invisible until something goes wrong, enables the cloud and
connects, and saves lives.
• There are no universal software engineering methods that are suitable for all systems.
• Software Development Processes: Set of related activities that lead to the production of a software
product. It orders activities in order to make them predictable and repeatable.
• These processes can differ from each other but always have 4 main development activities:
- Specification
- Design & Implementation
- Validation
- Evolution
• They’re independent of the used process that simply affects flow among the activities.
• Software processes have changed through time, when software
engineering was starting to become a discipline in the 70s, there was a
focus on plan-driven developments.
• People believed that requirements would remain stable, thus made
preplanned models like Fig.1.2.1. Plan-driven development is very
heavy weighted since it very document focussed.
• In the 90s software began looking different and the focus shifted to
incremental development, where there was quick delivery and also Fig.1.1 Waterfall model
changing and unpredictable requirements.
• Agile processes/methodologies are a type of incremental development.
• In agile development documentation is reduced, so it’s light weight as
it changes things without requesting it first as a plan-driven
development does.
• There are a few agile principles:
- Frequent releases of the product
- Continuous interaction between the development team and customer Fig.1.2 Agile model
- Reduced product documentation
- Continuous and systematic assessment of produced value and risks
• How agile looks in practice is as follows:
1. Make a list of features/requirements
2. Estimate the time it’ll take
3. Set priorities based on the estimation
4. Start executing
5. Update the plan at run-time
➤1.3 Introduction to Requirements Engineering
• Requirement:
- A need perceived by a stakeholder
- A capability or property that a system shall have
- A documented representation of a need, capability or property
• Requirement Specification: A collection of requirements. With plan-driven developments, a
systematically represented collection of requirements, typically for a system or component.
• In agile projects requirements don’t need to be systematic. Instead, they express requirements in:
- User stories, issues, storyboards, acceptance criteria associated with user stories etc.
- A vision document
- Implicit shared understanding among the people involved.
, • Requirements Engineering: A systematic approach for the specification and management of
requirements with the following goals:
1. Knowing the relevant requirement, achieving a consensus among the stakeholders, documenting
them according to given standards and managing them systematically.
2. Understanding and documenting the stakeholders’ desires and needs.
3. Specifying and managing requirements to minimize the risk of delivering a system that doesn’t
meet the stakeholders’ desires and needs.
• Requirements Engineering results in a lower cost and it manages risk, since you avoid errors and
rework by meeting the stakeholders’ desires and making reliable estimates for deadlines and costs.
• The economic effects of Requirements Engineering are almost always indirect.
• Stakeholder: A person or organization that has a direct or indirect influence on the system’s
requirements. Indirect influence also includes situations where people are impacted by the system.
• There are different types of requirements:
- A function → what the system should do
- A behavior → how it should work
- A project requirements → how the project should be fulfilled
- A legal constraint → legality of the software
- A performance attribute
- A quality attribute
• Requirements can either be about the system, the project or the process. There are different types of
systematic requirements:
- Functional → Revers to the functionality and behavior. Prescribes what services the software-to-
be should provide.
- Non functional → Constrain how such services should be provided
‣ Quality
✦ Performance → Revers to the time and space bounds
✦ Specific quality → Revers to other “-ilities” such as reliability, usability, portability etc.
‣ Constraint → Revers to physical, legal, cultural, environmental and more types of constraints.
➤1.4 Principles of Requirements Engineering
• There are 8 basic principles, related to:
1. Stakeholders
- Viewpoints and needs by different stakeholders may conflict.
- So Requirements Engineering here implies:
‣ Discovering conflicts and inconsistencies
‣ Negotiating
‣ Moderating
‣ Consensus finding
‣ Determine where variability is needed
2. Problems, requirements & solutions
- Traditional Requirements Engineering: the waterfall
‣ Start with a complete specification of requirements, then proceed designing and
implementing a solution.
‣ This does not work properly in most cases.
- 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
- If a statement is owned by stakeholders, it’s a requirement.
- If a statement is owned by the supplier, it’s part of the technical solution.
3. Value-orientation
- Requirements shall deliver value, but it comes indirectly
- Value of a requirement: The benefit(profit) of reducing development risk minus the cost of
specifying the requirement.
- Adapt the effort put into RE such that the specification yields optimum value.
- Assessment of value requires assessment of risk.
- By assessing risk, you need to assess the criticality of the requirement and consider other
factors like specification effort, distinctiveness, shared understanding and reference systems.
- The effort spent for RE shall be inversely proportional to the risk that one is willing to take.
Module 1
➤1.2 Introduction to Software Engineering and Software Development Processes
• Software Engineering: Engineering discipline that is concerned with all aspects of software
production from the early stages of system specification through to maintaining the system after is has
gone into use.
• How this systematic approach is implemented depends on a few things:
- The organization developing the software
- The type of software
- The people involved in the development process
• Software manages complexity, is invisible until something goes wrong, enables the cloud and
connects, and saves lives.
• There are no universal software engineering methods that are suitable for all systems.
• Software Development Processes: Set of related activities that lead to the production of a software
product. It orders activities in order to make them predictable and repeatable.
• These processes can differ from each other but always have 4 main development activities:
- Specification
- Design & Implementation
- Validation
- Evolution
• They’re independent of the used process that simply affects flow among the activities.
• Software processes have changed through time, when software
engineering was starting to become a discipline in the 70s, there was a
focus on plan-driven developments.
• People believed that requirements would remain stable, thus made
preplanned models like Fig.1.2.1. Plan-driven development is very
heavy weighted since it very document focussed.
• In the 90s software began looking different and the focus shifted to
incremental development, where there was quick delivery and also Fig.1.1 Waterfall model
changing and unpredictable requirements.
• Agile processes/methodologies are a type of incremental development.
• In agile development documentation is reduced, so it’s light weight as
it changes things without requesting it first as a plan-driven
development does.
• There are a few agile principles:
- Frequent releases of the product
- Continuous interaction between the development team and customer Fig.1.2 Agile model
- Reduced product documentation
- Continuous and systematic assessment of produced value and risks
• How agile looks in practice is as follows:
1. Make a list of features/requirements
2. Estimate the time it’ll take
3. Set priorities based on the estimation
4. Start executing
5. Update the plan at run-time
➤1.3 Introduction to Requirements Engineering
• Requirement:
- A need perceived by a stakeholder
- A capability or property that a system shall have
- A documented representation of a need, capability or property
• Requirement Specification: A collection of requirements. With plan-driven developments, a
systematically represented collection of requirements, typically for a system or component.
• In agile projects requirements don’t need to be systematic. Instead, they express requirements in:
- User stories, issues, storyboards, acceptance criteria associated with user stories etc.
- A vision document
- Implicit shared understanding among the people involved.
, • Requirements Engineering: A systematic approach for the specification and management of
requirements with the following goals:
1. Knowing the relevant requirement, achieving a consensus among the stakeholders, documenting
them according to given standards and managing them systematically.
2. Understanding and documenting the stakeholders’ desires and needs.
3. Specifying and managing requirements to minimize the risk of delivering a system that doesn’t
meet the stakeholders’ desires and needs.
• Requirements Engineering results in a lower cost and it manages risk, since you avoid errors and
rework by meeting the stakeholders’ desires and making reliable estimates for deadlines and costs.
• The economic effects of Requirements Engineering are almost always indirect.
• Stakeholder: A person or organization that has a direct or indirect influence on the system’s
requirements. Indirect influence also includes situations where people are impacted by the system.
• There are different types of requirements:
- A function → what the system should do
- A behavior → how it should work
- A project requirements → how the project should be fulfilled
- A legal constraint → legality of the software
- A performance attribute
- A quality attribute
• Requirements can either be about the system, the project or the process. There are different types of
systematic requirements:
- Functional → Revers to the functionality and behavior. Prescribes what services the software-to-
be should provide.
- Non functional → Constrain how such services should be provided
‣ Quality
✦ Performance → Revers to the time and space bounds
✦ Specific quality → Revers to other “-ilities” such as reliability, usability, portability etc.
‣ Constraint → Revers to physical, legal, cultural, environmental and more types of constraints.
➤1.4 Principles of Requirements Engineering
• There are 8 basic principles, related to:
1. Stakeholders
- Viewpoints and needs by different stakeholders may conflict.
- So Requirements Engineering here implies:
‣ Discovering conflicts and inconsistencies
‣ Negotiating
‣ Moderating
‣ Consensus finding
‣ Determine where variability is needed
2. Problems, requirements & solutions
- Traditional Requirements Engineering: the waterfall
‣ Start with a complete specification of requirements, then proceed designing and
implementing a solution.
‣ This does not work properly in most cases.
- 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
- If a statement is owned by stakeholders, it’s a requirement.
- If a statement is owned by the supplier, it’s part of the technical solution.
3. Value-orientation
- Requirements shall deliver value, but it comes indirectly
- Value of a requirement: The benefit(profit) of reducing development risk minus the cost of
specifying the requirement.
- Adapt the effort put into RE such that the specification yields optimum value.
- Assessment of value requires assessment of risk.
- By assessing risk, you need to assess the criticality of the requirement and consider other
factors like specification effort, distinctiveness, shared understanding and reference systems.
- The effort spent for RE shall be inversely proportional to the risk that one is willing to take.
