CS 404 – Software PROJECT MANAGEMENT

1. CS 404 – Software PROJECT MANAGEMENT Requirements

2. Three easy Questions Define Release Criteria Define Product Purpose / Audience Define Features / User Roles

4. Requirements gathering • Waterfall & “agile” processes start by gathering requirements • But where do they come from? • Shadowy organizations often cited as source:"The Business", "Users", "The Customer" • But each often just a single stakeholder's opinions • Seldom solve all problems they meant to solve • Means we cannot stop after first pass! ACTUAL REQUIREMENTS HERE

5. Understanding requirements • Establish goals and objectives early • Document every requirements activity • Be transparent with documentation • Talk to the right stakeholders • Don’t make assumptions • Confirm, Confirm, Confirm • Focus on requirements, not tools • Help the customer prioritize • Remember, you missed something! Of course you know why you’re doing the project… right?

6. Understanding requirements • Establish goals and objectives early • Document every requirements activity • Be transparent with documentation • Talk to the right stakeholders • Don’t make assumptions • Confirm, Confirm, Confirm • Focus on requirements, not tools • Help the customer prioritize • Remember, you missed something! Easy to understand what the user wants while you’re talking to them… Unfortunately, you also need this understanding next week.

7. Understanding requirements • Establish goals and objectives early • Document every requirements activity • Be transparent with documentation • Talk to the right stakeholders • Don’t make assumptions • Confirm, Confirm, Confirm • Focus on requirements, not tools • Help the customer prioritize • Remember, you missed something! If it’s not in the notes, it didn’t happen!

8. Understanding requirements • Establish goals and objectives early • Document every requirements activity • Be transparent with documentation • Talk to the right stakeholders • Don’t make assumptions • Confirm, Confirm, Confirm • Focus on requirements, not tools • Help the customer prioritize • Remember, you missed something! The actual user may not be is almost never the decision maker…

9. Understanding requirements • Establish goals and objectives early • Document every requirements activity • Be transparent with documentation • Talk to the right stakeholders • Don’t make assumptions • Confirm, Confirm, Confirm • Focus on requirements, not tools • Help the customer prioritize • Remember, you missed something! We need a blog. Admin? Archive? RSS? Security?

10. Understanding requirements • Establish goals and objectives early • Document every requirements activity • Be transparent with documentation • Talk to the right stakeholders • Don’t make assumptions • Confirm, Confirm, Confirm • Focus on requirements, not tools • Help the customer prioritize • Remember, you missed something! Radio silence is not confirmation

11. Understanding requirements • Establish goals and objectives early • Document every requirements activity • Be transparent with documentation • Talk to the right stakeholders • Don’t make assumptions • Confirm, Confirm, Confirm • Focus on requirements, not tools • Help the customer prioritize • Remember, you missed something! Your reporting package is not a business requirement

12. Understanding requirements • Establish goals and objectives early • Document every requirements activity • Be transparent with documentation • Talk to the right stakeholders • Don’t make assumptions • Confirm, Confirm, Confirm • Focus on requirements, not tools • Help the customer prioritize • Remember, you missed something! They will want more than you can produce, in less time than you can produce it

13. Understanding requirements • Establish goals and objectives early • Document every requirements activity • Be transparent with documentation • Talk to the right stakeholders • Don’t make assumptions • Confirm, Confirm, Confirm • Focus on requirements, not tools • Help the customer prioritize • Remember, you missed something! Staying flexible is important, but often the deadline is still the deadline

14. When requirements go bad • Too Vague • Too Specific • Poorly Scoped (compounding) • Contradictory • Technically Infeasible • Misaligned to Business Case • Include invalid assumptions

15. Warning signs • Unquantifiable items and terms • Adjectives like fast, secure, responsive, user-friendly • Phrases like multiple languages, importing data, multiple roles • Conjunctions (and, or, but) • Technical specifics (#4454a3, D3.js, PHPMyAdmin) which are used to define how, not what • Disagreement in role and reason ("As a marketing manager, I want SHA256 encrypted passwords") • Use of non-existent or impossibly broad user groups (the system, the business) • References to other requirements

16. Requirements exercise (waterfall) Imagine that you have received the following business requirements for a new web app that allows users to track shipments. What additional information (if any) would you ask for? What other follow up questions might you have? • The system should have three security levels, unauthenticated, normal users, and admins • The system should be easy to use • The system should respond quickly • The system should produce usage reports • The system should support data imported from Excel

17. Requirements exercise (AGILE) • As a Manny’s food service customer, I need to save, copy, print, and email my list so that I can edit it again, check a received shipment against a printed list, and send the list to a restaurant. • As a developer, I want to finalize the database table changes and additions for the release so that we don’t have to make changes to the model later. • As the system, I want to store customer account info and their order lists in the database. • As a customer ordering food, I want to locate previous food order lists so that I can see all the lists that I have.