pr t t q r ts
play

Prt t qrts - PowerPoint PPT Presentation

Prt t qrts st Prt


  1. ❇❡❣✐♥ 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✐♥❣ ✷✵✶✹ ✶ ✴ ✾

  2. ❉✉❡ ❛❢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 ❆❣❡♥❞❛ ❚♦❞❛②✬s ❡✈❡♥ts✿ ❚❡❛♠ s❡❧❡❝t✐♦♥s ❢♦r ♠❛✐♥ ♣r♦❥❡❝t ❉❡♠♦s ❢♦r ♣r♦❥❡❝t✶❀ ❲❡❜■❞♦❧ ✈♦t✐♥❣ st❛rts ❛❢t❡r ❝❧❛ss ❈❙ ✸✼✵✱ ●ü♥❛② ✭❊♠♦r②✮ ❘❡q✉✐r❡♠❡♥ts ❛♥❞ ❋❡❛s✐❜✐❧✐t② ❙♣r✐♥❣ ✷✵✶✹ ✷ ✴ ✾

  3. ❚♦❞❛②✿ ❘❡q✉✐r❡♠❡♥ts ❛♥❞ ❢❡❛s✐❜✐❧✐t② ❢♦r ②♦✉r ♥❡✇ ♣r♦❥❡❝t ❆❣❡♥❞❛ ❚♦❞❛②✬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♦♠ ✷✴✶✽✮ ❈❙ ✸✼✵✱ ●ü♥❛② ✭❊♠♦r②✮ ❘❡q✉✐r❡♠❡♥ts ❛♥❞ ❋❡❛s✐❜✐❧✐t② ❙♣r✐♥❣ ✷✵✶✹ ✷ ✴ ✾

  4. ❆❣❡♥❞❛ ❚♦❞❛②✬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✐♥❣ ✷✵✶✹ ✷ ✴ ✾

  5. Pr♦❥❡❝t✶ ❞❡♠♦s ✭❲❡❜■❞♦❧✮ ❛r❡ ❛t t❤❡ ❡♥❞ ♦❢ ❝❧❛ss ▲❡t✬s st❛rt ✇✐t❤ ✇❤❛t ②♦✉ ♥❡❡❞ t♦ ❞♦ ✇✐t❤ ②♦✉r ♥❡✇ ♣r♦❥❡❝t ✦ ❚❡❛♠ ❙❡❧❡❝t✐♦♥s ❙❡❡ P✐❛③③❛ t❤r❡❛❞ ◆❡❡❞ ❛t ❧❡❛st ✸ ✐♥ ❛ t❡❛♠✱ ♠❛① ✺ ❙t❛rt ✇♦r❦✐♥❣ t♦❣❡t❤❡r ✐♠♠❡❞✐❛t❡❧② ❉❡❛❞❧✐♥❡ r✐❣❤t ❛❢t❡r ❙♣r✐♥❣ ❇r❡❛❦ ✭❚✉❡s❞❛②✱ ✸✴✶✽✮ ❲❡ ❛ss✐❣♥ ❡✈❡r②❜♦❞② ♥♦✇ ❈❙ ✸✼✵✱ ●ü♥❛② ✭❊♠♦r②✮ ❘❡q✉✐r❡♠❡♥ts ❛♥❞ ❋❡❛s✐❜✐❧✐t② ❙♣r✐♥❣ ✷✵✶✹ ✸ ✴ ✾

  6. ❚❡❛♠ ❙❡❧❡❝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✐♥❣ ✷✵✶✹ ✸ ✴ ✾

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

  8. 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

  9. 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]

  10. 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

  11. 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

  12. 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.

  13. 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.

  14. 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

  15. 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

  16. System requirements  Elaborate the user requirements to get a precise, detailed and complete version of 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

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend