Prt t qrts - - PowerPoint PPT Presentation

❇❡❣✐♥ Pr♦❥❡❝t ❉❡✈❡❧♦♣♠❡♥t✿ ❘❡q✉✐r❡♠❡♥ts ❛♥❞ ❋❡❛s✐❜✐❧✐t②

❈❙ ✸✼✵ ❙❊ Pr❛❝t✐❝✉♠✱ ❈❡♥❣✐③ ●ü♥❛②

✭❙♦♠❡ s❧✐❞❡s ❝♦✉rt❡s② ♦❢ ❊✉❣❡♥❡ ❆❣✐❝❤t❡✐♥ ❛♥❞ t❤❡ ■♥t❡r♥❡ts✮ ❈❙ ✸✼✵✱ ●ü♥❛② ✭❊♠♦r②✮ ❘❡q✉✐r❡♠❡♥ts ❛♥❞ ❋❡❛s✐❜✐❧✐t② ❙♣r✐♥❣ ✷✵✶✹ ✶ ✴ ✾

❆❣❡♥❞❛

❚♦❞❛②✬s ❡✈❡♥ts✿ ❚❡❛♠ s❡❧❡❝t✐♦♥s ❢♦r ♠❛✐♥ ♣r♦❥❡❝t ❉❡♠♦s ❢♦r ♣r♦❥❡❝t✶❀ ❲❡❜■❞♦❧ ✈♦t✐♥❣ st❛rts ❛❢t❡r ❝❧❛ss ❉✉❡ ❛❢t❡r ❙♣r✐♥❣ ❇r❡❛❦ ✭❚✉❡s❞❛②✱ ✸✴✶✽✮✿ Pr♦❥❡❝t ✐♥t❡r❢❛❝❡ ♠♦❝❦✲✉♣ ❛♥❞ ♦❜❥❡❝t✲❞❛t❛ ♠♦❞❡❧ ❞❡s✐❣♥s ✭s❡❡ ❝❧❛ss ★✽ ♥♦t❡s ❢r♦♠ ✷✴✶✽✮ ❚♦❞❛②✿ ❘❡q✉✐r❡♠❡♥ts ❛♥❞ ❢❡❛s✐❜✐❧✐t② ❢♦r ②♦✉r ♥❡✇ ♣r♦❥❡❝t

❈❙ ✸✼✵✱ ●ü♥❛② ✭❊♠♦r②✮ ❘❡q✉✐r❡♠❡♥ts ❛♥❞ ❋❡❛s✐❜✐❧✐t② ❙♣r✐♥❣ ✷✵✶✹ ✷ ✴ ✾

❆❣❡♥❞❛

❚♦❞❛②✬s ❡✈❡♥ts✿ ❚❡❛♠ s❡❧❡❝t✐♦♥s ❢♦r ♠❛✐♥ ♣r♦❥❡❝t ❉❡♠♦s ❢♦r ♣r♦❥❡❝t✶❀ ❲❡❜■❞♦❧ ✈♦t✐♥❣ st❛rts ❛❢t❡r ❝❧❛ss ❉✉❡ ❛❢t❡r ❙♣r✐♥❣ ❇r❡❛❦ ✭❚✉❡s❞❛②✱ ✸✴✶✽✮✿ Pr♦❥❡❝t ✐♥t❡r❢❛❝❡ ♠♦❝❦✲✉♣ ❛♥❞ ♦❜❥❡❝t✲❞❛t❛ ♠♦❞❡❧ ❞❡s✐❣♥s ✭s❡❡ ❝❧❛ss ★✽ ♥♦t❡s ❢r♦♠ ✷✴✶✽✮ ❚♦❞❛②✿ ❘❡q✉✐r❡♠❡♥ts ❛♥❞ ❢❡❛s✐❜✐❧✐t② ❢♦r ②♦✉r ♥❡✇ ♣r♦❥❡❝t

