CSSE 571
Fall, 2014
Notes for class 9
Thursday, 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 yesterday
i. 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 topic
a. Rapid development
i. Ch 9 in Berenbach
ii. 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 - Intro
a. Everyone wants "rapid development"!
i. Time to develop may be a more important variable than cost
1. It is the time-to-market
2. 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 beneficial
b. 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 processes
a. Automation, like Berenbach's tools for modeling
b. Agile and "rapid" development processes
i. Often, a key of "doing less"
ii. Eliminate processes that aren't adding value
iii. Especially less paperwork
1. 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 upfront. 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. Consultants
3. 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, or
b. The customer is right there to tell you when you mess-up, or
c. 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, or
ii. 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 world
ii. 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 cases
2. Get customer agreement on these (often from their domain experts)
ii. Then prototype these, to see if you are close about the concrete meaning
1. Get feedback on the prototypes
2. Add detail to the real requirements, and
3. Revise the prototypes for another cycle
iii. Use prototypes to resolve conflicts
1. This is the hard part of requirements elicitation
a. Conflicting stakeholder requests
b. Local interests versus overall organizational interests
c. 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 abstract
2. The prototype becomes a "sample implementation" of those
vi. Time-to-market
1. Development often can't be started until requirements reach some level
of reliability
2. This single-threading of the activities makes speed of requirements
development a key to success
e. Practical experience in developing prototypes in parallel with RE:
i. Have clear goals for each prototype
ii. Have people with more domain knowledge do them
iii. Have a small team work on both RE and prototypes together
iv. A model:
v. Domain experts or customers review both regularly
vi. Stress simplicity and unambiguousness (unambiguity?)
vii. Have multiple functional proposals
1. 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:
f.
x. Make the prototypes a throwaway!
1. The requirements are evolving
How to identify and eliminate stakeholder conflicts:
i. It's natural to have incompatible needs
ii. Identify as early as possible via reactions to prototypes
1. Then take time to resolve conflicts
iii. Start with an agreed sunny-day scenario
iv. Expand on this with more details
1. Typical conflict - what data should be shown or hidden
2. 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 goals
vii. Focus on areas of uncertainty - which are potential conflicts in disguise
viii. Deal with conflicts as these arise
1. Can be due to the RE team's discovery that they can't synthesize all the
client input
2. 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 room
5. 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-cheap
i. See also Leffingwell's Ch 13
ii. Easy to create, modify, and comment on
iii. Development groups often use a standard format like Berenbach recommends
(pp 246 - 248)
h. Executable prototypes
i. May or may not be throwaways
ii. 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 prototyping
i. 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 requirements
l. Berenbach's discussion questions for this chapter:
i. When should working prototypes be implemented as compared to non-codingbased approaches such as storyboards?
ii. Under which conditions should one consider reusing prototype code for the
product development as compared to throwaway prototypes?
V.
VI.
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?
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 code
iii. Anything else can be questioned for value
iv. 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.
What's next? (or, in this case, last) - see schedule and assignments
A. 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 presentations
2. 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.