160 likes | 238 Views
ITEC 370. Lecture 5 Requirements. 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?
E N D
ITEC 370 Lecture 5 Requirements
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?
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
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…
Stakeholders • Different classes of users • Administrator • Manager • Power user • Regular user • Tourist
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…
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
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
Results • After inception you should have • Statement of need and feasibility • Scope of product • List of stakeholders • Requirements • Usage scenarios
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
Elaboration • Initial technical requirements • Database, Not (tables, indexes) • Toolkits, languages • Typically not interesting for the business folks • ONLY attempt after user requirements
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
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
Validation • Ambiguity removed • Inconsistency not present • Omissions not present • End product • Software Requirement Specification (SRS)
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
Review • Process of requirements gathering • Inception • Elaboration • Negotiation • Validation • SRS