❈❙ ✸✼✵✱ ●ü♥❛② ✭❊♠♦r②✮ ❘❡q✉✐r❡♠❡♥ts ❛♥❞ ❋❡❛s✐❜✐❧✐t② ❙♣r✐♥❣ ✷✵✶✹ ✷ ✴ ✾

❆❣❡♥❞❛

❚♦❞❛②✬s ❡✈❡♥ts✿ ❚❡❛♠ s❡❧❡❝t✐♦♥s ❢♦r ♠❛✐♥ ♣r♦❥❡❝t ❉❡♠♦s ❢♦r ♣r♦❥❡❝t✶❀ ❲❡❜■❞♦❧ ✈♦t✐♥❣ st❛rts ❛❢t❡r ❝❧❛ss ❉✉❡ ❛❢t❡r ❙♣r✐♥❣ ❇r❡❛❦ ✭❚✉❡s❞❛②✱ ✸✴✶✽✮✿ Pr♦❥❡❝t ✐♥t❡r❢❛❝❡ ♠♦❝❦✲✉♣ ❛♥❞ ♦❜❥❡❝t✲❞❛t❛ ♠♦❞❡❧ ❞❡s✐❣♥s ✭s❡❡ ❝❧❛ss ★✽ ♥♦t❡s ❢r♦♠ ✷✴✶✽✮ ❚♦❞❛②✿ ❘❡q✉✐r❡♠❡♥ts ❛♥❞ ❢❡❛s✐❜✐❧✐t② ❢♦r ②♦✉r ♥❡✇ ♣r♦❥❡❝t

❈❙ ✸✼✵✱ ●ü♥❛② ✭❊♠♦r②✮ ❘❡q✉✐r❡♠❡♥ts ❛♥❞ ❋❡❛s✐❜✐❧✐t② ❙♣r✐♥❣ ✷✵✶✹ ✷ ✴ ✾

❚❡❛♠ ❙❡❧❡❝t✐♦♥s

❙❡❡ P✐❛③③❛ t❤r❡❛❞ ◆❡❡❞ ❛t ❧❡❛st ✸ ✐♥ ❛ t❡❛♠✱ ♠❛① ✺ ❙t❛rt ✇♦r❦✐♥❣ t♦❣❡t❤❡r ✐♠♠❡❞✐❛t❡❧② ❉❡❛❞❧✐♥❡ r✐❣❤t ❛❢t❡r ❙♣r✐♥❣ ❇r❡❛❦ ✭❚✉❡s❞❛②✱ ✸✴✶✽✮ ❲❡ ❛ss✐❣♥ ❡✈❡r②❜♦❞② ♥♦✇ Pr♦❥❡❝t✶ ❞❡♠♦s ✭❲❡❜■❞♦❧✮ ❛r❡ ❛t t❤❡ ❡♥❞ ♦❢ ❝❧❛ss ▲❡t✬s st❛rt ✇✐t❤ ✇❤❛t ②♦✉ ♥❡❡❞ t♦ ❞♦ ✇✐t❤ ②♦✉r ♥❡✇ ♣r♦❥❡❝t✦

❈❙ ✸✼✵✱ ●ü♥❛② ✭❊♠♦r②✮ ❘❡q✉✐r❡♠❡♥ts ❛♥❞ ❋❡❛s✐❜✐❧✐t② ❙♣r✐♥❣ ✷✵✶✹ ✸ ✴ ✾

❚❡❛♠ ❙❡❧❡❝t✐♦♥s

❙❡❡ P✐❛③③❛ t❤r❡❛❞ ◆❡❡❞ ❛t ❧❡❛st ✸ ✐♥ ❛ t❡❛♠✱ ♠❛① ✺ ❙t❛rt ✇♦r❦✐♥❣ t♦❣❡t❤❡r ✐♠♠❡❞✐❛t❡❧② ❉❡❛❞❧✐♥❡ r✐❣❤t ❛❢t❡r ❙♣r✐♥❣ ❇r❡❛❦ ✭❚✉❡s❞❛②✱ ✸✴✶✽✮ ❲❡ ❛ss✐❣♥ ❡✈❡r②❜♦❞② ♥♦✇ Pr♦❥❡❝t✶ ❞❡♠♦s ✭❲❡❜■❞♦❧✮ ❛r❡ ❛t t❤❡ ❡♥❞ ♦❢ ❝❧❛ss ▲❡t✬s st❛rt ✇✐t❤ ✇❤❛t ②♦✉ ♥❡❡❞ t♦ ❞♦ ✇✐t❤ ②♦✉r ♥❡✇ ♣r♦❥❡❝t✦

