1 / 16

Mastering Software Requirements: Types, Stakeholders, and Process

Learn about functional and non-functional requirements, stakeholder classes, inception, elicitation methods, and the importance of validation in software requirement specification. Understand the process of gathering, elaborating, negotiating, and validating requirements to create effective software solutions.

sonya-mullins
Télécharger la présentation

Mastering Software Requirements: Types, Stakeholders, and Process

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. ITEC 370 Lecture 5 Requirements

  2. Review • Requirements • What did you learn? • Why are requirements part of the process? • What is the difference between a functional requirement and a non-functional requirement? • Where are requirements used in the process? • What are some of the different types of requirements?

  3. Objectives • Requirements • Process of gathering them • Mini-presentation of idea on F • 2-3 minutes • Be prepared to give feedback to other teams • Too ambitious, not large enough of the scope

  4. Types Straight from the book • Design requirement • Physical or code wise • Functional requirement • What does it do? • Implementation requirement • Thou shalt use quicksort • Interface requirement • I want it to look like… • Performance requirement • It must perform like… • Physical requirement • I have to lift servers everyday so…

  5. Stakeholders • Different classes of users • Administrator • Manager • Power user • Regular user • Tourist

  6. Inception • Where does the process begin… • RFP, Programming Assignment, Pizza • Who should you talk to? • Determine stakeholders ASAP • What are some of the problems when you talk to…

  7. Elicitation • Easiest way = 5 W’s • Who What When Where Why, and maybe How • List how each stakeholder will be affected by the software • Useful for providing reasons to adopt your solution

  8. Issues • Difficult process • Scope • Understanding • Volatility • How to acquire requirements • Interview (Structured / free-form) • Questionnaire • Look through documentation / manuals • Observation • Don’t be the secretive type, involve your clients

  9. Results • After inception you should have • Statement of need and feasibility • Scope of product • List of stakeholders • Requirements • Usage scenarios

  10. Elaboration • Just gathering requirements isn’t enough • Initial user requirements • Typically aren’t ready to hand to designer • Information needs to be stored so I can get it to fill out a report later • Polish

  11. Elaboration • Initial technical requirements • Database, Not (tables, indexes) • Toolkits, languages • Typically not interesting for the business folks • ONLY attempt after user requirements

  12. Elaboration • Take initial stages and combine to get final functional requirements • Terminology suitable for non-techies and techies • Descriptions for each user requirement • Complete enough so you can form an estimate on how long it will take to build • Developers are feasible it can be built

  13. Negotiation • How much is this going to cost >) • Moscow rule • Must have • Should Have • Could Have • Want but probably won’t have • Methods vary based on lifecycle model

  14. Validation • Ambiguity removed • Inconsistency not present • Omissions not present • End product • Software Requirement Specification (SRS)

  15. SRS • Document, therefore it isn’t fed into a compiler • Structured • Sections, subsections, sub-sub sections, etc… • Numbers are your friend (tie-in) • Concise, Easy to read, black box, plans for the worst, verifiable • Can take up / cost 10-30% of a projects time / budget

  16. Review • Process of requirements gathering • Inception • Elaboration • Negotiation • Validation • SRS

More Related