sobware&requirementspecificaons& (srs)&...2012/04/05 · april&5&...
TRANSCRIPT
April 5 © Kıvanç Muşlu, University of Washington, 2012 1 of 14
SoBware Requirement SpecificaIons (SRS)
Most of the slides are adapted from the previous quarter’s recitaIon and an exisIng SRS document
With an Emphasis on Use Cases
April 5 © Kıvanç Muşlu, University of Washington, 2012 2 of 14
Use Cases
A wriQen descripIon of the user's interacIon with the soBware product to accomplish a goal • Accurately describes the what system must do • DocumentaIon of func%onality not design – Remember ‘what’ vs. ‘how’
April 5 © Kıvanç Muşlu, University of Washington, 2012 3 of 14
A Few Use Case ClarificaIons…
• Primary Actor: the person interacIng in the use case • Level: granularity, big picture vs. small feature • Minimal/Success “Guarantee”
– Guarantee == Post-‐condiIon – Minimal/Success == worst case/best case
• Main Success Scenario – Describes how user uses system to successfully complete a task
• Extensions – Alternate paths in success scenario (usually failure cases) – Should maintain minimal guarantee
April 5 © Kıvanç Muşlu, University of Washington, 2012 4 of 14
Personal Advisors Finance Package
April 5 © Kıvanç Muşlu, University of Washington, 2012 5 of 14
SRS DefiniIon
“A soBware requirements specificaIon (SRS) is a complete descripIon of the behavior of a system to be developed.”
Wikipedia
April 5 © Kıvanç Muşlu, University of Washington, 2012 6 of 14
SRS Outline • IntroducIon: Purpose, scope and overview • Overall DescripIon – System environment
• FuncIonal Reqs: “What” your soBware does – Use case scenarios
• User CharacterisIcs: How will different actors interact with your soBware
• Non-‐funcIonal Requirements: Imposed by the employer & users – Quality standards, performance requirements, etc
April 5 © Kıvanç Muşlu, University of Washington, 2012 7 of 14
Example: Web Publishing System
Example from: www.courses.utep.edu/portals/870/S04-‐F04%20SRS%20v0.91.doc
April 5 © Kıvanç Muşlu, University of Washington, 2012 8 of 14
Scope
• Web publishing system for an editor • Goal: Maximize editor’s producIvity – Automated arIcle review and publishing
• Facilitate communicaIon between the editor, a group of reviewers and the author via email – PreformaQed reply forms to provide uniform reviewing process
April 5 © Kıvanç Muşlu, University of Washington, 2012 9 of 14
System Environment Diagram
April 5 © Kıvanç Muşlu, University of Washington, 2012 10 of 14
Use Case 01: Search ArIcle
April 5 © Kıvanç Muşlu, University of Washington, 2012 11 of 14
Use Case 02: Submit ArIcle
April 5 © Kıvanç Muşlu, University of Washington, 2012 12 of 14
Non-‐funcIonal Requirements
April 5 © Kıvanç Muşlu, University of Washington, 2012 13 of 14
Your SRS Outline
• Follow the informaIon on the web – mostly straighqorward, but answer quesIons thoroughly
• Write in complete sentences and paragraphs • Explain your choices, describe your product as if we have not seen your presentaIon
• Parts: – Product descripIon, Use cases (also in SRS) – UI diagrams, process, customer meeIng report
April 5 © Kıvanç Muşlu, University of Washington, 2012 14 of 14
Reminders
• Group MeeIngs – Name your team! – Select your Program Manager (PM) – Schedule your weekly group meeIngs and let your TAs know your meeIng Imes • We won’t be able to meet with each group every week, but we will try our best and coordinate with your PMs • Also you can always setup appointments with us
• SRS document due on April 10 (next Tue.) @11PM