1 csse 490 - requirements steve chenoweth department of computer science & software engineering...

1

CSSE 490 - Requirements

Steve ChenowethDepartment of Computer Science &

Software EngineeringRHIT

Session 1 – Wed, June 6, 2007

Above – Sources of requirements in the business I was in – Telecom. From http://www.althosbooks.com/crrfforiptec.html.

2

Today

• Course syllabus. • Introductions & your objectives.• Schedule and overview.• 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

Course syllabus

• See link to course website syllabus.

• Grading & assignments yet to be determined! (Last thing today.)

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 – – 1974 – 2003 I worked on software projects, mostly for

NCR and AT&T / Lucent.– Wrote lots of requirements, including problem

statements, use cases, quality attribute specs, & similar modern stuff.

– Reviewed requirements & architecture for about 50 telecom projects.

5

Schedule and overview

• Schedule -- See link to course website schedule.

• Overview –– Achieve your objectives– Achieve course objectives– Be able to say you can do requirements for an

engineering / IT project

Questions?

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

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

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

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.

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.

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

Oh, and it should look like this…

• And run faster than that one…

• And spill less.

• Huh?

Image from javaqueen.us/coffeemaker.htm .

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

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

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)• Lots of Req errors – why?

Questions?

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

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

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

Sample Req documents

• See link to course website handouts.

Questions?

19

Discuss possible projects, first 2 assignments

• What projects could you do, eliciting and managing a set of requirements?– Project description due next week

• What could you do as a short case history for next week?

Questions?

20

Discuss grading & assignments in general

• The sample syllabus lists the following types of assignments:40%Project Work (details below)14%Exam 114%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

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?