# data[].attributes.headline
URN models can be used to specify and analyze various types of (proposed or evolving) reactive systems, business processes, and telecommunications standards

# data[].attributes.subject
URN models can be used to specify and analyze various types of (proposed or evolving) reactive systems, business processes, and telecommunications standards

# data[].attributes.headline
URN Formalizes and integrates two notations:

# data[].attributes.subject
URN Formalizes and integrates two notations:

# data[].attributes.body
 Goal-oriented Requirement Language (GRL)

 Use Case Maps (UCMs) for expressing scenarios

# data[].attributes.body
 helps understanding and communicating goals
 complements template-based documentation

Goal modeling method consists of language, rules, guidelines and management practices

# data[].attributes.headline
apply the following steps to weaken the restrictions:

# data[].attributes.subject
apply the following steps to weaken the restrictions:

# data[].attributes.body
1. Elicit the actual, solution/constraint-free super-goal that is behind the required solution by asking “why” questions.

2. Try to identify viable solution alternatives for the super- goal.

3. Document the identified, alternative solutions as sub-goals of the solution-free super-goal using an OR-decomposition.

# data[].attributes.headline
Documenting Goals using templates (structured)

# data[].attributes.subject
Documenting Goals using templates (structured)

# data[].attributes.body
Template-based documentation of goals offers significant advantages.

# data[].attributes.headline
Documenting Goals using unstructured natural Language

# data[].attributes.subject
Documenting Goals using unstructured natural Language

# data[].attributes.body
Unstructured approach implies specifying goals one after the other in free text, without any specific rules.

# data[].attributes.body
 Using unstructured natural language.

 Using templates (structured)

 Using dedicated goal modeling languages.

# data[].attributes.headline
Context changes affect goal dependencies

# data[].attributes.subject
Context changes affect goal dependencies

# data[].attributes.body
Example:
Change of a data protection law in a country may prohibit the electronic localization of a car

# data[].attributes.headline
An “obstruction” dependency cannot exist between goals that are part of an AND-decomposition

# data[].attributes.subject
An “obstruction” dependency cannot exist between goals that are part of an AND-decomposition

# data[].attributes.body
Goals can have the following types of dependencies between each other:
 Requires
 Support
 Obstruction
 Conflict

 Equivalence

for more details and examples lecture 5 slides 13 to 18

# data[].attributes.body
7 to 9
and 22
and 27
and 28
and 30 to 34
Important to read from 35 to the end (GRL)

# data[].attributes.body
1- goals
2- Scenarios

3- solution-oriented

for more details lecture 4 slides 35 to 37

# data[].attributes.body
1- Validation
2- Management

# data[].attributes.body
1- Elicitation (content dimension)
2- Negotiation (agreement dimension)
3- Documentation (documentation dimension)

for more details lecture 4 slide 28

# data[].attributes.body
1- Subject facet: Objects and events relevant for the system.

2- Usage facet: Aspects concerning the usage by people or other systems.

3- IT system facet: Objects and elements of the IT system environment of the system

4- Development facet: Aspects concerning the development process of the system

examples lecture 4 slides 24 and 25

# data[].attributes.body
may be true or false

# data[].attributes.headline
Use goals and scenarios to check whether specific aspects of the environment are relevant for the system or not. If an aspect is relevant, it should affect at least one goal or one scenario.

# data[].attributes.subject
Use goals and scenarios to check whether specific aspects of the environment are relevant for the system or not. If an aspect is relevant, it should affect at least one goal or one scenario.

# data[].attributes.body
17
and 20
and 32 to 34

# data[].attributes.headline
Grey Zone between the System and the Context

# data[].attributes.subject
Grey Zone between the System and the Context

# data[].attributes.body
During requirements engineering, the system boundary as well as the interfaces are typically unstable (that you can decide is a part of system or part of context)

# data[].attributes.body
The context boundary separates the relevant part of the environment of a system to be developed from the irrelevant part, i.e., the part that does not have to be considered during requirements engineering.

# data[].attributes.body
The system boundary separates the system to be developed from its environment, i.e., it separates the part of the reality that can be modified or altered by the development process from aspects of the environment that cannot be changed or modified by the development process.

# data[].attributes.body
The system context is the part of the system environment that is relevant for the definition as well as the understanding of the requirements of a system to be developed.

# data[].attributes.headline
System environment significantly influences requirements for the system

# data[].attributes.subject
System environment significantly influences requirements for the system

# data[].attributes.body
A wrong assumption about the behavior of an external system will most likely lead to an incorrect definition of the requirement specifying interaction with the external system.

# data[].attributes.headline
Software-intensive systems are always embedded in environment 

# data[].attributes.subject
Software-intensive systems are always embedded in environment 

# data[].attributes.body
environment
Technologies, business processes, existing software components, people, laws, etc.

# data[].attributes.body
The vision and the system context are thus the two essential inputs for the RE process

The main goal of RE is to:
"establish a vision within an existing context"

# data[].attributes.body
Each software-intensive system is embedded within a "system context" that contains the requirement sources and strongly influences the definition of the system requirements.

# data[].attributes.body
For [target customer]

Who [statement of the need or opportunity]

The [product name]

Is [a product category]

That [key benefit, compelling reason to buy or use]

Unlike [primary competitive alternative, current system, or current business process],

Our product [statement of primary differentiation and advantages of new product]

for examples read slides 6 and 7
from lecture 4

# data[].attributes.headline
Vision characteristics:           1-Big picture                            2-Abstract                                                            -                                           vision purpose:                                     1-Agreement on what this project is about                        2-Easy communication with stakeholders                        

# data[].attributes.subject
Vision characteristics:           1-Big picture                            2-Abstract                                                            -                                           vision purpose:                                     1-Agreement on what this project is about                        2-Easy communication with stakeholders                        

# data[].attributes.body
The system vision is a joint vision of the system agreed upon by all active stakeholders

# data[].attributes.headline
The value of any marketable feature decreases over time.

# data[].attributes.subject
The value of any marketable feature decreases over time.

# data[].attributes.body
Resources and date are fixed

requirements are estimated

(good)

# data[].attributes.body
A Scrum Master mentors the empowered, self-organizing, and self- accountable teams that are responsible for delivery of successful outcomes at each sprint.

A product owner plays the role of the customer proxy.

A daily stand-up meeting is a primary communication method.

# data[].attributes.body
Work is done in “sprints,” which are time boxed iterations of a fixed 30 days or fewer duration.

Work within a sprint is fixed. Once the scope of a sprint is committed, no additional functionality can be added, except by the development team.

# data[].attributes.headline
Key practices of XP include the following:

# data[].attributes.subject
Key practices of XP include the following:

# data[].attributes.body
1. A team of five to ten programmers work at one location with customer representation onsite.

2. Development occurs in frequent builds or iterations

3. Requirements are specified as user stories

4. Programmers work in pairs, follow strict coding standards, and do their own unit testing. Customers participate in acceptance testing.

5. Requirements, architecture, and design emerge over the course of the project.

# data[].attributes.body
1-  Highest priority is to satisfy the customer through early and continuous delivery of valuable software
2-Welcome changing requirements, even late in development
3- Deliver working software
4- Business people and developers must work together daily throughout the project
5- Build projects around motivated individuals

# data[].attributes.body
1-Dynamic Systems Development Method (DSDM),
2- Feature-Driven Development (FDD),
3- Adaptive Software Development
4- Scrum,
5- Extreme Programming (XP),
6- Open Unified Process (Open UP),
7- Agile RUP,
8- Kanban,
9- Lean,
10- Crystal Methods, etc.

The most widely adopted agile methods are Scrum and XP.

Scrum (with or without combination with XP) is now applied in 74% of agile implementations

# data[].attributes.headline
The iterative process is applied to more quickly discover the “real user requirements” in early iterations, thus substantially reducing the overall risk profile of the project.

# data[].attributes.subject
The iterative process is applied to more quickly discover the “real user requirements” in early iterations, thus substantially reducing the overall risk profile of the project.

# data[].attributes.body
Apply lighter-weight documents and models such as vision documents, use case models, and so on, which are used to initially define what is to be built.

# data[].attributes.body
RUP recognized the necessary overlap of the various activities that occurred during the life cycle phases of inception, elaboration, construction, and transition.

Requirements elaboration and requirements change are considered to be a continuous process that occurs throughout the life cycle.

# data[].attributes.body
No traditional big, upfront design  but  “discovery based” approach

# data[].attributes.body
8
and 10 (the spiral model)
and 11 (RAD model)
and 12(RUP model)

# data[].attributes.headline
“Scope management related to attempting waterfall practices was the single largest contributing factor for failure.”

# data[].attributes.subject
“Scope management related to attempting waterfall practices was the single largest contributing factor for failure.”

# data[].attributes.body
(predictive)

# data[].attributes.headline
This “fixed requirements scope” assumption has indeed been found to be a root cause of project failures.

# data[].attributes.subject
This “fixed requirements scope” assumption has indeed been found to be a root cause of project failures.

# data[].attributes.body
(predictive)

# data[].attributes.body
the requirements are fixed.

the schedule and budget of the project are estimated.

(not good)

# data[].attributes.body
Software development occurred in an orderly series of sequential stages (Progress flows top to bottom, like a waterfall)

Predictive stages
1- Requirement
2- design
3- implementation
4- verification
5- Deployment

# data[].attributes.headline
The problem definition is typically not independent of the solution definition.

# data[].attributes.subject
The problem definition is typically not independent of the solution definition.

# data[].attributes.body
A large proportion of requirements are specified with a (preliminary) solution in mind.

# data[].attributes.headline
Interactions between requirements and design stage possible

# data[].attributes.subject
Interactions between requirements and design stage possible

# data[].attributes.headline
Solution space decreases during the development process.

# data[].attributes.subject
Solution space decreases during the development process.

# data[].attributes.body
for more details see slide 38 from lecture 2

