requirements development and management-3

8/7/2019 Requirements Development and Management-3

1/28

5 2006 1

Requirements DevelopmentRequirements Development

and Managementand Management[RD[RD--REQM Process ImplementationREQM Process Implementation 33]]

..

Authorized SCAMPI Lead AppraiserAuthorized SCAMPI Lead Appraiser

Authorized SCAMPI B&C Team LeaderAuthorized SCAMPI B&C Team Leader

[email protected]@ku.ac.th


2/28

5 2006 . - 2

www.bsthome.com/out/thayanan/minimsewww.bsthome.com/out/thayanan/minimse

Applying UML andPatternsApplying UML andPatterns::AnAnIntroductionto ObjectIntroductionto Object--OrientedAnalysisOrientedAnalysis

andDesignandIterative Development,andDesignandIterative Development,ThirdEdition, Craig Larmen,AddisonThirdEdition, Craig Larmen,AddisonWesley,Wesley, 20042004..

R

ationalR

oseR

ationalR

ose (for UML Modeling)(for UML Modeling)--


3/28

5 2006 . - 3

Iterative Development Process for ObjectIterative Development Process for Object--

Oriented SystemsOriented Systems -- the Unified Processthe Unified Process

Case StudyCase Study the NextGen POS Systemthe NextGen POS System


4/28

5 2006 . - 4

Iterative & EvolutionaryIterative & EvolutionaryDevelopment Life CycleDevelopment Life Cycle


5/28

5 2006 . - 5

Iterative feedback and adaptation leads towardsIterative feedback and adaptation leads towardsthe desired system. The requirements and designthe desired system. The requirements and design

instability lowers overtimeinstability lowers overtime


6/28

5 2006 . - 6

Benefits of Iterative DevelopmentBenefits of Iterative Development

LLess project failure, better productivity, and lower defectess project failure, better productivity, and lower defectrates; shown by research into iterative and evolutionaryrates; shown by research into iterative and evolutionarymethodsmethods

Early rather than late mitigation of high risks (technical,Early rather than late mitigation of high risks (technical,requirements, objectives, usability, and so forth)requirements, objectives, usability, and so forth)

Early visible progressEarly visible progress Early feedback, user engagement, and adaptation,Early feedback, user engagement, and adaptation,

leading to a refined systems that more closely meets theleading to a refined systems that more closely meets thereal needs of the stakeholdersreal needs of the stakeholders

Managed complexity; the team is not overwhelmedbyManaged complexity; the team is not overwhelmedbyanalysis paralysis or very long and complex stepsanalysis paralysis or very long and complex steps

The learning within an iteration can be methodicallyThe learning within an iteration can be methodicallyused to improve the development process itself, iterationused to improve the development process itself, iterationby iteration.by iteration.


7/28

5 2006 . - 7

Manage your risks earlier the better.Manage your risks earlier the better.

If you dontactively attack therisks

The risks willactively attack you,

Tom Gilb


8/28

5 2006 . - 8

The Need for Feedback and AdaptationThe Need for Feedback and Adaptation

In complex, changing systemsIn complex, changing systems ((such as most softwaresuch as most softwareprojectsprojects)) feedback and adaptation are key ingredientsfeedback and adaptation are key ingredientsfor successfor success..

Feedback from early development, programmers tryingFeedback from early development, programmers tryingto read specifications, and client demos to refine theto read specifications, and client demos to refine therequirementsrequirements..

Feedback from tests and developers to refine the designFeedback from tests and developers to refine the designor modelsor models..

Feedback from the progress of the team tackling earlyFeedback from the progress of the team tackling early

features to refine the schedule and estimatesfeatures to refine the schedule and estimates..

Feedback from the client and marketplace to reFeedback from the client and marketplace to re--prioritizeprioritizethe features to tackle in the next iterationthe features to tackle in the next iteration..


9/28

5 2006 . - 9

Evolutionary analysis and designEvolutionary analysis and design-- the majority in early iterationsthe majority in early iterations


10/28

5 2006 . - 10

Other Critical UPBest PracticesOther Critical UPBest Practices

tackle hightackle high--risk andhighrisk andhigh--value issues in early iterationsvalue issues in early iterations continuously engage users for evaluation, feedback, andcontinuously engage users for evaluation, feedback, and

requirementsrequirements

