WIXLIB

2.8UP seIterationsIter 15 CoreWorkflows R A D ElaborationIter 2IT Iter 3 tionTransitionIter 4 Iter 5 Iter 6 Each phase can include several iterations Life-cycleArchitectureThe exact number of iterations per phase depends on the size of the project!e.g. one iteration per phase for small projectsEach phase concludes with a major milestone Clear View Training 2010 v2.638

2.9Phases and Workflows This figure is thekey tounderstandingUP!For each phasewe will consider: The focus interms of thecore workflowsThe goal for thephaseThe milestoneat the end ofthe ransitionamount of rationsI1I2 Clear View Training 2010 v2.6InIn 1In 2ImIm 139

2.9.2InceptionRequirements – establish business case andscope. Capture core requirementsamount of workin each core workflowInception ElaborationRA DIConstructionTransitionAnalysis – establish feasibilityFocusDesign – design proof of concept or technicalprototypesImplementation – build proof of concept ortechnical prototypeTest – not generally applicableGoalsEstablish feasibility of the project - create proof of concept/technical prototypesCreate a business caseScope the system - capture key requirementsIdentify critical risks Clear View Training 2010 v2.640

2.9.3Inception - milestone Life Cycle Objectives - conditions of satisfaction: System scope has been definedKey requirements for the system have been captured. Thesehave been defined and agreed with the stakeholdersAn architectural vision exists. This is just a sketch at thisstageA Risk AssessmentA Business CaseProject feasibility is confirmedThe stakeholders agree on the objectives of the project Clear View Training 2010 v2.641

2.9.4ElaborationRequirements – refine system scope andrequirementsR ADInception ElaborationConstructionITTransitionAnalysis – establish what to buildFocusDesign – create a stable architectural baselineImplementation – build the architecturalbaselineTest – test the architectural baselineGoalsCreate an executable architectural baselineRefine Risk Assessment and define quality attributes (defect rates etc.)Capture use cases to 80% of the functional requirementsCreate a plan with sufficient detail for the construction phaseFormulate a bid which includes resources, time, equipment, staff, cost Clear View Training 2010 v2.642

2.9.6Elaboration - milestone Lifecycle Architecture - conditions ofsatisfaction: A resilient, robust executable architectural baselinehas been createdThe Risk Assessment has been updatedA project plan has been created to enable a realisticbid to be formulatedThe business case has been verified against theplanThe stakeholders agree to continue Clear View Training 2010 v2.643

2.9.7ConstructionR ARequirements – uncover any requirementsthat had been missedInception ElaborationConstructionDITTransitionAnalysis – finish the analysis modelFocusDesign – finish the design modelImplementation – build the Initial OperationalCapabilityTest – test the Initial Operational CapabilityGoalsComplete use case identification, description and realizationFinish analysis, design, implementation and testMaintain the integrity of the system architectureRevise the Risk Assessment Clear View Training 2010 v2.644

2.9.9Construction - milestone Initial Operational Capability - conditions ofsatisfaction: The product is ready for beta testing in the userenvironment Clear View Training 2010 v2.645

2.9.10TransitionDRequirements – not applicableInception ElaborationConstructionITTransitionAnalysis – not applicableFocusDesign – modify the design if problems emergein beta testingImplementation – tailor the software for theuser site. Fix bugs uncovered in beta testingTest – perform beta testing and acceptancetesting at the user siteGoalsCorrect defectsPrepare the user site for the new software and tailor the software to operate at the user siteModify software if unforeseen problems ariseCreate user manuals and other documentationProvide customer consultancyConduct post project review Clear View Training 2010 v2.646

2.9.12Transition – milestone Product Release - conditions of satisfaction: Beta testing, acceptance testing and defect repairare finishedThe product is released into the user community Clear View Training 2010 v2.647

2.10Summary UP is a risk and use case driven, architecture centric, iterative andincremental software development processUP has four phases: InceptionElaborationConstructionTransitionEach iteration has five core workflows: RequirementsAnalysisDesignImplementationTest Clear View Training 2010 v2.648

Requirements - introduction Clear View Training 2010 v2.649

3.2Requirements - purpose The purpose of therequirements workflow is tocreate a high-levelspecification of what shouldbe implementedWe interview thestakeholders to find outwhat they need the systemto do for them – theirrequirementsInceptionElaboration Clear View Training 2010 v2.6ConstructionTransition50

3.3Requirements - icationpackageanchoriconUse casemodelP1P2P3use caseactor Clear View Training 2010 v2.651

3.4Requirements - workflowFind actors and use casesSystem AnalystArchitectUse case specifierUser interface designerStructure the use case modelPrioritise use casesDetail a use casePrototype user interface Clear View Training 2010 v2.652

