1 / 5

Unveiling Software Requirements: Sources & Reflections

Explore the origins of requirements in software engineering, learning to gather them effectively from various sources and people. Understand how requirements reflect their sources and ways to manage them to prevent "requirements creep." Delve into additional resources on requirement gathering processes. Discover the IEEE spec format, Creative Problem Solving model, and competitive insights. Take the next step in your project by identifying necessary tasks and engaging the right individuals.

jerold
Télécharger la présentation

Unveiling Software Requirements: Sources & Reflections

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. Left – People use these throughout engineering. This one’s rom the requirements document at archives.elevated.org/ project/resources.shtm. Requirements Documents “Some are more precise than others…” CSSE 371, Software Requirements and Specification Steve Chenoweth, Rose-Hulman Institute October 18, 2004 In the book – This is Ch 20

  2. Let’s start with “Where do requirements come from?” • Do it first, • Then the “lessons” might sound familiar… • Get with your project team. • One person take notes. • In 1 minute, write down the list of all the “sources” of your requirements. Where have they come from? • We’ll hear a few examples. • In 2 more minutes, write down a list of all the additional people who might know additional requirements (or could have good ideas about what should be in the system). • We’ll hear a few examples. • Keep these lists! • (See p. 5 ) “This project would enable a user to share the real-time contents and actions of their computer screen with any remote user or group of users… ” …From your project description.

  3. Do the requirements depend on who you heard them from? • Well, yeah…? And in varying amounts, depending… • How would you make your requirements reflect that? Right – The Codex Alexandrinus version of St Luke xii. 54 - xiii 5, which is at the British Museum. From www.mun.ca/rels/restmov/ texts/dasc/HWGI04.HTM. Above – Kids brainstorming ideas at a Young Authors’ Conference. From www.halcyon.com/ arborhts/ya.html.

  4. Ok, what else can get you? • “When they say it!” • I thought I told you that… • Requirements “creep” • What does this imply about how requirements should be done? “Didn’t I tell you so when we started?” cried Sherlock Holmes with a laugh. From www.bakerstreet221b.de/ canon/stud-207.htm.

  5. Let’s look at some additional resources • What’s in Ch 20 about all this – From Bill Opdyke , North Central College. (See http://www.noctrl.edu/academics/departments/computer_science/department_site/faculty.htm. • How the “Creative Problem Solving” process model sorts out “How’s and What’s” – This is out on Angel, under Handouts.  Google for “CPS Model” and you’ll get lots on this. At http://members.optusnet.com.au/~charles57/Creative/Brain/cps.htm, for example. • The IEEE spec format, in case you run into it. You can find it on the web (e.g., at IEEE Spec at www.dcc.ufmg.br/~rodolfo/es-1-03/IEEE-Std-830-1998.pdf, but we are supposed to pay IEEE for it. • For “What does our competition learn on this subject?” see for example http://www.ncst.ernet.in/education/. •  Your devious next step in your project – You just did a list of what else you need to do. How would you contact the right people to get all those things?

More Related