Introduction to Software Requirements

 It depends who you ask…  Requirements try to describe the whole system you are creating.  You need to decide on a definition with all project stakeholders…your requirements document will be based on that definition.

 Intersection of interests of stakeholders:  Customers (acquire the software)  Users  Analysts, developers, testers  Legal staff  And so on…

 Foundation for the software system  Define them well  terrific product, happy customers/stakeholders  Define them poorly  disaster

 Business Organization  vision/scope  User  use cases  Functional  software specs

 Nonfunctional  Business rules  Quality attributes  External interfaces  Constraints  And so on…

 Foundation for the software system  Define them well  terrific product, happy customers/stakeholders  Define them poorly  disaster

 Business Organization  vision/scope  User  use cases  Functional  software specs

 We will produce a Requirements Document as per a given template (posted to the bts330 site)

 Develop Requirements  Elicitation  Analysis  Specification  Validation

 Manage Requirements  Define baseline—SCOPE  Manage changes (**NOT EASY)  Manage project activity  Manage project plan

 Detailed requirements are difficult!!!  “…no other part of the work so cripples the resulting system if they’re wrong. No other part is more difficult to rectify later.”  (text, p. 15)

RequirementsDesignCodeTestOperation Relative Cost Source: Text, p. 17

 Insufficient user involvement  Scope creep  Ambiguous requirements  Gold plating  “Paper Napkin” syndrome  Overlooked users  Inaccurate planning (bad promises)

Pain Time Good Requirements Poor Requirements

 Take responsibility for ensuring understanding  Be respectful  Give honest/correct information ▪ See text pg 32, “bill of rights”

 Signing off requirements  is NOT a weapon but a milestone  establishes a baseline  provides the basis for change management