3.4We add find functional requirementsRequirements Engineerfind non-functional requirementstrace requirements to use casesArchitect prioritise requirementsIn order to adopt a rigorous approach to requirements weneed to extend the basic UP workflow with functional andnon-functional requirements elicitation and requirementstraceability Clear View Training 2010 v2.653

3.5The importance of requirementsProject FailuresIncomplete requirements are the primaryreason that projects fail!IncompleterequirementsLack of userinvolvementLack of resourcesUnrealisticexpectationsLack of executivesupportChangingrequirementsLack of planningDidn't need it anylongerThe Standish Group, "The CHAOS Report (1994) " Clear View Training 2010 v2.654

3.6What are requirements? Requirements - “A specification of what should beimplemented”: In UP we create a Software Requirements Specification (SRS) What behaviour the system should offerA specific property of the systemA constraint on the systemThe beginning of the OO software construction process it is a statementof the system requirements for all stakeholdersOrganises related requirements into sectionsThe SRS consists of: Requirements model comprising functional and non-functionalrequirementsUse case model comprising actors and use cases Clear View Training 2010 v2.655

3.6.2Writing requirements id The system shall function unique identifiername of systemkeywordfunction to be performede.g. "32 The ATM system shall validate the PIN number." There is no UML standard way of writing requirements! Functional Requirements - what the system should do We recommend the uniform sentence structure above"The ATM system shall provide a facility for authenticating the identity ofa system user"Non-functional Requirements - a constraint on how thefunctional requirements are implemented "The ATM system shall authenticate a customer in four seconds or less" Clear View Training 2010 v2.656

3.7The map is not the territory Everyone filters information to create theirown particular model of the world. NoamChomsky described this as three processes: these filters areappliedautomaticallyandunconsciously Deletion – information is filtered outDistortion – information is modified by the relatedmechanisms of creation and hallucinationGeneralisation –the creation of rules, beliefs andprinciples about truth and falsehoodThese filters shape natural language and sowe may need to work to recover filteredinformation Clear View Training 2010 v2.657

3.8Summary We have seen how to capture: Functional requirementsNon-functional requirementsWe have had a brief overview of the threefilters which people use to construct theirmodel of the world Clear View Training 2010 v2.658

Requirements –use case modelling Clear View Training 2010 v2.659

4.2Use case modelling Use case modelling is a form of requirementsengineeringUse case modelling proceeds as follows: Find the system boundaryFind actorsFind use cases Use case specificationScenariosIt lets us identify the system boundary, who or whatuses the system, and what functions the systemshould offer Clear View Training 2010 v2.660

4.3Find actors and use casesBusiness model[or domain model]SystemanalystRequirementsmodelFind actors anduse casesUse case model[outlined]ProjectglossaryFeature list Clear View Training 2010 v2.661

4.3.1The subject Before we can build anything, we need toknow: Where the boundary of the system liesWho or what uses the systemWhat functions the system should offer to its userssubjectSystemNameWe create a Use Case model containing: Subject – the edge of the system also known as the system boundaryActors – who or what uses the systemUse Cases – things actors do with the systemRelationships - between actors and use cases Clear View Training 2010 v2.662

4.3.2What are actors? An actor is anything that interacts directly withthe system Actors identify who or what uses the system and soindicate where the system boundary liesActors are external to the systemAn Actor specifies a role that some externalentity adopts when interacting with the system«actor»CustomerCustomer Clear View Training 2010 v2.663

4.3.2.1Identifying Actors When identifying actors ask: Who or what uses the system?What roles do they play in the interaction?Who installs the system?Who starts and shuts down the system?Who maintains the system?What other systems use this system?Who gets and provides information to the system?Does anything happen at a fixed time?Time Clear View Training 2010 v2.664

4.3.3What are use cases? A use case is something an actor needs the system to do. It isa “case of use” of the system by a specific actorUse cases are always started by an actor The primary actor triggers the use caseZero or more secondary actors interact with the use case in some wayUse cases are always written from the point of view of theactorsPlaceOrderGetStatusOnOrder Clear View Training 2010 v2.665

4.3.3.1Identifying use cases Start with the list of actors that interact with thesystemWhen identifying use cases ask: What functions will a specific actor want from the system?Does the system store and retrieve information? If so, whichactors trigger this behaviour?What happens when the system changes state (e.g. systemstart and stop)? Are any actors notified?Are there any external events that affect the system? Whatnotifies the system about those events?Does the system interact with any external system?Does the system generate any reports? Clear View Training 2010 v2.666

4.3.3.2The use case diagramMail Order System use case diagramMail Order Systemcommunicationrelationshipsubject namesystem mpanyCustomeractorCheckOrderStatusSendCatalogueuse case Clear View Training 2010 v2.6Dispatcher67

4.3.4The Project Glossary Project GlossaryTerm1Term2Term3 msDefinitionSynonymsHomonyms In any business domain there isalways a certain amount of jargon.It’s important to capture the languageof the domain in a project glossaryThe aim of the glossary is to definekey terms and to resolve synonymsand homonymsYou are building a vocabulary thatyou can use to discuss the systemwith the stakeholders Clear View Training 2010 v2.668