❈❙ ✸✼✵✱ ●ü♥❛② ✭❊♠♦r②✮ ❘❡q✉✐r❡♠❡♥ts ❛♥❞ ❋❡❛s✐❜✐❧✐t② ❙♣r✐♥❣ ✷✵✶✹ ✸ ✴ ✾

❈♦❧❧❡❝t✐♥❣ ❘❡q✉✐r❡♠❡♥ts

What is a requirement?

 It is about WHAT not HOW  Nothing can be said obvious  Requirements are the descriptions of the services

provided by a system and its operational constraints

 It may range from a high level abstract statement to

a detailed mathematical specification

 It may be as complex as a 500 pages of description  It may serve as the basis for a bid for a contract or

the basis for the contract itself

Why requirements?

 What are the advantages of a complete

set of documented requirements?

 Ensures the user (not the developer) drives

system functionalities

 Helps avoiding confusion and arguments  Helps minimizing the changes

 Changes in requirements are expensive.

Changing the requirements costs:

 3 x as much during the design phase  5-10 x as much during implementation  10-100 x as much after release [Code

Complete, p30]

Why requirements?

 2/3 of finished system errors are

requirements and design errors [RG]

 A careful requirements process doesn’t

mean there will be no changes later

 Average project experiences about 25%

changes in the requirements

 This accounts for 70-80% if the rework of

the project [Code Complete, p40]

 Important to plan for requirements changes

 The case of critical applications

Different levels of abstraction

 User requirements (abstract)

 Usually the first attempt for the description of

the requirements

 Services and constraints of the system  In natural language or diagrams  Readable by everybody  Serve business objectives

 System requirements (NOT abstract)

 Services and constraints of the system in detail  Useful for the design and development  Precise and cover all cases  Structured presentation

Example

 User requirement: As a user who found a new job

announcement, I want to add a new position to the website so s/he can start working on doing the initial research and apply to it

 System requirement: A registered user on the academic

jobs website should be able to add a new position listing with the name of the school and academic unit, date of posting, date of expiry, application deadline, and contact and application details. The interaction fails if: the position is already listed, the application deadline is in the past, position announcement is expired, or the contact information is missing. If fails, point mistakes to user and ask the user to fix and resubmit.

Types of requirements



Functional requirements



Services the system should provide



What the system should do or not in reaction to particular situations



Non-functional requirements



Constraints on the services or functions offered by the system



Examples: Timing constraints (e.g., one semester), constraints on the development process (CASE, language, development method…), standards etc



Domain requirements



From the application domain of the system



May be functional or non-functional



Examples: Medicine, library, physics, chemistry



Note: You can have all of user/system functional/non- functional requirements.

User requirements

 First attempt to describe functional and non-

functional requirements

 Understandable by the user

 Problems:

 Lack of clarity - ambiguous language  Requirements confusion - functional, non-functional

requirements, design information are not distinguished

 Requirements amalgamation – several requirements

are defined as a single one

 Incompleteness – requirements may be missing  Inconsistency – requirements may contradict

themselves

User requirements

 Guideline to minimize the issues:

 Separate requirements – separate the requirements,

separate functional and non-functional requirements, requirements must be clearly identified (e.g. by a number)

 Include a rationale for each requirement – helps clarify

reasoning behind the requirements and may be useful for evaluating potential changes in the requirements

 Invent or use a standard form/template  Distinguish requirements priorities

 Example: MoSCoW (Must, Shall, Could, Want/Will (no TBD))

 Avoid technical jargon  Testable (write test cases)  Deliverables