build a cohesive, core architecture in early iterationsbuild a cohesive, core architecture in early iterations

continuously verify quality; test early, often, andcontinuously verify quality; test early, often, andrealisticallyrealistically

apply use cases where appropriateapply use cases where appropriate

do some visual modelingdo some visual modeling ((with the UMLwith the UML))

carefully manage requirementscarefully manage requirements practice change request and configuration managementpractice change request and configuration management


11/28

5 2006 . - 11

UPUP 44 Major PhasesMajor Phases

1.1. InceptionInception-- approximate vision, businessapproximate vision, businesscase, scope, vague estimates.case, scope, vague estimates.

2.2. ElaborationElaboration-- refined vision, iterativerefined vision, iterativeimplementation of the core architecture,implementation of the core architecture,

resolution ofhigh risks, identification of mostresolution ofhigh risks, identification of mostrequirements and scope, more realisticrequirements and scope, more realisticestimatesestimates..

3.3. ConstructionConstruction-- iterative implementation of theiterative implementation of theremaining lower risk and easier elements, andremaining lower risk and easier elements, andpreparation for deployment.preparation for deployment.

4.4. TransitionTransition-- beta tests, deploymentbeta tests, deployment..


12/28

5 2006 . - 12

UPPhasesUPPhases


13/28

5 2006 . - 13

UP DisciplinesUP Disciplines


14/28

5 2006 . - 14

UP Disciplines (partial)UP Disciplines (partial)

Business Modeling - The Domain Modelartifact, to visualize noteworthy concepts in theapplication domain.

Requirements- The Use-Case Model and

Supplementary Specification artifacts to capturefunctional and non-functional requirements.

Design - The Design Model artifact, to designthe software objects.


15/28

5 2006 . - 15

Relationship Between theRelationship Between theDisciplines and PhasesDisciplines and Phases


16/28

5 2006 . - 16

Sample Artifacts of Inception PhaseSample Artifacts of Inception Phase


17/28

5 2006 . - 17

Types & Categories of RequirementsTypes & Categories of Requirements

FURPS+ ModelFURPS+ Model

FunctionalFunctional features, capabilities, security.features, capabilities, security. UsabilityUsabilityhuman factors, help, documentationhuman factors, help, documentation..

ReliabilityReliabilityfrequency of failure, recoverability, predictability.frequency of failure, recoverability, predictability.

PerformancePerformance response times, throughput, accuracy, availability,response times, throughput, accuracy, availability,resource usageresource usage..

SupportabilitySupportabilityadaptability, maintainability, internationalization,adaptability, maintainability, internationalization,configurability.configurability.

The "+" in FURPS+ indicates ancillary and subThe "+" in FURPS+ indicates ancillary and sub--factors, such as:factors, such as:

ImplementationImplementationresource limitations, languages and tools,resource limitations, languages and tools,hardware,hardware, ......

InterfaceInterface constraints imposedby interfacing with external systems.constraints imposedby interfacing with external systems. OperationsOperationssystem management in its operational settingsystem management in its operational setting..

PackagingPackaging for example, a physical box.for example, a physical box.

LegalLegal licensing and so forthlicensing and so forth..


18/28

5 2006 . - 18

Key Artifacts [Inception Phase]Key Artifacts [Inception Phase]

UseUse--Case ModelCase ModelA

set of typical scenarios ofusing aA

set of typical scenarios ofusing asystem.There are primarily for functional (behavioral)system.There are primarily for functional (behavioral)requirements.requirements.

SupplementarySpecificationSupplementarySpecificationBasically, everythingBasically, everythingnot in the use casesnot in the use cases..This artifact is primarily for all nonThis artifact is primarily for all non--functional requirements, such as performance orfunctional requirements, such as performance or

licensinglicensing.. It is also the place to record functionalIt is also the place to record functionalfeaturesfeatures not expressednot expressed ((or expressibleor expressible)) as use cases; foras use cases; forexample, a report generationexample, a report generation..

GlossaryGlossary In its simplest form, the Glossary definesIn its simplest form, the Glossary definesnoteworthy terms. It also encompasses the concept ofnoteworthy terms. It also encompasses the concept of

thet

he data dictionarydata dictionary, w

hich

records requirements related, which

