CSSE 571Fall, 2014Notes for class 9Thursday, Nov 13

I. Let's talk about your HW and projects and exam 2 --a. Paper / project - final improvement ideas (due yesterday)

i. How did your ideas change over the past few weeks?ii. Did you start to try any of these out, to see if they work?

iii. How did you do on the goal to have a big list of "possible improvements"?iv. Ready for the presentation on Thursday?v. Ready to turn in the final, knitted-together version then, too?

b. HW 4 - also due yesterdayi. Have value beyond the project work you're doing?

c. Exam 2 - Out there since Sun, Nov 9.i. Due Mon, Nov 17.

ii. Question?

II. Tonight - one topica. Rapid development

i. Ch 9 in Berenbachii. Also ref - Leffingwell, Ch 30 (Agile requirements methods)

iii. And, pretty much all of Rogers assumes use of prototyping methods!1. What kinds do they stress, of the types Berenbach covers?

III. Rapid development - Introa. Everyone wants "rapid development"!

i. Time to develop may be a more important variable than cost1. It is the time-to-market2. Tends to relate strongly to market share

ii. But it's hard to change, because --1. Development orgs get stuck in processes that take a fixed amount of

time to do (e.g., testing)2. Management can't just argue developers into working faster

a. They do tend to believe that esprit de corps is beneficialb. Or, setting expectations, like long hours?c. What's wrong with the picture, below, of the new Facebook HQ

in CA (formerly Sun's HQ)?

And, in front of this place, a famous sign where visitors stop for a "selfie":1

3. So, you look instead at changing development processesa. Automation, like Berenbach's tools for modelingb. Agile and "rapid" development processes

i. Often, a key of "doing less" ii. Eliminate processes that aren't adding value

iii. Especially less paperwork1. Including requirements?2. Sometimes you need precise specs.

1 From http://usatoday30.usatoday.com/tech/news/story/2012-02-03/facebook-pew-research/52945870/1.

3. Agile model is based on NOT knowing it all up-front. And,

4. Instead, the customer's ideas evolving as they see what they are getting.

5. Not so true in well-known areas.a. Say, a new payroll system.

6. The reason agile continues to work may be that software is inherently novel.

a. High-payoff systems continue to be new-ish.

c. Tricks can speed things up, like i. Overlapping schedules on releases

ii. Adding help in various ways…1. Outside services; say, farm-out testing

a. The fastest development is the one you don't have to do.

b. Especially if it's already done - you buy it!

2. Consultants3. Temporary developers -

a. The Japanese "lifetime employment" model - worked because…

b. The other half of the people were contractors, who came and went.

b. Can you make requirements gathering "rapid"?i. Berenbach's approach, basically, is to prototype along with eliciting

1. Maybe that means throwaway prototypes.2. Maybe it means something like spiral development.3. In either case, you get customer feedback to what you think the

requirements are.ii. Leffingwell's approach, basically, is to do less writing

1. You need something to make up for that, like:a. The developers already know what they are doing, orb. The customer is right there to tell you when you mess-up, orc. The development is speculative, and "interpretations" are ok

2. You write short customer stories, say, instead of use cases.a. This is ok, if either:

i. You can fill these out imaginatively, orii. You know all the rest, precisely, or

iii. You're willing to fix-up how they look, based on customer feedback.

IV. Rapid Development Techniques for Requirements Evolution in Berenbach (Ch 9)a. This is about the "people side" of requirements!

i. Take a customer who lives in one worldii. Add developers who live in a different world

iii. What are the odds they mean the same thing by, "In case of errors, the system shall handle reversal of transactions"?

b. Prototypes force a shared meaning early, because they "are" what the requirements mean, to the extent they represent the real product.

i. Thus, they shorten the time required for developers to "know" what the real requirements are

c. Prototypes can be "throwaway" or part of the real product.i. There's a huge difference

ii. Anyone here who's not ever been stuck using a prototype as a product?d. Situations where prototyping makes sense (pp 236-9)

i. Start with scenarios (like agile "user stories")1. Very general versions of use cases2. Get customer agreement on these (often from their domain experts)

ii. Then prototype these, to see if you are close about the concrete meaning1. Get feedback on the prototypes2. Add detail to the real requirements, and3. Revise the prototypes for another cycle

iii. Use prototypes to resolve conflicts1. This is the hard part of requirements elicitation

a. Conflicting stakeholder requestsb. Local interests versus overall organizational interestsc. Varying interests of different customers

2. Prototypes give more unambiguous meaning, to get and resolve these reactions

3. Dan Starr's levels of customer Wants and Needs:a. Absolutely Essential: “If it Doesn’t Have X, I’m not Interested”b. Part of “Basic” Set: “I Can Live Without X, But If Anybody Else

Offers It I’ll Buy From Them”c. An Important Add-On: “I’ll Buy Your Product Without X, But I’d

Pay Extra if X Were Included”d. A Differentiator If Free: “I’ll Buy Your Product If It Has X, as

Long as X Doesn’t Increase the Cost”e. Irrelevant: “I Couldn’t Care Less Whether Your Product Has X”f. Dysfunctional: “I Don’t Want X, and I’d Rather Buy a Product

Without It”4. The real trouble is if you have two customers, at opposite ends of this

scale about a lot of features.iv. Use prototypes to bridge the skills of stakeholders and developers

1. Many software developers still lack broad domain and business knowledge

2. Many software companies work with customers in a variety of types of businesses

3. Geographical and cultural differences can loom large!v. Capture detailed requirements

1. Written requirements may (appropriately) be abstract2. The prototype becomes a "sample implementation" of those

vi. Time-to-market1. Development often can't be started until requirements reach some level

of reliability2. This single-threading of the activities makes speed of requirements

development a key to successe. Practical experience in developing prototypes in parallel with RE:

i. Have clear goals for each prototypeii. Have people with more domain knowledge do them

iii. Have a small team work on both RE and prototypes togetheriv. A model:

v. Domain experts or customers review both regularlyvi. Stress simplicity and unambiguousness (unambiguity?)

vii. Have multiple functional proposals1. Like in mechanical engineering - a table of:

a. Which way's cheaper?b. Which way lasts longer?c. Which one's easier to fix?d. Which one produces the most profit?

2. NOT like most software shops do it - the first way they think of!viii. Don't have prototyping continue for an extended time

ix. Implement and review multiple features, with overlapping review cycles to prevent blockage. I.e., Use concurrent development like this:

x. Make the prototypes a throwaway!1. The requirements are evolving

f. How to identify and eliminate stakeholder conflicts:i. It's natural to have incompatible needs

ii. Identify as early as possible via reactions to prototypes1. Then take time to resolve conflicts

iii. Start with an agreed sunny-day scenarioiv. Expand on this with more details

1. Typical conflict - what data should be shown or hidden2. Requests for different action sequences

v. Some conflicts are well-known to the stakeholders! And they may have resolution ideas.

vi. Simplify functionality to meet most of everyone's goalsvii. Focus on areas of uncertainty - which are potential conflicts in disguise

viii. Deal with conflicts as these arise1. Can be due to the RE team's discovery that they can't synthesize all the

client input2. Can be due to clients rejecting interpretations you send them 3. Dealing with them iteratively feels more like progress!4. Prototype review allows you to confirm agreements

a. May not be possible to get all stakeholders in one room5. Need to be sure you are hearing from real domain experts

a. If they are "busy" - Danger, Will Robinson!b. Their feedback needs to be informative, timely and actionable.

6. "Experienced domain experts with a broad understanding of their markets, environments, and other critical aspects of the product context are rare, and they are unlikely to be available for extended periods of time in the early stags of product planning and development."

g. Storyboarding - a great tool for prototyping on-the-cheapi. See also Leffingwell's Ch 13

ii. Easy to create, modify, and comment oniii. Development groups often use a standard format like Berenbach recommends

(pp 246 - 248)h. Executable prototypes

i. May or may not be throwawaysii. Need an intentional decision about this!

iii. Most common - "branch prototypes" (p 249)1. Since it's all speculative, each new feature added / changed is a

"branch" - it may be removed, etc.iv. Goal is to be "transparent" about how the real system will work

i. Can also use test-first methods with prototypingi. The prototype pretends to handle the test cases

j. A hidden goal in the process - collaboration among stakeholders!k. Another - making the requirements unambiguous as quickly as possible

i. It sets up the fastest possible feedback loop for requirementsl. Berenbach's discussion questions for this chapter:

i. When should working prototypes be implemented as compared to non-coding-based approaches such as storyboards?

ii. Under which conditions should one consider reusing prototype code for the product development as compared to throwaway prototypes?

iii. How frequently should iterations of prototype feature development and review occur?

iv. When is the best time to stop prototyping and move on to full-scale product development?

V. Leffingwell's Agile Requirements Methods (Ch 30)a. The point is to "mitigate requirements risk"

i. In the terminology of agile development, it's all about identifying and reducing risks systematically

ii. The whole purpose of development is creation of successful codeiii. Anything else can be questioned for valueiv. Typical agile strategies for RE (p 384):

1. Interactive, face-to-face communication is the cheapest and fastest channel for exchanging information.

2. Excess methodology weight is costly.3. Large teams need heavier methodologies.4. Greater ceremony is appropriate for projects with greater criticality.

v. See Leffingwell's Table 30-1, of specific risks related to requirements, like:1. Requirements traceability - Critical requirements might be overlooked in

the implementation.vi. XP - Beck's radical-est approach:

1. Regarding requirements, assumes you need early and continuous user feedback.

2. At the heart, there is a "product concept."3. The product "vision" includes short and long-term versions of this.

VI. What's next? (or, in this case, last) - see schedule and assignmentsA. Course evaluations (planned - They are open all this week on Banner)B. Paper/project -

i. Presentation Tuesday, with some visitors (at least Jared Goulding)ii. Turn in a "coherent" paper Thursday, if not already. And the presentation.

C. Exam 2 - Turn in by next Monday night, Nov 17.D. Next (last) class - Tuesday, August 16, 5:30 PM, here

i. Topics will be 1. Your presentations2. Ch 10 and 11 in Berenbach, if time

Tonight's handout - Start of the discussion of Distributed Requirements Engineering for next time:

What do requirements look like if you are an off-shore development organization? Take a look at SRS.ppt, a file in this same (lectures) directory. It's a slide presentation that's part of a class on requirements from IIT Mumbai (2004), preparing students who will develop software to clients in the US. We'll discuss it tonight as a start on the general discussion of distributed RE on Thursday.

1. What's different about how requirements are treated here, than what we are used to, when they are written for in-house organizations?

2. How do you explain those differences in terms of the position of a development organization in India, versus their client - such as an IT organization in the US?

a. Also read the similar article on outsourcing by Sam Eiring;2 focus on the parts about requirements.

2 There's a copy in this directory. He's from UW Platteville, and you also can find the link on Google for this Outsourcing article.