Adressing nonfunctional requirements with agile practices

2,502 views

Published on

A recurring challenge with agile practices is how to address non-functional requirements. A non-functional requirement specifies "how well" the "what" must behave. They focus on characteristics such as security, maintainability, availability and performance that typically cut across functional requirements. Improperly dealing with nonfunctional requirements leads to the source code difficult to evolve or software with an unpleasant execution quality. During this session, you will learn how to specify these recurring concerns using self-contained constraints that can be satisfied iteration after iteration, in a finite period of time. Overall, you will acquire a different perspective on how to connect requirements and architecture using agile practices.

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,502
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
4
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Constraintis self-contained and shouldbe satisfied in a finite period of timeIntroduce the next section “Functional requirement” by explaining that you will explain in more detail what are User Story and Scenario
  • Master complexity by addressing goals. They are engaging; they enable conversations about how to create valueIt is a placeholder containing just enough information so that the stakeholders can prioritize it and the team can produce a reasonable estimate of the effort to implement it.Quick way of documenting a stakeholder’s desirable outcome without having to elaborate vast formalized requirement documentsEncourage the team to defer collecting detailsAn initial high level story can be written as a first cut and then split into more stories when the team successively refines the software and it becomes important to have the details
  • Role: Student, goal: buy a pass valid only on school days, benefit: go to schoolRole: Worker, goal: buy a monthly pass, benefit: go to work
  • Success criteria convey additional information about the storyThey are a specification as important, if not more important, than the storyThey are a key element of agile specifications
  • Given-When-Thenis the Gherkin langage promote by Behavior-DrivenDevelopment (BDD)Widelypromote by the Ruby community (Rspec and Cucumber)
  • Slide to announce last two sections
  • carry out the software's functions at run time, and as such, are not only visible by stakeholders but also highly desirable
  • Constraintis self-contained and shouldbe satisfied in a finite period of timeIntroduce the next section “Functional requirement” by explaining that you will explain in more detail what are User Story and Scenario
  • Constraintis self-contained and shouldbe satisfied in a finite period of timeIntroduce the next section “Functional requirement” by explaining that you will explain in more detail what are User Story and Scenario
  • Slide to restart discussingNonfunctionalrequirements
  • Constraintis self-contained and shouldbe satisfied in a finite period of timeIntroduce the next section “Functional requirement” by explaining that you will explain in more detail what are User Story and Scenario
  • Constraintis self-contained and shouldbe satisfied in a finite period of timeIntroduce the next section “Functional requirement” by explaining that you will explain in more detail what are User Story and Scenario
  • Constraintis self-contained and shouldbe satisfied in a finite period of timeIntroduce the next section “Functional requirement” by explaining that you will explain in more detail what are User Story and Scenario
  • Constraintis self-contained and shouldbe satisfied in a finite period of timeIntroduce the next section “Functional requirement” by explaining that you will explain in more detail what are User Story and Scenario
  • Constraintis self-contained and shouldbe satisfied in a finite period of timeIntroduce the next section “Functional requirement” by explaining that you will explain in more detail what are User Story and Scenario
  • Constraintis self-contained and shouldbe satisfied in a finite period of timeIntroduce the next section “Functional requirement” by explaining that you will explain in more detail what are User Story and Scenario
  • Robustness: Client-server architecture  remove the server, does the client code copes gracefully with errors during execution?
  • Robustness: Client-server architecture  remove the server, does the client code copes gracefully with errors during execution?
  • Bewarethattoomany restrictions caneasilyspoil the success of an iteration
  • Adressing nonfunctional requirements with agile practices

    1. 1. AddressingNonfunctional RequirementsVersion May 16thMario CardinalAgile Coach & Software Architectwww.mariocardinal.com
    2. 2. • Agile Coach & Software architect• Leading independent consultant• www.mariocardinal.comWho am I ?
    3. 3. "The real voyage of discovery consists, not in seeking new landscapes, but inhaving new eyes.”Marcel ProustA. Nonfunctional requirements– External and internal qualityB. Functional requirements and agileframeworkC. Nonfunctional requirements and agileframeworkWhy are we here?Agenda
    4. 4. Addressing NonfunctionalRequirementsSection ANonfunctional requirements
    5. 5. Nonfunctional RequirementsWhat are they?• Specify"howwell"the"what"mustbehave• Notaboutnewfeaturestodeliver,butratheraboutdesirablecharacteristicsofexistingfeatures• Setconstraintsthattypicallycutacrossfunctionalrequirements• Alsoknownas"technicalrequirements",“qualityattributes”or"qualityofservicerequirements“
    6. 6. Nonfunctional RequirementsIt is all about qualityCanbedividedintotwomaincategories:1. Externalqualitysuchasperformance,correctness,securityandusability,whichcarryoutthesoftwaresfunctionsatruntime,andassuch,isnotonlyvisiblebystakeholdersbutalsohighlydesirable2. Internalqualitysuchasmaintainability,modifiabilityandtestability,whichisbarelyvisiblebystakeholdersbutsimplifyhowtobuildthesoftware
    7. 7. Nonfunctional RequirementsKnowledge is not experience• Idonotintendtotellyouhowtosatisfythemanynonfunctionalrequirements• Itisaskillthatoneacquireswithexperience
    8. 8. Nonfunctional RequirementsI aim for a simpler goal• IwillexplainhowtotranslateNonfunctionalrequirementsintorestrictions• Restrictionssetalimittocomplywith• Restrictionsguideyourwork• Restrictionshelpdeterminewhetheryouhavesatisfiedthenonfunctionalrequirements
    9. 9. Nonfunctional RequirementsNeed to review functional requirements• Constraintsweavethroughthefunctionalrequirements
    10. 10. Addressing NonfunctionalRequirementsSection BFunctional requirementsandagile framework
    11. 11. Functional RequirementsExpress desirements with user stories• Auserstoryisashortdescriptionwrittenineverydaylanguagethatrepresentsadiscretepieceofdemonstrablefunctionality• Itisadesirableoutcomebystakeholders• Classictemplate• “Asa<role>,Iwant<goal>sothat<benefit>”
    12. 12. Functional RequirementsExample: User stories for a TransitAuthority• Asa<student>,Iwant<tobuyapassvalidonlyonschooldays>sothatIcan<gotoschool>• Asa<worker>,Iwant<tobuyamonthlypass>sothatIcan<gotowork>
    13. 13. • Ascenarioisaconcreteexamplewrittenineverydaylanguage• ItdescribesasignificantexercisethatisrequiredforthefulfillmentofauserstoryFunctional RequirementsIllustrate User Story with scenariosActionPreconditionConsequencedescribes the current state of the systemdescribes a transition or stimulus to that systemdescribes the resulting state of the system
    14. 14. Functional RequirementsConfirm success criteria with scenarios• Scenariosestablishtheconditionsofacceptation• Scenariosareconcreteexamplesthatsaysinthewordsofthestakeholdershowtheyplantoverifythedesirableoutcome• Scenariosenablestheteamtoknowwhentheyaredone• Scenariosareaspecificationasimportant,ifnotmoreimportant,thanstories
    15. 15. Functional RequirementsExpress scenarios with formalityGivenonepreconditionAndanotherpreconditionAndyetanotherpreconditionWhenanactionoccursThenaconsequenceAndanotherconsequence
    16. 16. Functional RequirementsExpress scenarios with formalityGivenanemptyshoppingcartiscreatedAndamonthlystudentpassisaddedtoshoppingcartWhenbuyercheckouttheshoppingcartThena76dollarssaleoccurred
    17. 17. Addressing NonfunctionalRequirementsSection CNonfunctional requirementsandagile framework
    18. 18. Nonfunctional RequirementsTwo categories of constraint• Externalquality• Restrictionsimposeconditionsthatsetsalimittocomplyduringsoftwareexecution• Internalquality• Practicesensurethatthesoftwareconstructionisdonecorrectly
    19. 19. External QualityWhat is it?NonfunctionalRequirementDefinitionCorrectness Ability with which the software respects the specification.Performance Ease with which the software is doing the work it is supposed to do. Usually it ismeasured as a response time or a throughput.Reliability Ability with which the software performs its required functions under statedconditions for a specified period of time.Robustness Ability with which the software copes with errors during execution.Scalability Ability with which the software handles growing amounts of work in a gracefulmanner.Security Degree to which the software protects against threats.Usability Ease with which the software can be used by specific users to achieve specificgoals.
    20. 20. External QualityRestrictions should be SMART• Specific• Itshouldtargetapieceoffunctionalitythatissmall,consistentandsimple• Measurable• Itimposesalimitthatismeasurable,otherwisehowwouldyouknowwhenyou’veaddressedit• Attainable• Itisrecognizedasachievablebytheteam• Relevant• Itisdirectlyrelated,connected,andpertinenttothenonfunctionalrequirement• Traceable• Itislinkedwitharequirementandatargetthatjustifieswhyitexists
    21. 21. RestrictionThe most important element is the ‘measure’• Easiertoimposeifyou• Reducethescaleofwhatneedstobemeasured• Reducefunctionalscope
    22. 22. RestrictionReduce the functional scope to a scenario• Arestrictionisaddressedsidebysidewithitslinkedfunctionalscope
    23. 23. Nonfunctional RequirementsWhat about User Story?• Cannotbesatisfiedinafiniteperiodoftime• The“what”thatneedstoberestrictedisnotconcreteenough• Thefunctionalscopeisfuzzybecauseitisaniteration• Caneasilyinducetechnicaldebt• Oncethestoryiscompleted,youmustputitbackinthebacklogtomakeitavailableagainforafutureiteration• Complicatesthemanagementofthebacklogunduly
    24. 24. RestrictionReduce the functional scope to a scenario• Linkingrestrictionswithscenariosisaprocessedrepeatedstoryafterstory
    25. 25. RestrictionSet Explicit Quality Objectives
    26. 26. RestrictionSet restrictions with formalityGivenonepreconditionAndanotherpreconditionAndyetanotherpreconditionRestrictafterxoccurrencewithameasurablequalityobjectiveThenaconsequenceAndanotherconsequence
    27. 27. RestrictionSet expectations with formalityRestrictwithresponsetimelessthan5seconds
    28. 28. RestrictionSet positive expectations (Happy path)Giventhebuyerisuser‘KnownBuyer’Restrictwiththebuyertobeauthenticatedpositively
    29. 29. RestrictionSet negative expectationsGiventhebuyerisuser‘UnknownBuyer’RestrictwiththebuyertobeauthenticatednegativelyThenissueissavedinsecuritydatabaseanduserisredirectedto“Login”page
    30. 30. External QualityTest Restrictions with Proven Practices• Accessibility:Verifyvisualimpairments,mobilitydifficulty,hearinginabilityandcognitivedisabilities• Correctness:Determineifthesoftwarerespectsthespecification(Acceptancetesting)• Performance:Measureresponsetimeandinspectthroughput• Reliability:Seekforextraordinaryresourceconsumptionoveraspecifiedperiodoftime(memory,CPU,diskspace)
    31. 31. External QualityTest Restrictions with Proven Practices• Robustness:Determineabilityofthesoftwaretofunctioncorrectlyinthepresenceofinvalidinputsorstressfulenvironmentalconditions• Scalability:Verifysoftwarebehaviorunderbothnormalandanticipatedpeakloadconditions(Loadtesting)• Security:Performintrusiondetectionandvulnerabilityscanning• Usability:Conductheuristicevaluation,consistencyinspectionandactivityanalysistoverifyifusersachievespecifiedgoals
    32. 32. External QualityLess is more• Negotiatewithstakeholderstoreducenumberofrestrictions• Isit«really,really»adesirableoutcome?• Trytotargetaspecificiterationfortestinganonfunctionalrequirement• Benefit:Transformfromarecurrentconcerntoaone-timeconcern
    33. 33. • Reduce the scope of requirements– User Story– Scenario• Start expressing Restriction– Add restrictions as success criteriaNext StepsWhat should you do tomorrow?

    ×