Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 CS427: Software Engineering I Darko Marinov (slides from Ralph Johnson)

Similar presentations


Presentation on theme: "1 CS427: Software Engineering I Darko Marinov (slides from Ralph Johnson)"— Presentation transcript:

1 1 CS427: Software Engineering I Darko Marinov (slides from Ralph Johnson)

2 CS4276-2 Previous lectures zProject initiation yDecide whether to proceed, cost-benefit yConvince others to proceed, use documents xVision, use cases, risks, project plan [Homework 1] zRisks yTechnical, project, business zRequirements yFunctional vs. non-functional

3 CS4276-3 Requirements zFunctional requirements ySoftware inputs, outputs, and their relationship zNon-functional requirements ySecurity, reliability, usability, scalability, maintanability, efficiency… zToday: Uses cases yHigh-level system description

4 CS4276-4 System description zTypical description has two parts yData yOperations on that data zThree kinds of descriptions yRequirements ySpecification yDesign

5 CS4276-5 Many notations zUML yUse cases yClass diagram yState diagram zHamlet and Maybee yFinite state machine, data flow diagram yProlog yPseudocode

6 CS4276-6 Many purposes zCommunicate to yUser yDevelopers yBoss zComplete - lots of detail zEasy to read - less detail

7 CS4276-7 Writing Effective Use Cases zAuthor: Alistair Cockburn zKnow the inside cover, front and back zMore info on Web (Wikis) yhttp://www.usecases.org (some broken links)http://www.usecases.org yhttp://c2.com/cgi/wiki?UseCases (a bit old)http://c2.com/cgi/wiki?UseCases yPapers yDiscussion boards

8 Where are the use cases?

9 CS4276-9 Use-case diagram zShows actors and use cases zShows system scope and boundaries zNot a description of use cases themselves

10 CS4276-10 Use cases zText - a form of writing zDescribes the system’s behavior as it responds to a request from an actor zMany kinds of use cases yBrief / detailed yRequirement / specification / design

11 CS4276-11 Sequence of events zUse cases describe the sequence of events that happen when the system responds to a request yCan describe alternatives yCan describe errors

12 CS4276-12 Use cases are text zUse cases should be easy to read yKeep them short yTell a story yWrite full sentences with active verb phrases yMake the actors visible in each sentence xVariation: Actor explicitly first, followed by a colon

13 CS4276-13 Many variations of writing zUser stories zActor-goal list zUse case briefs zCasual use cases z“Fully dressed” use cases

14 CS4276-14 Actor-goal list ActorTask-level goalPriority ProviderSubmit paper claim1 Provider Submit fax claim2 ProviderSubmit electronic claim3 Adjud.Adjudicate problem2

15 CS4276-15 Use case briefs Actor Provider Adjucator Goal Submit paper claim Submit fax claim Adjudicate failed claim Brief Submit claim on paper, which is converted into electronic form, and either paid or sent for adjudication. Submit claim by fax, which is processed by OCR and either paid or sent for adjudication. Decide whether a questionable claim should be paid by the mainframe payment system or rejected.

16 CS4276-16 Brief (casual) version of Submit Fax Claim The Provider submits a claim by fax. The claim processing system will log the image to optical disk, apply form dropout, deskewing, despeckling, and then process it using OCR. Knowledge workers will repair any fields that seem to be in error. The claim will then either be paid (using existing mainframe processing system) or sent to adjudication.

17 CS4276-17 Detailed (fully dressed) version of Submit Fax Claim Primary actor: Provider Goal in context: Pay legitimate claims while rejecting bad ones Scope: Business - the overall purchasing mechanism, electronic and nonelectronic, as seen by the people in the company Level: Summary Stakeholders and interests: Provider: Wants to be paid for services rendered Company: Wants to cut costs and avoid fraud Preconditions: none Minimal guarantees: Pay only certified providers, pay only for services that are covered by plan, do not pay if there are obvious mistakes

18 CS4276-18 Main success scenario: Trigger: Claim submitted by fax 1. Provider: submit claim by fax 2. Claim system: drop forms, deskew, despeckle, use OCR to convert to electronic form 3. Claim system: check claim to make sure it is legal 4. Mainframe payment system: pay claim Extensions: 2a. Some fields have low confidence: Knowledge worker corrects 3a. Claim is not valid: Send to adjudication

19 CS4276-19 Your example (1) Use case: Scope: Level: Primary actor: Goal: Stakeholders and interests: Preconditions: Trigger: Minimal guarantees: Success guarantees:

20 CS4276-20 Your example (2) Main success scenario: Extensions:

21 CS4276-21 Use cases and requirements zAn important part of requirements zHelp requirement traceability zHelp manage requirements

22 CS4276-22 Requirements zUse cases zStakeholders - people who care zBusiness case - cost of project, time to complete project zInterfaces with outside systems zTechnology requirements zEase of use, ease of maintenance, throughput and response time

23 CS4276-23 Traceability zTraceability - the ability to trace the effect of a requirement and determine who caused it yWhy do we have this requirement? Who wrote it? yHow is this requirement met? yWhat requirement caused this design?

24 CS4276-24 Manage requirements zMust agree to change in requirements yUsually increases price yMust be reviewed zMake sure each part of design is due to a requirement zAnalyze problems: what was the root cause of this bug?

25 CS4276-25 Scenarios and use cases zScenario is concrete and detailed yNames of people y$ values, particular dates, particular amounts zScenario is a test case zUse case is a contract and collects several scenarios

26 CS4276-26 Goals and use cases zActor has a goal for the use case zSystem forms subgoals to carry out its responsibility zGoals can fail zUse case describes a few ways for carrying out the goal, and a few ways of failing

27 CS4276-27 When use cases don’t work zCompilers yOne use case - compile a program zDespeckler yOne use case - remove speckles zNo interaction zComplexity is caused by yInput format yTransformation

28 CS4276-28 Summary zUse cases are useful, but not perfect zMany ways to write use cases zBig projects need big use cases zUse the simplest way you can!

29 CS4276-29 Next: Planning zChapter 8 of Hamlet and Maybee zRUP: Chapters 12 and 14 of Kroll & Kruchten zXP: Chapter 12 of Beck & Andres or Planning Game (note XP evolution) from say http://c2.com/cgi/wiki?PlanningGame http://c2.com/cgi/wiki?PlanningGame


Download ppt "1 CS427: Software Engineering I Darko Marinov (slides from Ralph Johnson)"

Similar presentations


Ads by Google