System requirements

 Elaborate the user requirements to get

a precise, detailed and complete version

• f them

 Used by designers and developers  An important aspect is how to

present/write system requirements

 Natural language is often used!

 The difference between user and

system requirements must not be thought as a detail

System requirements

 Example: If sales for current month are below

target sales, then report is to be printed unless difference between target sales and actual sales is less than half of difference between target sales and actual sales in previous month, or if difference between target sales and actual sales for the current month is less than 5%.

 Problems:

 Difficult to read  Ambiguity: sales and actual sales, 5% of what?  Incomplete: what if sales are above target sales?

Writing system requirements

 Natural language (informal requirements)

 Reviled by academics  But widely practiced: everybody can read them,

finding a better notation is hard

 Structured natural language

 Forms/templates are used to bring some rigor to

natural language presentations

 Graphical notations

 Using boxes, arrows… but they mean different things

to different people

 Formal specification

 Based on logic, state machines…  Hard to understand for many people

An analogy

 Archimedes (ca. 250 bc)

 Any sphere is equal to 4 times the cone which has

its base equal to the greatest circle in the sphere and its height equal to the radius of the sphere.

 Today

 V = 4/3 pi r 3

 How is this bit of history relevant for software

requirements?

 Formal is better only if everybody understands it  It may take a long time to find a good notation  Software requirements is an area of research

Non-functional requirements

 They can be further categorized into:

 Product requirements

 Product behavior  Ex: Timing, performance, memory, reliability,

portability, usability

 Organizational requirements

 Policies and procedures in the customer’s and

developer’s organizations

 Example: Process requirements, implementation

requirements, delivery requirements

 External requirements

 Factors externals to the system and the development

process

 Example: Interoperability, legislation, ethics



Non-functional requirements may be more critical than functional requirements. (The system may be useless…)

Non-functional requirements

Perfor mance requirements Spac e requirements U sa bility requirements E fficiency r equirements Relia bility requirements P

• r

tability requirem ents Inter

• perability

requirements E thical requirements L egislative requirements Implementation requirements Standa rds requirements D elivery requirements Safety requirements Privacy requirements Pr

• duc

t requirements O rga nizational requirements E xternal requirements N

• n-functional

requirements

Non-functional requirements

 It is important to be able to test/verify/check non-

functional requirements

Property Measure Speed Processed transactions/second User/Event response time Screen refresh time Size K Bytes Number of RAM chips Ease of use Training time Number of help frames Reliability Mean time to failure Probability of unavailability Rate of failure occurrence Availability Robustness Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependent statements Number of target systems

Requirement engineering

F easib ility stud y Requirem ents elicitation and analysis R equirem ents specification Requirem ents va lidation F easib ility rep

• rt

System m

• dels

U ser and sy stem req uirem ents Req uirem ents do cu m ent

Feasibility study

 It is done at first to decide whether or not the

project is worthwhile

 Look at different perspectives:



Market analysis, financial, schedule, technical, resource, legal…

 Should make you aware of the risks

Feasibility study

 Doing the study



Consult information sources: managers, software engineers, end users…



Based on information collection (interviews, surveys, questionnaires…)

 Should be short (2-3 weeks)

Feasibility study

 What if the system wasn’t implemented?  What are current process problems?  Do technical resources exist?  What is the risk associated with the

technology?

 Is new technology needed? What skills?  How will the proposed project help?  How does the proposed project contribute to

the overall objectives of the organization?

 Have the benefits identified with the system

being identified clearly?

Feasibility study

 What will be the integration problems?  What facilities must be supported by the

system?

 What is the risk associated with cost

and schedule?

 What are the potential

disadvantages/advantages?

 Are there legal issues?  Are there issues linked with the fact that

this is an offshore project?

 …

❋♦r ②♦✉r ♣r♦❥❡❝t

