1. Software Waterfall Life Cycle Requirements Construction Design Testing Delivery and Installation Operations and Maintenance Concept Exploration Prototype

2. V-Model

3. Spiral Model

4. Agile Methods

5. Life Cycle Heuristics If the requirements are well-defined – use the waterfall model (with prototyping) If the requirements are very complex and tightly coupled – use a spiral model If the requirements are uncertain and the project is not large – use an agile method, gathering and implementing requirements in increments

6. Prioritization of Requirements Essential – Must be satisfied in next release Desirable – need to be prioritized in light of time Optional – Can be set aside unless you finish early In CS 480-481 projects, propose three systems – Minimally acceptable by the faculty adviser – Expected by the team, faculty adviser, and client – Desirable by the client (doable if everything falls into place)

7. From SWEBOK 2004

8. Requirements Elicitation Requirement Sources – High level goals or vision of the software – Domain knowledge – Stakeholders – Operational requirements – Organizational environment Elicitation Techniques – Interviews, Scenarios (Use Cases), Prototypes, Facilitated Meetings, Observation

9. Managing Changes in Requirements Change control process (QA) Traceability – How does one change affect others? Version control – How are changes communicated to the team? – How are changes documented? Status tracking – Pending, approved, rejected, deferred, completed, cancelled

10. Use Cases Used to capture functional requirements and describe the interactions between various actors and the system Actors are roles (not individuals) that have a goal for using the system – Actors can be other systems or organizations Use Cases focus on achieving a user goal – Use cases may have relationships (associations) with each other

11. Use Case Scenarios Not UML, no standard format A written description of the steps involved in an interaction between an actor and the system, always beginning with the primary actor

12. Written Use Case Scenarios Use Case Name (use verb-noun) Participating Actors Normal Flow of Events (happy path) – Exceptions (error conditions) – Extensions (optional goals) Entry (pre) Conditions Exit (post) Conditions Quality Requirements

13. Use Case NameWithdraw Money Participating ActorsInitiated by Customer Communicates with Bank Accounting System Flow of Events1.Customer inserts ATM card 2.ATM reads and validates the bank ID and account number with Bank Accounting System 3.Customer enters PIN number 4.ATM validates PIN with Bank Accounting System 5.Customer selects account 6.Customer enters amount to withdraw 7.ATM validates amount with Bank Accounting System 8.ATM dispenses cash and receipt 9.ATM logs transaction 10.Customer takes card, cash, and receipt Entry-Conditions ATM has money and supplies Bank Accounting System (and network) is working Exit-Conditions Customer‘s account balance is adjusted ATM’s money inventory is adjusted ATM’s supply inventory is adjusted Quality Requirements The Customer wait time is less than 3 seconds between steps