records requirements relatedto data, such as validation rules, acceptable values, andto data, such as validation rules, acceptable values, andso forth.The Glossary can detail any element: anso forth.The Glossary can detail any element: anattribute of an object, a parameter of an operation call,attribute of an object, a parameter of an operation call,a report layout, and so forth.a report layout, and so forth.


19/28

5 2006 . - 19

Key Artifacts [Inception Phase] (cont)Key Artifacts [Inception Phase] (cont)

VisionVisionSummarizes

highS

ummarizeshigh--level requirements t

hat arelevel requirements t

hat areelaborated in the Useelaborated in the Use--Case Model andSupplementaryCase Model andSupplementary

Specification, and summarizes the business case for theSpecification, and summarizes the business case for theprojectproject..A short executive overview document for quicklyA short executive overview document for quicklylearning the project's big ideaslearning the project's big ideas..

BusinessRulesBusinessRulesBusiness rules (also called DomainBusiness rules (also called Domain

Rules) typically describe requirements or policies thatRules) typically describe requirements or policies thattranscend one software projectthey are required in thetranscend one software projectthey are required in thedomain or business, and many applications may need todomain or business, and many applications may need toconform to them.An excellent example is governmentconform to them.An excellent example is governmenttax laws. Domain rule detailstax laws. Domain rule details maymay be recorded in thebe recorded in theSupplementary Specification, butbecause they areSupplementary Specification, butbecause they areusually more enduring and applicable than for oneusually more enduring and applicable than for onesoftware project, placing them in a central Businesssoftware project, placing them in a central BusinessRules artifact (sharedby all analysts of the company)Rules artifact (sharedby all analysts of the company)makes for better reuse of the analysis effort.makes for better reuse of the analysis effort.


20/28

5 2006 . - 20

Sample UP artifacts and timingSample UP artifacts and timing.. ss -- start; rstart; r -- refinerefine


21/28

5 2006 . - 21

Iterative Development Process for ObjectIterative Development Process for Object--

OrientedSystemsOrientedSystems -- the Unified Processthe Unified Process

Case StudyCase Study the NextGen POSSystemthe NextGen POSSystem


22/28

5 2006 . - 22

Case StudyCase Study The NextGen POSSystemThe NextGen POSSystem

A computerized application usedA computerized application used ((in partin part)) to record salesto record salesandhandle payments; it is typically used in a retail storeandhandle payments; it is typically used in a retail store..

It includes hardware components such as a computerIt includes hardware components such as a computerandbar code scanner, and software to run the systemandbar code scanner, and software to run the system..

It interfaces to various service applications, such

as aIt interfaces to various service applications, such

as athirdthird--party tax calculator and inventory controlparty tax calculator and inventory control..

These systems mustbe relatively faultThese systems mustbe relatively fault--tolerant; that is,tolerant; that is,even if remote services are temporarily unavailableeven if remote services are temporarily unavailable ((suchsuchas the inventory systemas the inventory system)), they must still be capable of, they must still be capable of

capturing sales andhandling at least cash paymentscapturing sales andhandling at least cash payments ((sosothat the business is not crippledthat the business is not crippled).).


23/28

5 2006 . - 23

Case StudyCase Study The NextGen POSSystemThe NextGen POSSystem

APOS system increasingly must support multiple andAPOS system increasingly must support multiple andvaried clientvaried client--side terminals and interfacesside terminals and interfaces..

These include a thinThese include a thin--client Webbrowser terminal, a regularclient Webbrowser terminal, a regularpersonal computer with something like a Java Swing graphicalpersonal computer with something like a Java Swing graphicaluser interface, touch screen input, wireless PDAs, and so forthuser interface, touch screen input, wireless PDAs, and so forth..

This commercial POS system that we will sell to differentThis commercial POS system that we will sell to differentclients withdisparate needs in terms ofbusiness ruleclients withdisparate needs in terms ofbusiness ruleprocessingprocessing..

Each client will desire a unique set of logic to execute at certainEach client will desire a unique set of logic to execute at certainpredictable points in scenarios ofusing the system, such aspredictable points in scenarios ofusing the system, such as

when a new sale is initiated or when a new line item is addedwhen a new sale is initiated or when a new line item is added..

Therefore, we will need a mechanism to provide thisTherefore, we will need a mechanism to provide thisflexibility and customizationflexibility and customization..


24/28

5 2006 . - 24