❆♥② ✈♦❧✉♥t❡❡rs❄ ❘❡q✉✐r❡♠❡♥ts✿ ❢✉♥❝t✐♦♥❛❧✱ ♥♦♥✲❢✉♥❝t✐♦♥❛❧✱ ❞♦♠❛✐♥ ❋❡❛s✐❜✐❧✐t②✿ ✐❞❡❛✱ r✐s❦s✱ ❧❡❣❛❧✱ ♠❡♠❜❡r tr❛✐♥✐♥❣

❋♦r ②♦✉r ♣r♦❥❡❝t

❆♥② ✈♦❧✉♥t❡❡rs❄ ❘❡q✉✐r❡♠❡♥ts✿ ❢✉♥❝t✐♦♥❛❧✱ ♥♦♥✲❢✉♥❝t✐♦♥❛❧✱ ❞♦♠❛✐♥ ❋❡❛s✐❜✐❧✐t②✿ ✐❞❡❛✱ r✐s❦s✱ ❧❡❣❛❧✱ ♠❡♠❜❡r tr❛✐♥✐♥❣

❋♦r ②♦✉r ♣r♦❥❡❝t

❆♥② ✈♦❧✉♥t❡❡rs❄ ❘❡q✉✐r❡♠❡♥ts✿ ❢✉♥❝t✐♦♥❛❧✱ ♥♦♥✲❢✉♥❝t✐♦♥❛❧✱ ❞♦♠❛✐♥ ❋❡❛s✐❜✐❧✐t②✿ ✐❞❡❛✱ r✐s❦s✱ ❧❡❣❛❧✱ ♠❡♠❜❡r tr❛✐♥✐♥❣

User Stories

Templates & Examples

Estimation & Planning

User Stories are the central focus for developers Each User Story should imply an acceptance test Complexity is estimated in Story Points

 Arbitrary measure of relative complexity  We use modified Fibonacci Sequence (0, 1, 2, 3, 5, 8, 13, 21)  Estimates are collaborative to uncover assumptions  Based on Staffing we estimate how many Story Points we can

accomplish in a 2 week Iteration (Velocity)

User Story T emplate

Example from T emplate

Other Example User Stories*

These were excerpted from http://www.westborosystems.com/2010/02/user-story-examples/

Also see http://agile.csc.ncsu.edu/SEMaterials/tutorials/cofgee_maker/ for a great set of examples and tutorials

Key Points

Cards: physical (or virtual) medium where the story is recorded Conversation: Discussion and clarification, modification of the story via communication with the user Confirmation: Tests to verify the user story

I.N.V.E.S.T.

I = independent. Not requiring other features. N = negotiable. Can be excluded, revised, etc. V = valuable. Clearly contributing to product usefulness E = estimable. Reasonable development estimates can be made from the story. S = small. Stories that are too big tend to be vague and to miss the

• ther points, too.

T = testable. Stories need to have a means of verifying functionality.

❙♦ ❤♦✇ t♦ ♠❛✐♥t❛✐♥ ✉s❡r st♦r✐❡s❄

❯s❡ ♦♥❧✐♥❡ t♦♦❧✿ P✐✈♦t❛❧ ❚r❛❝❦❡r

◮ ❚♦ ❝r❡❛t❡✱ ❛ss✐❣♥✱ ❛♥❞ ♠❛✐♥t❛✐♥ ✉s❡r st♦r✐❡s ❢♦r ②♦✉r ♣r♦❥❡❝t

▼❛♥❞❛t♦r②✿ ■ ✇✐❧❧ tr❛❝❦ ②♦✉r ♣r♦❣r❡ss t❤r♦✉❣❤ ✐t✳ ❲❡ ❤❛✈❡ ❛♥ ❛❝❛❞❡♠✐❝ ❛❝❝♦✉♥t✱ ■ ✇✐❧❧ s❡♥❞ ✐♥✈✐t❡s t♦ t❡❛♠s✳

❈❙ ✸✼✵✱ ●ü♥❛② ✭❊♠♦r②✮ ❘❡q✉✐r❡♠❡♥ts ❛♥❞ ❋❡❛s✐❜✐❧✐t② ❙♣r✐♥❣ ✷✵✶✹ ✻ ✴ ✾

