07 September 2006Kaiser: COMS W4156 Fall 20061 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser [email protected]

07 September 2006 Kaiser: COMS W4156 Fall 2006 1

COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]

http://york.cs.columbia.edu/classes/cs4156/

mailto:[email protected]



Requirements

• What is the (future) software system supposed to “do”?

• Usage scenarios– User stories– Use Cases– …


User Stories• Written by the customers (or end-users) as

things that the system needs to do for them

• About 3 sentences in the customer’s terminology, without technical detail

• Written on index cards (!)• May be augmented by samples (e.g.,

formatted report)• Prioritize (high, medium, low)


Example Story Card

111 Instructor View

The instructor view for a given course includes the course number, name and semester; a button to edit the introduction; a button to designate library reserves; and a button to adjust settings for the course.

Otherwise the instructor view is the same as the student view.

Priority High


Continuing Example

222 Student View

The student view for a given course includes the course number, name and semester; general courseinformation; and instructor information.

There are buttons to select introduction, discussion, board, class e-mail, dictionary, notepad and help.

Priority High


Continuing Example

123 Instructor vs. Student View

When an instructor selects one of the courses he/she is teaching, the instructor view is shown.The instructor view should include a button to show the student view, and then that special studentview should include a button to switch back to the instructor view

Priority Medium


Continuing Example

321 Login

The user is prompted to enter uni and password

If the uni and password match database,the user is shown the default screen with his/her list of current courses

Priority High


Why are user stories on cards?

• Tangible Unit of– Discussion– Estimation– Scheduling– Testing– Completion

• Used for:– Construction of engineering tasks– Creation of acceptance tests– Derivation of time estimates for planning


Use Case Modeling

• Use case model = a view of a system that emphasizes the behavior as it appears to external actors

• Partitions system functionality into interactions (‘use cases’) that are meaningful to users or external systems (‘actors’)


Use Case Diagram

• Using, e.g., UML = Unified Modeling Language• Visualizes the high-level functions of the system

and the system's scope– Including the relationship of "actors" to essential

processes and system functionality– As well as the relationships among different use

cases

• By looking at a use case diagram, you can easily tell the functions that the system provides (and doesn’t provide)


Example• This system lets the band

manager view a sales statistics report and the Billboard 200 report for the band's CDs

• It also lets the record manager view a sales statistics report and the Billboard 200 report for a particular CD

• The diagram also tells us that our system delivers Billboard reports from an external system called Billboard Reporting Service


Simple Example

• This use case diagram does not provide a way for a band manager to listen to songs from the different albums on the Billboard 200 — i.e., we see no reference to a use case called Listen to Songs from Billboard 200


Customer

Supervisor

SalespersonPlace

Establishcredit

Check

Telephone Catalog

Fill orders

Shipping Clerk

status

order

Another Simple Example

07 September 2006 Kaiser: COMS W4156 Fall 2006 14Fig. 3-54, UML Notation Guide

Not So Simple Use Case Relationships

additional requests :

OrderProduct

SupplyArrange

«include»«include»«include»

RequestCatalog

«extend»Extension points

PaymentCustomer Data

after creation of the order

Place Order

1 * the salesperson asks forthe catalog


Yet Another Simple Example

Online HR System

LocateEm ployees

UpdateEm ployee

Profile

Update Benefits

Access TravelSystem

Access PayRecords

Em ployee

M anager

Healthcare P lan System

{if currentMonth = Oct.}

{readOnly}

Insurance P lan System


More Not So Simple Use Case Relationships

Update M edicalP lan

Update DentalP lan

Update Benefits______________Extension pointsbenefit options:

after required enrollm ents

UpdateInsurance P lan

Em ployee

<<include>> <<include>> <<include>>

ElectReim bursem entfor Healthcare

Elect StockPurchase

<<extend>>em ployee requestsstock purchase option

<<extend>>em ployee requestsreim bursem ent option

extensioncondition

extension pointname andlocation


Use Cases vs. User Stories

• Both intended to capture requirements

• Use Cases are more formal – UML details introduced later in course

• User Stories tend to be more fine-grained

• User Stories don’t easily map relationships


One problem with User Stories and User Cases

• Where do the usage scenarios come from?

• The customers (or users).

• But how do the customers know what to put in their usage scenarios?


Requirements Elicitation

• Process of discovering the requirements for a system.• Through communication with customers, system users,

system administrators, and other stakeholders.• Through domain analysis.• Through investigation of previous and similar systems –

reuse requirements– Saves time and money. – Reduces risk. – Reused requirements have a better chance of being understood

by all stakeholders.– Requirements reuse may lead to additional reuse in other

lifecycle activities.


Requirements Elicitation• Use Business Concerns to drive elicitation

– If a system is to be useful, it must contribute to the key concerns of the business.

– If those business concerns are identified and used as drivers of the requirements elicitation process, there will be higher confidence that the system will meet real organization needs.

• Collect requirements from Multiple Viewpoints– If the requirements are collected from a single viewpoint,

unlikely to meet other stakeholders requirements.– Identified viewpoints can be used to help organize

requirements elicitation and the resulting requirements specification.


Requirements Challenges: “Yes, But”

• The first time users see the system, the first reaction is either, “Wow this is so cool” or “Yes, but, hmm, now that I see it what about this…?”

• This reaction is simply human nature.

• Need to get the “buts” out early.

