Download
itec 370 n.
Skip this Video
Loading SlideShow in 5 Seconds..
ITEC 370 PowerPoint Presentation

ITEC 370

67 Vues Download Presentation
Télécharger la présentation

ITEC 370

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. ITEC 370 Lecture 5 Requirements

  2. Review • Requirements • What did you learn? • Why are requirements part of the process? • What is the difference between a functional requirement and a non-functional requirement? • Where are requirements used in the process? • What are some of the different types of requirements?

  3. Objectives • Requirements • Process of gathering them • Mini-presentation of idea on F • 2-3 minutes • Be prepared to give feedback to other teams • Too ambitious, not large enough of the scope

  4. Types Straight from the book • Design requirement • Physical or code wise • Functional requirement • What does it do? • Implementation requirement • Thou shalt use quicksort • Interface requirement • I want it to look like… • Performance requirement • It must perform like… • Physical requirement • I have to lift servers everyday so…

  5. Stakeholders • Different classes of users • Administrator • Manager • Power user • Regular user • Tourist

  6. Inception • Where does the process begin… • RFP, Programming Assignment, Pizza • Who should you talk to? • Determine stakeholders ASAP • What are some of the problems when you talk to…

  7. Elicitation • Easiest way = 5 W’s • Who What When Where Why, and maybe How • List how each stakeholder will be affected by the software • Useful for providing reasons to adopt your solution

  8. Issues • Difficult process • Scope • Understanding • Volatility • How to acquire requirements • Interview (Structured / free-form) • Questionnaire • Look through documentation / manuals • Observation • Don’t be the secretive type, involve your clients

  9. Results • After inception you should have • Statement of need and feasibility • Scope of product • List of stakeholders • Requirements • Usage scenarios

  10. Elaboration • Just gathering requirements isn’t enough • Initial user requirements • Typically aren’t ready to hand to designer • Information needs to be stored so I can get it to fill out a report later • Polish

  11. Elaboration • Initial technical requirements • Database, Not (tables, indexes) • Toolkits, languages • Typically not interesting for the business folks • ONLY attempt after user requirements

  12. Elaboration • Take initial stages and combine to get final functional requirements • Terminology suitable for non-techies and techies • Descriptions for each user requirement • Complete enough so you can form an estimate on how long it will take to build • Developers are feasible it can be built

  13. Negotiation • How much is this going to cost >) • Moscow rule • Must have • Should Have • Could Have • Want but probably won’t have • Methods vary based on lifecycle model

  14. Validation • Ambiguity removed • Inconsistency not present • Omissions not present • End product • Software Requirement Specification (SRS)

  15. SRS • Document, therefore it isn’t fed into a compiler • Structured • Sections, subsections, sub-sub sections, etc… • Numbers are your friend (tie-in) • Concise, Easy to read, black box, plans for the worst, verifiable • Can take up / cost 10-30% of a projects time / budget

  16. Review • Process of requirements gathering • Inception • Elaboration • Negotiation • Validation • SRS