❙♦ ❤♦✇ t♦ ♠❛✐♥t❛✐♥ ✉s❡r st♦r✐❡s❄

❯s❡ ♦♥❧✐♥❡ t♦♦❧✿ P✐✈♦t❛❧ ❚r❛❝❦❡r

◮ ❚♦ ❝r❡❛t❡✱ ❛ss✐❣♥✱ ❛♥❞ ♠❛✐♥t❛✐♥ ✉s❡r st♦r✐❡s ❢♦r ②♦✉r ♣r♦❥❡❝t

▼❛♥❞❛t♦r②✿ ■ ✇✐❧❧ tr❛❝❦ ②♦✉r ♣r♦❣r❡ss t❤r♦✉❣❤ ✐t✳ ❲❡ ❤❛✈❡ ❛♥ ❛❝❛❞❡♠✐❝ ❛❝❝♦✉♥t✱ ■ ✇✐❧❧ s❡♥❞ ✐♥✈✐t❡s t♦ t❡❛♠s✳

❈❙ ✸✼✵✱ ●ü♥❛② ✭❊♠♦r②✮ ❘❡q✉✐r❡♠❡♥ts ❛♥❞ ❋❡❛s✐❜✐❧✐t② ❙♣r✐♥❣ ✷✵✶✹ ✻ ✴ ✾

❉✐♠ t❤❡ ❧✐❣❤ts✱ ❤❡r❡ ✇❡ ❣♦✦

❉❡♠♦s✱ ❍♦♥♦r❛❜❧❡ ✭❛♥❞ ❍♦rr✐❜❧❡✮ ▼❡♥t✐♦♥s

■♥✈✐t❡❞ ❞❡♠♦s✿ ❍②♦ ❇②✉♥ ✕ ❚✐♠❡❚r❛❝❦ ▼❛❞❞✐❡ ❲❡♥ ✫ P❛tr✐❝❦ ❖✬▲❡❛r② ✕ ❋♦r✉♠ ❙❤✐②✐ ✏❚♦♥②✑ ❨✐♥❣ ✕ ❉♦♦❧❡② ✇❛♥ts t♦ ❦♥♦✇ ❊t❤❛♥ ❈♦❤❡♥ ✫ P❛✉❧ ❑✐t❝❤❡❧❧ ✕ P❡t✐t✐♦♥ ❈r❡❛t♦r ❲❡s P❛✐♥t❡r ✕ P❤♦t♦s❤♦♣♣❡❞❄ ❍♦♥♦r❛❜❧❡ ♠❡♥t✐♦♥s✿ ❍✉✐❧✐ ❈❤❡♥ ✕ ◆♦❈♦♥t❡①t ❏❡♥♥✐❢❡r ❆s❤✐r✉ ✫ ❙✉s❤✐ ❘✳ ✕ ❍❛✉♥t❡❞ ❍♦✉s❡ ▼✐❧❛♣ ◆❛✐❦ ✫ ❉❛✈❡ ❙t❡ss ✕ ❉♦❣❡❋♦rt✉♥❡ ❆✉st✐♥ ❉♦♥❣ ✫ ❩❡②✉ ❩❤❛♥❣ ✕ ❈❛❧❝✉❧❛t♦r ❍♦rr✐❜❧❡ ♠❡♥t✐♦♥s✿ ❏❛♠❡s ❉✐♥❣ ✕ ❈❡♥❣✐③ ✈s✳ ❉❥❛♥❣♦ ▼❡❤✿ ❙✉❜♠✐tt❡❞ t❤❡ t✉t♦r✐❛❧✦✦✦

❈❙ ✸✼✵✱ ●ü♥❛② ✭❊♠♦r②✮ ❘❡q✉✐r❡♠❡♥ts ❛♥❞ ❋❡❛s✐❜✐❧✐t② ❙♣r✐♥❣ ✷✵✶✹ ✽ ✴ ✾

❉❡♠♦s✱ ❍♦♥♦r❛❜❧❡ ✭❛♥❞ ❍♦rr✐❜❧❡✮ ▼❡♥t✐♦♥s