# data[].attributes.body
1-Product requirements
2-Organizational requirements
3-External requirements

# data[].attributes.headline
Constraints may also lead to the change of requirements or the definition of new requirements

# data[].attributes.subject
Constraints may also lead to the change of requirements or the definition of new requirements

# data[].attributes.body
1 the system itself
2-the development process of the system

for more detail read slide 24 from lecture 2

# data[].attributes.body
1-cultural
2-legal constraints (from laws and standards)
3-organizational constraints
4-physical constraints
5-project constraints

# data[].attributes.headline
Quality requirements must have a business case, and are not for the sake of the development team.

# data[].attributes.subject
Quality requirements must have a business case, and are not for the sake of the development team.

# data[].attributes.body
Example: “To improve maintainability, the architecture of the Sales module must be refactored.”

# data[].attributes.body
1- important primarily to users
2-important primarily to developers

examples in the lecture 2  slide 15
very important from 16 to 19

# data[].attributes.body
1. Functional requirements
2. Quality requirements
3. Constraints

# data[].attributes.headline
A user requirement may be expanded into several system requirements.

# data[].attributes.subject
A user requirement may be expanded into several system requirements.

# data[].attributes.body
1- user requirements
2- system requirements

# data[].attributes.headline
Why there are Different levels of requirements?

# data[].attributes.subject
Why there are Different levels of requirements?

# data[].attributes.body
because there are different types of readers.

# data[].attributes.body
A structured document setting out detailed descriptions of the system’s requirements .

# data[].attributes.body
Statements in natural language plus diagrams of the services(requirements) the system

provides and its operational constraints

-Written for customers.

# data[].attributes.headline
*read lecture 2*                                 

# data[].attributes.subject
*read lecture 2*                                 

# data[].attributes.body
7 and 20

# data[].attributes.body
it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization’s needs.

# data[].attributes.headline
RE is always embedded within a specific organizational context(company's products).

# data[].attributes.subject
RE is always embedded within a specific organizational context(company's products).

# data[].attributes.body
requirement engineering should be involved in the whole process with any new products from the organisation.

# data[].attributes.headline
If the requirements defect is not detected until acceptance testing, the effort required can be up to 100 times greater.

# data[].attributes.subject
If the requirements defect is not detected until acceptance testing, the effort required can be up to 100 times greater.

# data[].attributes.headline
If a requirement defect is detected during programming, the cost to fix the defect is approximately 20 times higher than the effort required to detect and fix the defect during requirements engineering.

# data[].attributes.subject
If a requirement defect is detected during programming, the cost to fix the defect is approximately 20 times higher than the effort required to detect and fix the defect during requirements engineering.

# data[].attributes.headline
The cost of removing defects in requirements increases the later the defects are detected during the development process.

# data[].attributes.subject
The cost of removing defects in requirements increases the later the defects are detected during the development process.

# data[].attributes.headline
Nearly 50% of the failures found in program source code can be traced back to requirements defects.

# data[].attributes.subject
Nearly 50% of the failures found in program source code can be traced back to requirements defects.

# data[].attributes.headline
*read lecture 1 *                         

# data[].attributes.subject
*read lecture 1 *                         

# data[].attributes.body
from 12 to 14
and 16
and 18

# data[].attributes.headline
The reason for many of these failures lay in insufficient requirements engineering:

# data[].attributes.subject
The reason for many of these failures lay in insufficient requirements engineering:

# data[].attributes.body
1-Requirements gathering,
2-Requirements documentation, 3-Requirements management.

# data[].attributes.headline
The spectrum(sequent) of failures ranges from failures with minor consequences to failure with disastrous effects(bad effects).

# data[].attributes.subject
The spectrum(sequent) of failures ranges from failures with minor consequences to failure with disastrous effects(bad effects).

# data[].attributes.headline
One of the major causes of both cost and time overruns is

# data[].attributes.subject
One of the major causes of both cost and time overruns is

# data[].attributes.body
restart, Some projects can have several restarts

# data[].attributes.body
1- size
2-conflicting goals
3-large budgets

# data[].attributes.headline
 The faster the projects go into production

# data[].attributes.subject
 The faster the projects go into production

# data[].attributes.body
the quicker the payback starts to accumulate.

# data[].attributes.body
1- Requirement
2- Cost
3- Schedule

# data[].attributes.headline
The larger the project, the less valuable the return rate. In many cases larger projects never return value to an organization. 

# data[].attributes.subject
The larger the project, the less valuable the return rate. In many cases larger projects never return value to an organization. 

# data[].attributes.body
The project get cancelled

# data[].attributes.body
Does not satisfy one or two of the Iron Triangle

# data[].attributes.headline
The Term Requirements .                       

# data[].attributes.subject
The Term Requirements .                       

# data[].attributes.body
(1) Needs and goals of users

(2) Conditions and properties of the system to be developed

(3) A documented requirement is called “Requirements Artefact”
(number 3 means A documented representation of (1) or (2). )

# data[].attributes.body
Satisfied all the Iron Triangle