1. 3 September 2014

3. Sources of requirements  People Stakeholders ○ Who are the stakeholders? Issues: ○ Conflicting requirements ○ Wants vs. needs Helping the customer articulate the requirements ○ Use cases  Hardware constraints Laws of physics and nature  Social responsibility

4. Social responsibility  Privacy  Security  How it will (can) be used Does it have the potential for misuse? Can it be used to harm people?

5. Sources of Requirements: People vs. Other (Brackett, CMU) % of requirements gathered from people Type of application highly constrained unconstrained missile guidance system flight control system for airliner enhancement to corporate accounting system manufacturing control system corporate accounting system video game decision support system for military tactics relatively lowrelatively high

6. Types of Requirements  Functional : services needed  Usability : how easy it is to do it  Performance: speed, capacity, memory  Reliability and availability: failure rates  Error handling: how to handle  Interface: user and program  Constraints: systems and tolerances  (Inverse: what it won’t do)

7. A requirement must be …  Documented  Expressed precisely  Expressed as what, not how  Prioritized essential, desirable, optional primary, secondary, tertiary  Testable

8. The set of requirements must be…  Consistent Three requirements: ○ Only basic food staples will be carried ○ Everyone will carry water ○ Basic food staples are flour, butter, salt, and milk  Complete The function tells whether 3 numbers produce an equilateral, isosceles, or scalene triangle.

9. Requirement Level  Two phases Requirements written at customer level Developer will convert in order to do design  Once agreement exists with customer, developer “translates” them into his language  Example Customer: User must never lose more than 10 minutes of work Developer: Autosaving is required

11. What is a Functional Spec?  Defines what the functionality will be NOT how it will be implemented  Describes features of the software product product's behavior as seen by external observer  Contains technical info and data needed for design  What a contractor bids on

12. Why a Spec?  Allows you to communicate with your client and users  Easier to change than code  Basis for schedule  Record of design decisions

13. What’s in a Functional Spec?  Overview: project description  Use cases and (optionally) personas  Interfaces: anything the USER sees or uses  Requirements  …as much as you know  Note: your functional spec will go through multiple iterations

14. Expectations of Software Engineering 1. Predetermine quantitative quality goals 2. Accumulate data for use in later projects 3. Keep all work visible 4. Design, program and test only against requirements 5. Measure and achieve quality goals Watts Humphrey