4.4Detail a use caseUse case model[outlined]Use case specifierSupplementaryrequirementsDetail ause caseUse case[detailed]Glossary Clear View Training 2010 v2.669

4.5Use case specificationUse case: PaySalesTaxuse case nameuse case identifierID: 1brief descriptionBrief description:Pay Sales Tax to the Tax Authority at the end of the business quarter.the actors involved in theuse casePrimary actors:TimeSecondary actors:TaxAuthoritythe system state beforethe use case can beginPreconditions:1. It is the end of the business quarter.Main flow:the actual steps of the usecaseimplicit time actor1. The use case starts when it is the end of the business quarter.2. The system determines the amount of Sales Tax owed to the TaxAuthority.3. The system sends an electronic payment to the Tax Authority.the system state when theuse case has finishedPostconditions:1. The Tax Authority receives the correct amount of Sales Tax.alternative flowsAlternative flows:None. Clear View Training 2010 v2.670

Naming use cases Use cases describe something that happensThey are named using verbs or verb phrasesNaming standard 1: use cases are named usingUpperCamelCase e.g. PaySalesTax1 UML 2 does not specify any naming standards.All naming standards are our own, based on industry best practice. Clear View Training 2010 v2.671

4.5.5Pre and postconditions Preconditions and postconditionsare constraintsPreconditions constrain the stateof the system before the usecase can startPostconditions constrain the stateof the system after the use casehas executedIf there are no preconditions orpostconditions write "None"under the headingUse case: PlaceOrderPreconditions:1. A valid user has logged on to thesystemPostconditions:1. The order has been markedconfirmed and is saved by the system Clear View Training 2010 v2.672

4.5.6Main flow number The something some action The flow of events lists the steps in a use caseIt always begins by an actor doing something The flow of events should be a sequence of short steps that are: A good way to start a flow of events is:1) The use case starts when an actor function DeclarativeNumbered,Time orderedThe main flow is always the happy day or perfect world scenario Everything goes as expected and desired, and there are no errors,deviations, interrupts, or branchesAlternatives can be shown by branching or by listing under Alternativeflows (see later) Clear View Training 2010 v2.673

4.5.6.2Branching within a flow: If Use the keyword if toindicate alternatives withinthe flow of events There must be a Booleanexpression immediatelyafter ifUse indentation andnumbering to indicate theconditional part of the flowUse else to indicate whathappens if the condition isfalse (see next slide)Use case: ManageBasketID: 2Brief description:The Customer changes the quantity of an item in the basket.Primary actors:CustomerSecondary actors:None.Preconditions:1. The shopping basket contents are visible.Main flow:1. The use case starts when the Customer selects an item in thebasket.2. If the Customer selects "delete item"2.1 The system removes the item from the basket.3. If the Customer types in a new quantity3.1 The system updates the quantity of the item in the basket.Postconditions:None.Alternative flows:None. Clear View Training 2010 v2.674

4.5.6.4Repetition within a flow: For We can use thekeyword For toindicate the start of arepetition within theflow of eventsThe iterationexpressionimmediately after theFor statementindicates the numberof repetitions of theindented textbeneath the Forstatement.Use case: FindProductID: 3Brief description:The system finds some products based on Customer search criteria anddisplays them to the Customer.Actors:CustomerPreconditions:None.Main flow:1. The use case starts when the Customer selects "find product".2. The system asks the Customer for search criteria.3. The Customer enters the requested criteria.4. The system searches for products that match the Customer's criteria.5. For each product found5.1. The system displays a thumbnail sketch of the product.5.2. The system displays a summary of the product details.5.3. The system displays the product price.Postconditions:None.Alternative flows:NoProductsFound Clear View Training 2010 v2.675

4.5.6.5Repetition within a flow: While We can use thekeyword while toindicate thatsomethingrepeats whilesome Booleancondition is trueUse case: ShowCompanyDetailsID: 4Brief description:The system displays the company details to the Customer.Primary actors:CustomerSecondary actors:NonePreconditions:None.Main flow:1. The use case starts when the Customer selects "show company details".2. The system displays a web page showing the company details.3. While the Customer is browsing the company details4. The system searches for products that match the Customer's criteria.4.1. The system plays some background music.4.2. The system displays special offers in a banner ad.Postconditions:1. The system has displayed the company details.2. The system has played some background music.3. The systems has displayed special offers.Alternative flows:None. Clear View Training 2010 v2.676

4.5.7Branching: Alternative flows We may s

The Unified Software Development Process is an industry standard software engineering process It is commonly referred to as the "Unified Process" or UP It is the generic process for the UML It is free - described in "The Unified Software Development Process", ISBN:0201571692" UP is: Use case (requirements) driven Risk driven