軟件需求分析課件：Chap 3-Inception

1、Inception Phase Ch3: Case Study Ch4: Inception is Not the Requirements Phase Ch5: Evolutionary Requirements Ch6: Use Cases Ch7: Other Requirements1The Unified Process2Adapting the UPApart form the fundamental principles (such as iterative and evolutionary, risk and client-driven development, realist

2、ic continuous verification of quality), the UP is very flexible.We can write-up a Development Case document during inception to detail the choices of practices and artifacts that will be adopted for a project.3DisciplinePracticeArtifactIterations -InceptionI1ElaborationE1.EnConstructionC1.CnTransiti

3、onT1.TnBusiness ModelingRequirement workshop, Agile modellingDomain ModelsRequirementsRequirement workshop, vision box exercise,Dot votingUse Case modelVisionSupplementary SpecificationGlossaryssssrrrrDesignAgile modelling, test-driven developmentDesign ModelSW architecture documentssrImplementation

4、Pair programming, testdriven developmentCodesrrProject managementDaily scrum meetingsrrr4You Know you did not Understand Iterative Development When Define all the requirements details before start (or the entire detailed design;spend weeks doing UML modelling before programming;Inception = requireme

5、nts analysis, elaboration = design and construction = coding;Iterations are months long rather than weeks;Plans are fuzzy, overly detailed, document led and rigorously enforced;People work in isolation, handing one document after another to the next person (e.g. requirements specification from analy

6、st to a designer, design document to programmer, code to tester);5Book Organization6Chapter 3. Case Studies71. What is and is not Covered in the Case Study?Traditional business software applications include UI elements, core application logic, database access and links to external software or hardwa

7、reOur focus is on OOA/D in the core application logic layerOther layers are usually very technology/platform dependent, change quickly The OO design of the core logic layer is similar across technologies, OO design skills are applicable to all other layers 8Simple Layer Architecture Scheme 92. Case

8、Study Strategy: Iterative Development + Iterative Learning10A point-of-sale (POS) system:A computerised application used to record sales and handle payment;It interfaces to various external applications and must be relatively fault-tolerantinventory controlbanking software (credit card) Third party

9、tax calculatorMay support multiple and varied client-side terminals and interfaces (web browser, desktops ,PDA, etc.);May be generic so that it can be sold to many clients (shop-chains) in various with disparate needs in terms of business rule processing3. Case One: The NextGen POS System11Chapter 4

10、. Inception is Not the Requirements PhaseObjectivesDefine the inception step.Motivate the following chapters in this section12Inception is the initial short step to establish a common vision and basic scope for the projectA phase to clarify things-up a bitWhat is the vision of this project, its scop

11、e?Feasibility?Buy components and glue or from scratch?Very rough cost and schedule?Can we convince people of business case?Not a phaseDefining precise requirementsGetting good estimates1. What is Inception?13Analogy from oil business1. Decide if there is evidence(business case) to justifyexploratory

12、 drilling2. If so, do measurements and exploratory drilling3. Provide estimates Inception is like step 1: a feasibility study14Inception objectivesEstablish vision, scope and business caseVision: What do we want?Scope: What do we include and not include?Business case: Who wants it and why?Determine

13、primary scenarios as Use CasesCompleteness not necessary, maybe just 10%Estimate feasibility and risksIdentification of development environment needsStart defining terms in a glossary. 15Short.It may even be shorter (less than a week) if the project is commissioned by a client.Sometimes business neg

14、otiations will take much longer however 2. How Long Should the Inception Phase be?16Potential artifacts:Vision and Business Case: describes the high-level goals and constraints, provides an executive summary;Use Case Model: describes the fundamental requirements: during inception identify the names

15、of the use cases and analyse perhaps 10% of the them;Supplementary specification: describe non-functional requirements, look-and-feel, atmosphere etc.Glossary: keeping track of key terms;Risk list and risk management plan: describe the risks (business, technical, resource, schedule) and ideas for th

16、eir mitigation;Prototypes and proof-of-concepts: to clarify the vision, and validate technical ideas;Iteration Plan: Describes what to do in the first elaboration iteration, and overall goals of the elaboration phase;Development Case: Customised software development process;3. Which Artifacts Should

17、 be Started?17It takes more than a few weeksYou attempt to define most of the requirementsEstimates are expected to be reliableYou define the architectureThere is no business case or visionAll of the use cases were writtenNo use cases were written4. You Know you did not Understand Inception when 18C

18、hapter 5. Evolutionary RequirementsObjectivesMotivate doing evolutionary requirementsDefine the FURPS+ modelDefine the UP requirements artifacts191. Definition : Requirements“Requirements are capabilities and conditions to which the system, and more broadly the project, must conform”Challenges: Find

19、 Communicate Remember Requirement changes are inevitable, so effective management is critical 20Factors that Challenge Projects 21A Joke about Software Development 22Waterfall requirements Believe in the efficacy of full, early requirements for software projectsIn fact, attempting waterfall practice

20、s was the single largest contributing factor to failure (No. 1 in 82% of the project failure) In fact, almost 65% of the waterfall-specified features were of little or no value Evolutionary requirements Embrace change in requirements as a fundamental driver on projects start release-grade programmin

21、g and testing long before most of the requirements have been analysed (perhaps only 10% of the requirements have been specified whenever coding starts). 2. Evolutionary vs. Waterfall Requirements23Surely the client will know them all Do they?Eliciting the real requirements is in general difficult. Y

22、ou must use whatever technique is necessary:Writing use cases;Requirements workshop;Maximum involvement of the client; Prototypes;Focus groups with proxy customers;Increment demonstration after each iteration;Active feedback solicitation;Good communication practices;3. Means to Find Requirements?24F

23、URPS+ modelFunctional features;Usability human factors, help, documentation;Reliability frequency of failure, recoverability;Performanceresponse times, throughput, resource usage;Supportability adaptability, maintainability, internationalisation;4. Types and Categories of Requirements25the + indicat

24、es ancillary requirements or constraints such as:Implementation language and tools, hardware restrictions;Interface interfacing constraints;Packaging physical box;Legal licensing;26Another, much coarser, categorisation is functional and non-functional requirements.Categories are good (up to a point

25、) as a checklist : we are less likely to forget some of the requirements.27Use Case Model a set of typical scenarios (primarily for functional requirements);Supplementary Specification basically for non-functional requirements;Glossary a central repository of noteworthy terms;Vision summarises the r

26、equirements and the business case for the project. Includes a short executive overview;Business Rules (aka Domain Rules) external constraints that the project will have to respect, e.g. Banking procedures, network protocols, safety critical software regulations;5. How are Requirements Organised in U

27、P Artifacts?28Chapter 6. Use CasesObjectivesIdentify and write use cases Use the brief, casual, and fully dressed formats, in an essential style Apply tests to identify suitable use cases Relate use case analysis to iterative development 291. IntroductionUse cases are text stories of some actor usin

28、g a system to meet goalswidely used ，the F in FURPSUse cases are text,not diagramidentify and write good use casesUse case model = a set of use casesUse cases have nothing to do with objects simple, user-centric; they form a kind of contract of how an application should behave from a user point-of-v

29、iew.Use Cases influence many UP artifacts30Use Cases within the UP31Process Sale A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each purchased item. The system presents a running total and line-item details. The customer enters payment information,

30、 which the system validates and records. The system updates inventory. The customer receives a receipt from the system and then leaves with the items.Instead of recording requirements as a list (the system will do : ), use cases capture the requirements in the following style:This actor does this an

31、d the system responds this way etc.2. A Use Case Example (brief format )323. Motivation: Why Use Cases?Use case are text stories, they are simple and familiar More user centric (compared with traditional feature list) Who is using the system? What are their typical scenarios of use? What are their g

32、oals? The central mechanism to discover and define the functional requirements Able to scale both up and down in terms of sophistication and formality 33Actor something with behavior, such as a person (identified by role), computer system, or organization; e.g. a cashier, a player.Scenario (aka a us

33、e case instance) a specific sequence of actions and interactions between actors and the system : it is one particular story of using a system, or one path through a use case.Use case a collection of related success and failure scenarios that describe an actor using a system to support a goal. 4. Def

34、inition34Handle ReturnsMain Success Scenario: A customer arrives at a checkout with items to return. The cashier uses the POS system to record each returned item (as before)Alternate Scenarios:If the customer paid by credit, and the reimbursement transaction to their credit account is rejected, info

35、rm the customer and pay them with cash.If the item identifier is not found in the system, notify the Cashier and suggest manual entry of the identifier code (perhaps it is corrupted).If the system detects failure to communicate with the external accounting system, Hence a use case contains a set of

36、scenarios.A Use Case Example (casual format )35Three Kinds of ActorsPrimary actor Who drive use case Eg. CashierSupporting actorWho provides a service or informationeg. payment authorization service Offstage actor Who has an interest in the behavior of the use case, but is not primary or supportinge

37、g. government tax agency365. Three Common Use Case FormatsBriefone-paragraph summary, main success scenario Created during early requirements analysis, to get a quick sense of subject and scope. Casualmultiple, informal paragraphs covering many scenarios Fully-Dressedall steps and variations written

38、 in detail with supporting sections during the first requirements workshop a few (such as 10%) of the architecturally significant and high-value use cases are written in this format376. A Use Case Example (Fully Dressed Style)Use Case SectionCommentUse Case NameStart with a verb.ScopeThe system unde

39、r design.Leveluser-goal or sub functionPrimary ActorCalls on the system to deliver its services.Stakeholders and InterestsWho cares about this use case, and what do they want?PreconditionsWhat must be true on start?Success GuaranteeWhat must be true on successful completion, and worth telling the re

40、ader.Main Success ScenarioA typical path scenario of success.ExtensionsAlternate scenarios of success or failure.Special RequirementsRelated non-functional requirements.38 continuedUse Case SectionCommentTechnology and Data Variations ListVarying I/O methods and data formats.Frequency of OccurrenceI

41、nfluences investigation, testing, and timing of implementation.MiscellaneousSuch as open issues.39Use Case UC1 : Process SaleScope: NextGen POS applicationLevel: user goalPrimary Actor: CashierStakeholders and Interests:Cashier: Wants accurate, fast entry, and no payment errors, as cash drawer short

42、ages are deducted from his/her salary.Salesperson: Wants sales commissions updated.The following is an example for our POS application:40Customer: Wants purchase and fast service with minimal effort. Wants easily visible display of entered items and prices. Wants proof of purchase to support returns

43、.Company: Wants to accurately record transactions and satisfy customer interests. Wants to ensure that Payment Authorization Service payment receivables are recorded. Wants some fault tolerance to allow sales capture even if server components (e.g., remote credit validation) are unavailable. Wants a

44、utomatic and fast update of accounting and inventory.Manager: Wants to be able to quickly perform override operations, and easily debug Cashier problems.Government Tax Agencies: Want to collect tax from every sale. May be multiple agencies, such as national, state, and county.Payment Authorization S

45、ervice: Wants to receive digital authorization requests in the correct format and protocol. Wants to accurately account for their payables to the store.Preconditions: Cashier is identified and authenticated.Success Guarantee (aka Post conditions): Sale is saved. Tax is correctly calculated. Accounti

46、ng and Inventory are updated. Commissions recorded. Receipt is generated. Payment authorization approvals are recorded. continued41Main Success Scenario (or Basic Flow):Customer arrives at POS checkout with goods and/or services to purchase.Cashier starts a new sale.Cashier enters item identifier.Sy

47、stem records sale line item and presents item description, price, and running total. Price calculated from a set of price rules.Cashier repeats steps 3-4 until indicates done.System presents total with taxes calculated.Cashier tells Customer the total, and asks for payment.Customer pays and System h

48、andles payment.System logs completed sale and sends sale and payment information to the external Accounting system (for accounting and commissions) and Inventory system (to update inventory).System presents receipt.Customer leaves with receipt and goods (if any). continuedSee rest of UC1 on textbook

49、42Scope System use case vs. business use case Level : User-goal level -Elementary business process (EBP) Subfunction-level-describes substeps required to support a user goal, usually shared by several regular use cases; e.g.Pay by CreditStakeholders and Interests List (Important) :by focusing on wha

50、t the stakeholders want out of a given use case we are less likely to miss important requirements.Preconditions : What must always be true before any of the scenarios in the use case can begin. 7. What do the Sections Mean?43Success Guarantees (aka Post conditions) What must be true on successful co

51、mpletion of the use case either the main success scenario or some alternate path. should meet the needs of all stakeholdersMain Success Scenario (aka Basic Flow) Records steps: interactions between actors; a validation (by system); a state change (by system) Extensions (aka Alternate Flows)Scenario

52、branches (success/failure) Longer/more complex than basic flow Branches indicated by letter following basic flow step number, e.g. “3a” Two parts: condition, handling Special Requirements mainly non-functional requirementsrelates specifically to a use case Technology and Data Variations ListOften te

53、chnical constraint imposed by input or output technologies. E.g.The POS system must support credit account input using a card reader and the keyboard.“ 44A main alternative use case notation is to present the use case as a conversation between the actors and the system in a two column formatMain Suc

54、cess Scenario:Actor Action (or Intention)System Responsibility1. Customer arrives at a POS checkout with goods and/or services to purchase.2. Cashier starts a new sale3. Cashier enters item identifier.4. Records each sale line item, presents item description and running total.Cashier repeats steps 3

55、-4 until indicates done.5.Presents total with taxes calculated.6.Cashier tells Customer the total, and asks for payment.7.Customer pays.8.Handles payment.98. Notation: A Two-Column Variation45Essential Style Writing Keep the user interface out and focus on actor intent Essential Style: 1.Administrat

56、or identifies self. 2.System authenticates identity. 3. Concrete Style: 1.Administrator enters ID and password in dialog box (see Picture 3). 2.System authenticate Administrator. 3.System displays the “edit users” window (see Picture 4). 4. 9. Guideline: Write Use Cases in UI-Free Style46Concentrate

57、 at this early stage on what the user needs not on how it will work internallyDo write the system records the saleNot The system writes the sale to the database via or even worse the system generates an SQL INSERT statement for the saleFrom the actors point of view only to stress observable user val

58、ue and focus on users typical goals.10. Guideline: Write Black-Box Use Cases47Choose the system boundarysoftware application, the hardware ,person, organizationIdentify the primary actors those that have goals fulfilled through using services of the system.Identify the goals for each primary actorUs

59、e highest level that satisfies EBPException: CRUD Define use cases that satisfy user goals; name them according to their goal.Start the name of use cases with a verb11. How to Find Use Cases48Is the Cashier or Customer the Primary Actor?Primary actors and goals at different system boundaries49Guidel

60、ine: Brainstorm the primary actors first, as this sets up the framework for further investigation.In addition to obvious primary actors and goals, the following questions help identify others that may be missed:Who starts and stops the system? Who does system administration? Who does user and securi