itec 370

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