■♥✈✐t❡❞ ❞❡♠♦s✿ ❍②♦ ❇②✉♥ ✕ ❚✐♠❡❚r❛❝❦ ▼❛❞❞✐❡ ❲❡♥ ✫ P❛tr✐❝❦ ❖✬▲❡❛r② ✕ ❋♦r✉♠ ❙❤✐②✐ ✏❚♦♥②✑ ❨✐♥❣ ✕ ❉♦♦❧❡② ✇❛♥ts t♦ ❦♥♦✇ ❊t❤❛♥ ❈♦❤❡♥ ✫ P❛✉❧ ❑✐t❝❤❡❧❧ ✕ P❡t✐t✐♦♥ ❈r❡❛t♦r ❲❡s P❛✐♥t❡r ✕ P❤♦t♦s❤♦♣♣❡❞❄ ❍♦♥♦r❛❜❧❡ ♠❡♥t✐♦♥s✿ ❍✉✐❧✐ ❈❤❡♥ ✕ ◆♦❈♦♥t❡①t ❏❡♥♥✐❢❡r ❆s❤✐r✉ ✫ ❙✉s❤✐ ❘✳ ✕ ❍❛✉♥t❡❞ ❍♦✉s❡ ▼✐❧❛♣ ◆❛✐❦ ✫ ❉❛✈❡ ❙t❡ss ✕ ❉♦❣❡❋♦rt✉♥❡ ❆✉st✐♥ ❉♦♥❣ ✫ ❩❡②✉ ❩❤❛♥❣ ✕ ❈❛❧❝✉❧❛t♦r ❍♦rr✐❜❧❡ ♠❡♥t✐♦♥s✿ ❏❛♠❡s ❉✐♥❣ ✕ ❈❡♥❣✐③ ✈s✳ ❉❥❛♥❣♦ ▼❡❤✿ ❙✉❜♠✐tt❡❞ t❤❡ t✉t♦r✐❛❧✦✦✦

❈❙ ✸✼✵✱ ●ü♥❛② ✭❊♠♦r②✮ ❘❡q✉✐r❡♠❡♥ts ❛♥❞ ❋❡❛s✐❜✐❧✐t② ❙♣r✐♥❣ ✷✵✶✹ ✽ ✴ ✾

❉❡♠♦s✱ ❍♦♥♦r❛❜❧❡ ✭❛♥❞ ❍♦rr✐❜❧❡✮ ▼❡♥t✐♦♥s

■♥✈✐t❡❞ ❞❡♠♦s✿ ❍②♦ ❇②✉♥ ✕ ❚✐♠❡❚r❛❝❦ ▼❛❞❞✐❡ ❲❡♥ ✫ P❛tr✐❝❦ ❖✬▲❡❛r② ✕ ❋♦r✉♠ ❙❤✐②✐ ✏❚♦♥②✑ ❨✐♥❣ ✕ ❉♦♦❧❡② ✇❛♥ts t♦ ❦♥♦✇ ❊t❤❛♥ ❈♦❤❡♥ ✫ P❛✉❧ ❑✐t❝❤❡❧❧ ✕ P❡t✐t✐♦♥ ❈r❡❛t♦r ❲❡s P❛✐♥t❡r ✕ P❤♦t♦s❤♦♣♣❡❞❄ ❍♦♥♦r❛❜❧❡ ♠❡♥t✐♦♥s✿ ❍✉✐❧✐ ❈❤❡♥ ✕ ◆♦❈♦♥t❡①t ❏❡♥♥✐❢❡r ❆s❤✐r✉ ✫ ❙✉s❤✐ ❘✳ ✕ ❍❛✉♥t❡❞ ❍♦✉s❡ ▼✐❧❛♣ ◆❛✐❦ ✫ ❉❛✈❡ ❙t❡ss ✕ ❉♦❣❡❋♦rt✉♥❡ ❆✉st✐♥ ❉♦♥❣ ✫ ❩❡②✉ ❩❤❛♥❣ ✕ ❈❛❧❝✉❧❛t♦r ❍♦rr✐❜❧❡ ♠❡♥t✐♦♥s✿ ❏❛♠❡s ❉✐♥❣ ✕ ❈❡♥❣✐③ ✈s✳ ❉❥❛♥❣♦ ▼❡❤✿ ❙✉❜♠✐tt❡❞ t❤❡ t✉t♦r✐❛❧✦✦✦