Actor, Scenario, Use CasesActor, Scenario, Use Casesfor specifying functional requirementsfor specifying functional requirements

AnAn actoractor is something withbehavior, such as ais something withbehavior, such as apersonperson ((identifiedby roleidentifiedby role)), computer system, or, computer system, ororganization; for example, a cashierorganization; for example, a cashier..

AA scenarioscenario is a specific sequence of actions andis a specific sequence of actions and

interactions between actors and the system; it isinteractions between actors and the system; it isalso called aalso called a use case instance.use case instance. It is oneIt is oneparticular story ofusing a system, or one pathparticular story ofusing a system, or one paththrough the use case; for example, the scenariothrough the use case; for example, the scenario

of successfully purchasing items with cash, orof successfully purchasing items with cash, orthe scenario of failing to purchase items becausethe scenario of failing to purchase items becauseof a credit paymentdenialof a credit paymentdenial..


25/28

5 2006 . - 25

Use Case ScenarioUse Case ScenarioInformally then, aInformally then, a use caseuse case is a collection of related success and failureis a collection of related success and failure

scenarios thatdescribe an actor using a system to support a goalscenarios thatdescribe an actor using a system to support a goal..For example, here is aFor example, here is a casual formatcasual formatuse case with alternateuse case with alternatescenariosscenarios::

Handle ReturnsHandle Returns

MainS

uccessS

cenarioMainS

uccessS

cenario::A

customer arrives at a checkout wit

hitems

Acustomer arrives at a c

heckout wit

hitemsto return.The cashier uses the POS system to record each returnedto return.The cashier uses the POS system to record each returned

item item

Alternate Scenarios:Alternate Scenarios:

If the customer paidby credit, and the reimbursement transactionIf the customer paidby credit, and the reimbursement transactionto their credit account is rejected, inform the customer and payto their credit account is rejected, inform the customer and pay

them with cashthem with cash.. If the item identifier is not found in the system, notify the CashierIf the item identifier is not found in the system, notify the Cashier

and suggest manual entry of the identifier codeand suggest manual entry of the identifier code ((perhaps it isperhaps it iscorruptedcorrupted).).

If the system detects failure to communicate with the externalIf the system detects failure to communicate with the externalaccounting system, accounting system,


26/28

5 2006 . - 26

Use Case DiagramUse Case Diagramfor specifying functional requirementsfor specifying functional requirements


27/28

5 2006 . - 27

Other RequirementsOther Requirements

TheThe SupplementarySpecificationSupplementarySpecification captures andcaptures andidentifies other kinds of requirements, such as reports,identifies other kinds of requirements, such as reports,documentation, packaging, supportability, licensing, anddocumentation, packaging, supportability, licensing, andso forthso forth..

TheThe GlossaryGlossarycaptures terms anddefinitions; it can alsocaptures terms anddefinitions; it can alsoplay the role of a data dictionaryplay the role of a data dictionary..

TheThe VisionVisionsummarizes thesummarizes the ""visionvision"" of the projectanof the projectanexecutive summaryexecutive summary.. It serves to tersely communicateIt serves to tersely communicatethe big ideasthe big ideas..

TheThe BusinessRules(BusinessRules(orDomainRulesorDomainRules)) capturecapturelonglong--living and spanning rules or policies, such as taxliving and spanning rules or policies, such as taxlaws, that transcend one particular applicationlaws, that transcend one particular application..


28/28

5 2006 . - 28

DraftSRS for the NextGen POS systemDraftSRS for the NextGen POS system

(( Refine theRefine thesystem definitionsystem definition)) SRSTemplate (SRSTemplate (Use Case)Use Case) ArtifactsArtifacts WorkflowWorkflow

Requirement Discipline (Requirement Discipline (Analyze the Problem,Analyze the Problem,UnderstandStakeholders Needs, Define the System,UnderstandStakeholders Needs, Define the System,Manage the Scope of the SystemManage the Scope of the System)) Vision (SectionVision (Section 77..66))

Use Case ModelUse Case Model

(Figure(Figure 66..33 + Section+ Section 66..88:Process Sale):Process Sale) Supplementary Specification (SectionSupplementary Specification (Section 77..44))

Glossary (SectionGlossary (Section 77..88))

Business Rule (SectionBusiness Rule (Section 77..1010))

Draft the SRSDraft the SRS

requirements development and management-3

Documents