Adressing nonfunctional requirements with agile practices
2 likes3,280 views
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.
More Related Content
What's hot (20)
Viewers also liked (11)
Similar to Adressing nonfunctional requirements with agile practices (20)
Recently uploaded (20)
Adressing nonfunctional requirements with agile practices
- 1. Addressing Nonfunctional Requirements Version May 16th Mario Cardinal Agile Coach & Software Architect www.mariocardinal.com
- 2. • Agile Coach & Software architect • Leading independent consultant • www.mariocardinal.com Who am I ?
- 3. "The real voyage of discovery consists, not in seeking new landscapes, but in having new eyes.” Marcel Proust A. Nonfunctional requirements – External and internal quality B. Functional requirements and agile framework C. Nonfunctional requirements and agile framework Why are we here? Agenda
- 4. Addressing Nonfunctional Requirements Section A Nonfunctional requirements
- 5. Nonfunctional Requirements What are they? • Specify"howwell"the"what"mustbehave • Notaboutnewfeaturestodeliver,butratheraboutdesirable characteristicsofexistingfeatures • Setconstraintsthattypicallycutacrossfunctional requirements • Alsoknownas"technicalrequirements",“quality attributes”or"qualityofservicerequirements“
- 6. Nonfunctional Requirements It is all about quality Canbedividedintotwomaincategories: 1. Externalqualitysuchasperformance,correctness,security andusability,whichcarryoutthesoftware'sfunctionsat runtime,andassuch,isnotonlyvisiblebystakeholdersbut alsohighlydesirable 2. Internalqualitysuchasmaintainability,modifiabilityand testability,whichisbarelyvisiblebystakeholdersbut simplifyhowtobuildthesoftware
- 7. Nonfunctional Requirements Knowledge is not experience • Idonotintendtotellyouhowtosatisfythemany nonfunctionalrequirements • Itisaskillthatoneacquireswithexperience
- 8. Nonfunctional Requirements I aim for a simpler goal • IwillexplainhowtotranslateNonfunctional requirementsintorestrictions • Restrictionssetalimittocomplywith • Restrictionsguideyourwork • Restrictionshelpdeterminewhetheryouhavesatisfiedthe nonfunctionalrequirements
- 9. Nonfunctional Requirements Need to review functional requirements • Constraintsweavethroughthefunctional requirements
- 10. Addressing Nonfunctional Requirements Section B Functional requirements and agile framework
- 11. Functional Requirements Express desirements with user stories • Auserstoryisashortdescriptionwrittenineveryday languagethatrepresentsadiscretepieceof demonstrablefunctionality • Itisadesirableoutcomebystakeholders • Classictemplate • “Asa<role>,Iwant<goal>sothat<benefit>”
- 12. Functional Requirements Example: User stories for a TransitAuthority • Asa<student>,Iwant<tobuyapassvalidonlyon schooldays>sothatIcan<gotoschool> • Asa<worker>,Iwant<tobuyamonthlypass>sothat Ican<gotowork>
- 13. • Ascenarioisaconcreteexamplewrittenineveryday language • Itdescribesasignificantexercisethatisrequiredforthe fulfillmentofauserstory Functional Requirements Illustrate User Story with scenarios Action Precondition Consequence describes the current state of the system describes a transition or stimulus to that system describes the resulting state of the system
- 14. Functional Requirements Confirm success criteria with scenarios • Scenariosestablishtheconditionsofacceptation • Scenariosareconcreteexamplesthatsaysinthewords ofthestakeholdershowtheyplantoverifythe desirableoutcome • Scenariosenablestheteamtoknowwhentheyare done • Scenariosareaspecificationasimportant,ifnotmore important,thanstories
- 15. Functional Requirements Express scenarios with formality Givenoneprecondition Andanotherprecondition Andyetanotherprecondition Whenanactionoccurs Thenaconsequence Andanotherconsequence
- 16. Functional Requirements Express scenarios with formality Givenanemptyshoppingcartiscreated Andamonthlystudentpassisaddedtoshoppingcart Whenbuyercheckouttheshoppingcart Thena76dollarssaleoccurred
- 17. Addressing Nonfunctional Requirements Section C Nonfunctional requirements and agile framework
- 18. Nonfunctional Requirements Two categories of constraint • Externalquality • Restrictionsimposeconditionsthatsetsalimittocomply duringsoftwareexecution • Internalquality • Practicesensurethatthesoftwareconstructionisdone correctly
- 19. External Quality What is it? Nonfunctional Requirement Definition Correctness 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 is measured as a response time or a throughput. Reliability Ability with which the software performs its required functions under stated conditions 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 graceful manner. Security Degree to which the software protects against threats. Usability Ease with which the software can be used by specific users to achieve specific goals.
- 20. External Quality Restrictions should be SMART • Specific • Itshouldtargetapieceoffunctionalitythatissmall,consistentandsimple • Measurable • Itimposesalimitthatismeasurable,otherwisehowwouldyouknow whenyou’veaddressedit • Attainable • Itisrecognizedasachievablebytheteam • Relevant • Itisdirectlyrelated,connected,andpertinenttothenonfunctional requirement • Traceable • Itislinkedwitharequirementandatargetthatjustifieswhyitexists
- 21. Restriction The most important element is the ‘measure’ • Easiertoimposeifyou • Reducethescaleofwhatneedstobemeasured • Reducefunctionalscope
- 22. Restriction Reduce the functional scope to a scenario • Arestrictionisaddressedsidebysidewithitslinked functionalscope
- 23. Nonfunctional Requirements What about User Story? • Cannotbesatisfiedinafiniteperiodoftime • The“what”thatneedstoberestrictedisnotconcrete enough • Thefunctionalscopeisfuzzybecauseitisaniteration • Caneasilyinducetechnicaldebt • Oncethestoryiscompleted,youmustputitbackinthe backlogtomakeitavailableagainforafutureiteration • Complicatesthemanagementofthebacklogunduly
- 24. Restriction Reduce the functional scope to a scenario • Linkingrestrictionswithscenariosisaprocessed repeatedstoryafterstory
- 25. Restriction Set Explicit Quality Objectives
- 26. Restriction Set restrictions with formality Givenoneprecondition Andanotherprecondition Andyetanotherprecondition Restrictafterxoccurrencewithameasurablequality objective Thenaconsequence Andanotherconsequence
- 27. Restriction Set expectations with formality Restrictwithresponsetimelessthan5seconds
- 28. Restriction Set positive expectations (Happy path) Giventhebuyerisuser‘KnownBuyer’ Restrictwiththebuyertobeauthenticatedpositively
- 30. External Quality Test Restrictions with Proven Practices • Accessibility:Verifyvisualimpairments,mobilitydifficulty,hearing inabilityandcognitivedisabilities • Correctness:Determineifthesoftwarerespectsthespecification (Acceptancetesting) • Performance:Measureresponsetimeandinspectthroughput • Reliability:Seekforextraordinaryresourceconsumptionovera specifiedperiodoftime(memory,CPU,diskspace)
- 31. External Quality Test Restrictions with Proven Practices • Robustness:Determineabilityofthesoftwaretofunction correctlyinthepresenceofinvalidinputsorstressful environmentalconditions • Scalability:Verifysoftwarebehaviorunderbothnormaland anticipatedpeakloadconditions(Loadtesting) • Security:Performintrusiondetectionandvulnerabilityscanning • Usability:Conductheuristicevaluation,consistencyinspection andactivityanalysistoverifyifusersachievespecifiedgoals
- 32. External Quality Less is more • Negotiatewithstakeholderstoreducenumberof restrictions • Isit«really,really»adesirableoutcome? • Trytotargetaspecificiterationfortestinga nonfunctionalrequirement • Benefit:Transformfromarecurrentconcerntoaone-time concern
- 33. • Reduce the scope of requirements – User Story – Scenario • Start expressing Restriction – Add restrictions as success criteria Next Steps What should you do tomorrow?
Editor's Notes
- #10: 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
- #12: 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
- #13: 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
- #15: 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
- #16: Given-When-Thenis the Gherkin langage promote by Behavior-DrivenDevelopment (BDD)Widelypromote by the Ruby community (Rspec and Cucumber)
- #20: Slide to announce last two sections
- #21: carry out the software's functions at run time, and as such, are not only visible by stakeholders but also highly desirable
- #23: 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
- #24: 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
- #25: Slide to restart discussingNonfunctionalrequirements
- #26: 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
- #27: 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
- #28: 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
- #29: 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
- #30: 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
- #31: 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
- #32: Robustness: Client-server architecture remove the server, does the client code copes gracefully with errors during execution?
- #33: Robustness: Client-server architecture remove the server, does the client code copes gracefully with errors during execution?
- #34: Bewarethattoomany restrictions caneasilyspoil the success of an iteration