itec 370
DESCRIPTION
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? - PowerPoint PPT PresentationTRANSCRIPT
ITEC 370
Lecture 5Requirements
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
Stakeholders
• 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
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
Requirements
Elaboration
• Initial technical requirements– Database, Not (tables, indexes)– Toolkits, languages– Typically not interesting for the business
folks– ONLY attempt after user requirements
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
Requirements
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
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