Upload
rudolf-jones
View
221
Download
1
Tags:
Embed Size (px)
Citation preview
07 September 2006 Kaiser: COMS W4156 Fall 2006 1
COMS W4156: Advanced Software Engineering
Prof. Gail Kaiser
http://york.cs.columbia.edu/classes/cs4156/
07 September 2006 Kaiser: COMS W4156 Fall 2006 2
Requirements
• What is the (future) software system supposed to “do”?
• Usage scenarios– User stories– Use Cases– …
07 September 2006 Kaiser: COMS W4156 Fall 2006 3
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)
07 September 2006 Kaiser: COMS W4156 Fall 2006 4
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
07 September 2006 Kaiser: COMS W4156 Fall 2006 5
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
07 September 2006 Kaiser: COMS W4156 Fall 2006 6
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
07 September 2006 Kaiser: COMS W4156 Fall 2006 7
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
07 September 2006 Kaiser: COMS W4156 Fall 2006 8
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
07 September 2006 Kaiser: COMS W4156 Fall 2006 9
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’)
07 September 2006 Kaiser: COMS W4156 Fall 2006 10
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)
07 September 2006 Kaiser: COMS W4156 Fall 2006 11
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
07 September 2006 Kaiser: COMS W4156 Fall 2006 12
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
07 September 2006 Kaiser: COMS W4156 Fall 2006 13
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
07 September 2006 Kaiser: COMS W4156 Fall 2006 15
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
07 September 2006 Kaiser: COMS W4156 Fall 2006 16
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
07 September 2006 Kaiser: COMS W4156 Fall 2006 17
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
07 September 2006 Kaiser: COMS W4156 Fall 2006 18
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?
07 September 2006 Kaiser: COMS W4156 Fall 2006 19
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.
07 September 2006 Kaiser: COMS W4156 Fall 2006 20
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.
07 September 2006 Kaiser: COMS W4156 Fall 2006 21
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.
07 September 2006 Kaiser: COMS W4156 Fall 2006 22
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.
07 September 2006 Kaiser: COMS W4156 Fall 2006 23
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.
07 September 2006 Kaiser: COMS W4156 Fall 2006 24
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.
07 September 2006 Kaiser: COMS W4156 Fall 2006 25
Requirements Elicitation Techniques
• Interviewing and questionnaires
• Brainstorming and idea reduction
• Storyboarding
• Role Playing
• Requirements workshops
• Prototyping
07 September 2006 Kaiser: COMS W4156 Fall 2006 26
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
07 September 2006 Kaiser: COMS W4156 Fall 2006 27
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
07 September 2006 Kaiser: COMS W4156 Fall 2006 28
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
07 September 2006 Kaiser: COMS W4156 Fall 2006 29
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
07 September 2006 Kaiser: COMS W4156 Fall 2006 30
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
07 September 2006 Kaiser: COMS W4156 Fall 2006 31
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
07 September 2006 Kaiser: COMS W4156 Fall 2006 32
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
07 September 2006 Kaiser: COMS W4156 Fall 2006 33
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
07 September 2006 Kaiser: COMS W4156 Fall 2006 34
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
07 September 2006 Kaiser: COMS W4156 Fall 2006 35
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
07 September 2006 Kaiser: COMS W4156 Fall 2006 36
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)
07 September 2006 Kaiser: COMS W4156 Fall 2006 37
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
07 September 2006 Kaiser: COMS W4156 Fall 2006 38
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”)
07 September 2006 Kaiser: COMS W4156 Fall 2006 39
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
07 September 2006 Kaiser: COMS W4156 Fall 2006 40
COMS W4156: Advanced Software Engineering
Prof. Gail Kaiser
http://york.cs.columbia.edu/classes/cs4156/