1 / 17

Essential Questions in Software Project Management for Effective Requirements Gathering

Navigating software project management requires clarity in defining release criteria, understanding product purpose and audience, and identifying essential features. This guide emphasizes the importance of early goal establishment, transparent documentation, and engaging the right stakeholders. It cautions against assumptions in requirements gathering, highlights the necessity of confirmation, and guides prioritization efforts. By addressing potential pitfalls and emphasizing clear communication, this resource aims to enhance project outcomes and meet user needs effectively.

kesler
Télécharger la présentation

Essential Questions in Software Project Management for Effective Requirements Gathering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS 404 – Software PROJECT MANAGEMENT Requirements

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

  3. 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

  4. 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?

  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! Easy to understand what the user wants while you’re talking to them… Unfortunately, you also need this understanding next week.

  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! If it’s not in the notes, it didn’t happen!

  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! The actual user may not be is almost never the decision maker…

  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! We need a blog. Admin? Archive? RSS? Security?

  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! Radio silence is not confirmation

  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! Your reporting package is not a business requirement

  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! They will want more than you can produce, in less time than you can produce it

  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! Staying flexible is important, but often the deadline is still the deadline

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

  14. 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

  15. 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

  16. 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.

More Related