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?

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

Requirements Types 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… Straight from the book

Requirements Stakeholder s Different classes of users –Administrator –Manager –Power user –Regular user –Tourist

Requirements 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…

Requirements 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

Requirements 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

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

Requirements Elaboratio n 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

Requirements Elaboratio n Initial technical requirements –Database, Not (tables, indexes) –Toolkits, languages –Typically not interesting for the business folks –ONLY attempt after user requirements

Requirements Elaboratio n 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

Requirements Negotiatio n 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

Requirements Validation Ambiguity removed Inconsistency not present Omissions not present End product –Software Requirement Specification (SRS)

Requirements 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

Requirements Review Process of requirements gathering –Inception –Elaboration –Negotiation –Validation –SRS