1. 1 CSSE 490 - Requirements Steve Chenoweth Department of Computer Science & Software Engineering RHIT Session 1 – Wed, June 6, 2007 Above – Sources of requirements in the business I was in – Telecom. From http://www.althosbooks.com/crrfforiptec.html. http://www.althosbooks.com/crrfforiptec.html

2. 2 Today Course syllabus.Course syllabus Introductions & your objectives. Schedule and overview.Schedule Requirements (Req) situations and Req in software. The “Req problem.” Where Req are in the engineering lifecycle. Where the Req people fit on a team. Sample Req documents. Discuss possible projects, first 2 assignments. Discuss grading & assignments in general. Questions?

3. 3 Course syllabus See link to course website syllabus.syllabus Grading & assignments yet to be determined! (Last thing today.)

4. 4 Introductions & your objectives You -- Who / what you do / where / how requirements are involved / what you’d like to see in this course Me -- See website. In general –website –1974 – 2003 I worked on software projects, mostly for NCR and AT&T / Lucent. NCRAT&TLucent –Wrote lots of requirements, including problem statements, use cases, quality attribute specs, & similar modern stuff. –Reviewed requirements & architecture for about 50 telecom projects.

5. 5 Schedule and overview Schedule -- See link to course website schedule. schedule Overview – –Achieve your objectives –Achieve course objectives –Be able to say you can do requirements for an engineering / IT project Questions?

6. 6 Requirements (Req) situations and Req in software The situation questions are: –When do you have to do them? –How well do you have to do them? We’ll talk about software Req for various reasons…

7. 7 Requirements (Req) situations When do you have to do them? –Someone outside makes you (e.g., for govt contracts, FDA, customer contract). –It really enables your development to be done right. Examples of “times” to do requirements: –Starting a new project. –Discovering you didn’t do them! Questions?

8. 8 Requirements (Req) situations How well do you have to do them? At end of “R,” Leffingwell & Widrig give their view about how agile to be. It depends in part on team practices. What are developers expecting to develop from? The common trap is to fall into “incremental artifacts only.” Usually ends up being “not good enough.” In the course, we’ll take a middle ground approach, covering most of the new kinds of artifacts you may need to create. Questions?

9. 9 How well? – What’s “Minimalist”? Let’s try XP (Extreme Programming*), to see what a minimalist Req approach is like. Here’s how requirements feed into the system with XP: –User Stories are done at the beginning for release planning: These are written by the customers as things that the system needs to do for them. They are similar to usage scenarios, except that they are not limited to describing a user interface. They are in the format of about three sentences of text written by the customer in the customers terminology without techno- syntax. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the customer and receive a detailed description of the requirements face to face. –The customer is always available: Because details are left off the user stories the developers will need to talk with customers to get enough detail to complete a programming task. Projects of any significant size will require a full time commitment from the customer. The customer will also be needed to help with functional testing. The test data will need to be created and target results computed or verified. *See for example, http://www.extremeprogramming.org/, which these descriptions are taken from.http://www.extremeprogramming.org/

10. 10 An interesting exercise Here are 4 user stories to feed into development of a new product to be called the Mark IV Coffee Maker* : In this exercise, decide what order should these be done in by the development organization… *Taken from http://www.extremeprogramming.org/example/coffeestories.html.http://www.extremeprogramming.org/example/coffeestories.html 1. Brew some coffee. When the brew button is pressed boil the water until empty. 2. Keep the coffee warm. When the pot has coffee in it turn on the warmer. When the coffeepot is removed turn off the warmer. 3. Indicator light. Turn on this light when coffee is done brewing. Turn off the light when coffeepot is picked up. 4. Interrupt brewing if the coffeepot is removed. Opening the relief valve will stop the water flow. If coffeepot is replaced, continue.

11. 11 Oh, and it should look like this… And run faster than that one… And spill less. Huh? Image from javaqueen.us/coffeemaker.htm.javaqueen.us/coffeemaker.htm

12. 12 How well? – What’s “Maximalist”? Often hundreds of pages of one liners sounding like, “The system shall…” E.g., See for example WIRE C&DH Flight Software Requirements Specification DRAFT.WIRE C&DH Flight Software Requirements Specification DRAFT –041.1.1 The flight software shall receive data in the form of CCSDS packets from the Software Bus, and shall transmit the data over the 1553B bus. –041.1.2 The flight software shall collect data from the 1553B remote terminals and shall transmit the data on the Software Bus in the form of CCSDS packets. –041.1.3 If necessary, the flight software shall use multiple 1553B transactions to collect or transmit a single CCSDS packet. They are organized into well defined sections, often according to “IEEE SRS” guidelines (Std 830-1998 ). *See for example, http://www.extremeprogramming.org/, which these descriptions are taken from.http://www.extremeprogramming.org/

13. 13 Req in software Req in software run the gamut from well- defined to a series of prototypes. Req can be especially hard in software -- –Software can do almost anything? –You never have to build the same thing twice? –It’s invisible (and builds on other things that are invisible)? Questions?

14. 14 The “Req problem” Ch 1 & 2 in R Who’s giving the Req? Customers Product manager Suppliers Req are often a root cause of success & failure (thus your first assignment)first assignment Lots of Req errors – why? Questions?

15. 15 The “Req problem” What are the key Req activities? Elicitation – from whom? Documentation – for whom? Management – watching for what? –(This is most of R) Tracing fwd from Req to development & product (e.g., in creating test cases) Tracing back to Req from development & product errors Questions?

16. 16 Where Req are in the engineering lifecycle Ch 3 in R In software, most people use iterative or spiral prototyping. With Agile processes, writing down a full set of Req before committing to development decisions – not in the play book! Questions?

17. 17 Where the Req people fit on a team Ch 4 in R Junior or senior, vs. regular engineers / developers? How many decisions they make on their own, vs. just recording or translating? What org they are part of? Questions?

18. 18 Sample Req documents See link to course website handouts.handouts Questions?

19. 19 Discuss possible projects, first 2 assignments What projects could you do, eliciting and managing a set of requirements? –Project description due next weekProject description What could you do as a short case history for next week?short case history Questions?

20. 20 Discuss grading & assignments in general The sample syllabus lists the following types of assignments: 40%Project Work (details below) 14%Exam 1 14%Exam 2 ??%Homeworks (unknown, but 2% each) 10%Class Participation (including attendance) ??%Total – We’ll make it add up Want all those? (Time to pick!) Questions?

21. 21 Discuss grading & assignments in general The Project Work suggests this grading: –20% Clients’ Evaluation –10% Peer Evaluations –50% All the Project Artifacts –20% Project Presentations Want all those? (Time to pick!) Questions?