• Anticipate that there will be “buts” and add time and resources to plan for feedback.


Requirements Challenges: “Undiscovered Ruins”

• Developers struggle with determining when they are done with requirements elicitation.– How can we tell whether all the requirements have

been elicited, or have we found at least enough?– Like asking an archeologist “how many undiscovered

ruins are there?”• First scope the elicitation effort by defining the

business problem(s) to be solved by the system.• Employ techniques that help find some of those

ruins and get the stakeholders to buy-into the requirements.


Requirements Challenges:“User versus Developer”

• Users do not know what they want, or cannot articulate it.

• Users think they know what they want until developers give them what they said they wanted.

• Developers think they understand user problems better than users do.

• Recognize and appreciate the users as domain experts.

• Provide alternative elicitation techniques earlier: storyboard, role playing, prototypes, etc.

• Put the developers in the users’ place.


Requirements Challenge: Living with “the Sins

of your Predecessors”• Like it or not, your customers and developers

remember what happened in the past.– “Total Quality Management” programs that promised

things would be different.– The last project where requirements were vague and/or

were delivered short of expectations.• Need to build trust slowly: do not over-commit to

features, schedule, or budget.• Deliver highest priority features early.


Requirements Elicitation Techniques

• Interviewing and questionnaires

• Brainstorming and idea reduction

• Storyboarding

• Role Playing

• Requirements workshops

• Prototyping


Technique: Interviewing

• Simple direct technique

• Context-free questions about what system needs to do for the users

• Convergence on some common needs will initiate a “requirements repository”

• A questionnaire is no substitute for an interview, but may precede or follow interviews


Interview: Context-free questions

• Goal is to prevent prejudicing the user’s response to the questions

• Examples:– Who is the customer?– Who is the user?– Who is the user’s customer?– Are their needs different?– Where else can a solution to this problem be found?

• After context-free questions are asked, suggested solutions can be explored


Technique: Brainstorming

• Brainstorming involves both idea generation and idea reduction

• The most creative, innovative ideas often result from combining seemingly unrelated ideas

• Various voting techniques may be used to prioritize the ideas created

• Although live brainstorming is preferred, web-based brainstorming may be a viable alternative


Rules for Brainstorming

• Do not allow criticism or debate• Let your imagination soar• Generate as many ideas as possible• Mutate and combine ideas• Only then do Idea Reduction

– Prune ideas that are not worthy of further discussion– Group similar ideas into one super topic

• Prioritize the remaining ideas


Technique: Storyboarding

• Scripted walkthrough of system activities and/or screen mockups

• Identify the players, explain what happens to them, and describes how it happens

• Make the storyboard sketchy and easy to modify


Technique: Role Playing

• Role playing allows developers to experience the user’s world from the user’s perspective

• Live storyboard or unscripted walkthrough

• Generate system activities and/or screen mockups as you go along


Technique: Requirements Workshop

• Perhaps the most powerful technique for eliciting requirements

• Gather all key stakeholders together for a short but intensely focused period

• Use an outside facilitator experienced in requirements management

• May combine interviewing, brainstorming, storyboards, role playing


Technique: Prototyping

• Partial implementation of a software system, built to help developers, users and customers better understand system requirements

• Focus on the “fuzzy” requirements: poorly defined and/or poorly understood


Pair Formation assignment due Thursday September 14th

• Find a partner• Make sure your schedules are compatible!• Make sure you both use the same

language and platform!• Both submit the assignment (via email) • May optionally indicate the other pair with

whom you’d like to work in a team (otherwise will be assigned)

• Teams will be announced September 26th


Individual Development Assignment #1 due Tuesday September 19th

• “Traditional” distributed computing • Design an Auction House application

(submit design document only, no code)• 3 kinds of components:

– Supplier: infinite supply of auction Items– Customer(s): bid for next auction Item– AuctionHouse: sells a limited set of Items to

Customer; buys new Items from Supplier


IDA #1

• Freedom to decide functionality– Set your own requirements– Make your own assumptions

• You may use fast prototyping, if desired, to better understand problem and validate design

• Assume favorite programming or scripting language

• Do NOT assume any fancy distributed computing / component framework– e.g. .NET, Web Services, CORBA, EJB and the such

(that’s for the future)


IDA #1• Communication protocol:

– Sockets on a well-known port– RPCs– Other?

• Bidding protocol: Customer(s) and AuctionHouse must have a way to– Negotiate price– Recognize an acceptable bid– Finalize transaction

• Functional interfaces: AuctionHouse is a client to Supplier and a server to Customer(s)

• Interaction model, many choices like:– Negotiation session by single Customer– Sequential bids by multiple Customers– Concurrent bids by multiple Customers


IDA #1

• Work on design for no more than 2.5 hours• Deliverable (via CourseWorks): 3-6 pages

– 1-2 pages: Your requirements, assumptions and informal usage scenarios.

– 1-2 pages: Major structural elements and communication protocols of your design. Include diagrams/illustrations as warranted.

– 1-2 pages: Solution highlights, major problems, what is particularly easy/difficult to achieve.

• Graded pass/fail (a “checkmark”)


Upcoming

• Individual development assignment #2 due September 26th

• Teams announced September 26th

• Team project concept due October 3rd

• Individual development assignment #3 due October 10th

• Revised project concept due October 17th


COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]


mailto:[email protected]


Documents

07 September 2006Kaiser: COMS W4156 Fall 20061 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser [email protected]