❈❙ ✸✼✵✱ ●ü♥❛② ✭❊♠♦r②✮ ❘❡q✉✐r❡♠❡♥ts ❛♥❞ ❋❡❛s✐❜✐❧✐t② ❙♣r✐♥❣ ✷✵✶✹ ✽ ✴ ✾

❉❡♠♦s✱ ❍♦♥♦r❛❜❧❡ ✭❛♥❞ ❍♦rr✐❜❧❡✮ ▼❡♥t✐♦♥s

■♥✈✐t❡❞ ❞❡♠♦s✿ ❍②♦ ❇②✉♥ ✕ ❚✐♠❡❚r❛❝❦ ▼❛❞❞✐❡ ❲❡♥ ✫ P❛tr✐❝❦ ❖✬▲❡❛r② ✕ ❋♦r✉♠ ❙❤✐②✐ ✏❚♦♥②✑ ❨✐♥❣ ✕ ❉♦♦❧❡② ✇❛♥ts t♦ ❦♥♦✇ ❊t❤❛♥ ❈♦❤❡♥ ✫ P❛✉❧ ❑✐t❝❤❡❧❧ ✕ P❡t✐t✐♦♥ ❈r❡❛t♦r ❲❡s P❛✐♥t❡r ✕ P❤♦t♦s❤♦♣♣❡❞❄ ❍♦♥♦r❛❜❧❡ ♠❡♥t✐♦♥s✿ ❍✉✐❧✐ ❈❤❡♥ ✕ ◆♦❈♦♥t❡①t ❏❡♥♥✐❢❡r ❆s❤✐r✉ ✫ ❙✉s❤✐ ❘✳ ✕ ❍❛✉♥t❡❞ ❍♦✉s❡ ▼✐❧❛♣ ◆❛✐❦ ✫ ❉❛✈❡ ❙t❡ss ✕ ❉♦❣❡❋♦rt✉♥❡ ❆✉st✐♥ ❉♦♥❣ ✫ ❩❡②✉ ❩❤❛♥❣ ✕ ❈❛❧❝✉❧❛t♦r ❍♦rr✐❜❧❡ ♠❡♥t✐♦♥s✿ ❏❛♠❡s ❉✐♥❣ ✕ ❈❡♥❣✐③ ✈s✳ ❉❥❛♥❣♦ ▼❡❤✿ ❙✉❜♠✐tt❡❞ t❤❡ t✉t♦r✐❛❧✦✦✦

❈❙ ✸✼✵✱ ●ü♥❛② ✭❊♠♦r②✮ ❘❡q✉✐r❡♠❡♥ts ❛♥❞ ❋❡❛s✐❜✐❧✐t② ❙♣r✐♥❣ ✷✵✶✹ ✽ ✴ ✾

❱♦t✐♥❣ ❢♦r ❲❡❜■❞♦❧

❉♦ ♥♦t ❞✐❛❧ ✽✵✵ ♥✉♠❜❡rs✦ ■ ✇✐❧❧ ♣♦st ❛ ♣♦❧❧ ♦♥ P✐❛③③❛ ♥♦✇ ❱♦t✐♥❣ ✉♥t✐❧ ❝❧❛ss ♦♥ ❚❤✉rs❞❛②

❈❙ ✸✼✵✱ ●ü♥❛② ✭❊♠♦r②✮ ❘❡q✉✐r❡♠❡♥ts ❛♥❞ ❋❡❛s✐❜✐❧✐t② ❙♣r✐♥❣ ✷✵✶✹ ✾ ✴ ✾