Non functional requirements
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


Non functional requirements



Knowing of non-functional requirements helps you to avoid of customers say „You should thing better!“.

Knowing of non-functional requirements helps you to avoid of customers say „You should thing better!“.



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Non functional requirements Presentation Transcript

  • 1. Non Functional Requirements21.5.2010 - Pavel RůžičkaProduct Development Department
  • 2. Knowing of non-functionalrequirementsHelps to avoid of customers say„Y o u s h o u l d t h in g b e t t e r !“ 221.5.2010 - Pavel RůžičkaProduct Development Department
  • 3. I t helps a lot if you know what is the “most critical“ non-functional requirement because this can dominate the best choice of development technique and internal design. 3 21.5.2010 - Pavel Růžička Product Development Department
  • 4. 421.5.2010 - Pavel RůžičkaProduct Development Department
  • 5. Non-functional requirements areaspects• Users have implicit expectations about how well the software will work.• These characteristics include • how easy the software is to use, • how quickly it executes, • how reliable it is, • and how well it behaves when unexpected conditions arise.• The non-functional requirements define these aspects about the system. 521.5.2010 - Pavel RůžičkaProduct Development Department
  • 6. Non Fuctional Requirements -General • Security • Exception Handling • Validation • Logging • Tracing / Testing • Monitoring / Reliability • Transaction • Storage • GUI Binding • Configuration 621.5.2010 - Pavel RůžičkaProduct Development Department
  • 7. Non Fuctional Requirements–System / Dev • Naming conventions • Caching, Performance • Scalability • RAM usage • Thread Sync 7 21.5.2010 - Pavel Růžička Product Development Department
  • 8. Non Fuctional Requirements -Business • Time to market • Cost • Speed / Performance • Interoperability • Flexibility • Disaster recovery • Usability • Accessibility 821.5.2010 - Pavel RůžičkaProduct Development Department
  • 9. How to fetch non-functionalrequirements?• A n t i- s t o r ie s are things the user does not want to happen, commonly for safety or security reasons. • N o way we let an I L OV E Y OU E M ail worm in our System!• U s e a c h e c k lis t  9 21.5.2010 - Pavel Růžička Product Development Department
  • 10. Security- Should access to be limited?- Is an access list necessary? - Access Control List - White List - Black List 1021.5.2010 - Pavel RůžičkaProduct Development Department
  • 11. Exception handling- What errors can occur on runtime?- What it should do in case of error? 1121.5.2010 - Pavel RůžičkaProduct Development Department
  • 12. Validation• Which input items are required?• Which of them need to be validated?• What to do if input is invalid?• How to recognize if an item is valid? (email, personal number, ZIP code...)Be aware - customer tends to change it frequently! 1221.5.2010 - Pavel RůžičkaProduct Development Department
  • 13. Logging• It is about loggin from the user perspective, not developer’s logging• Which events should be logged?• Which items should log contain?• Is the last operation enough or you need history? • How deep the history should be?• Where to log? (file/db/…)• Who should have access to logs?• Incremental or rotation log?• How to purge/delete logs? 1321.5.2010 - Pavel RůžičkaProduct Development Department
  • 14. Tracing - testing• How to test an application?• Which parts of the application should traceable? 1421.5.2010 - Pavel RůžičkaProduct Development Department
  • 15. Monitoring - SLA• How it will be monitored?• Are there any special monitoring rules?• Use cases will help you best: • How to watch each particular use case? • What to watch/track there? (user/action/result) 1521.5.2010 - Pavel RůžičkaProduct Development Department
  • 16. Transaction• Which operation is „atomic“- what must be proceeded all at once?• How to do rollback/cancel an operation? 1621.5.2010 - Pavel RůžičkaProduct Development Department
  • 17. Naming conventionsName of a product/service and internal naming (Windows Chicago vs. Windows 2000)• E s t a b lis h in t e r n a l n a m in g c o n v e n t io n s – it w ill h e lp y o u t o a v o id o f t r o u b le s • in c a s e o f u n c le a r p r o d u c t n a m e • in c a s e o f c h a n g e t h e p u b lic produc t na me 1721.5.2010 - Pavel RůžičkaProduct Development Department
  • 18. Caching, performance• Think about scalability• What to cache• What must be strictly online • Prepare fallback scenario in case of outage 1821.5.2010 - Pavel RůžičkaProduct Development Department
  • 19. Sources••• 1921.5.2010 - Pavel RůžičkaProduct Development Department