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

1. Non Functional
Requirements
21.5.2010 - Pavel Růžička
Product Development Department

2. Knowing of non-functional
requirements
Helps to avoid of customers say
„Y o u s h o u l d t h in g
b e t t e r !“
2
21.5.2010 - Pavel Růžička
Product 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. 4
21.5.2010 - Pavel Růžička
Product Development Department

5. Non-functional requirements are
aspects
• 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.
5
21.5.2010 - Pavel Růžička
Product Development Department

6. Non Fuctional Requirements -
General
• Security
• Exception Handling
• Validation
• Logging
• Tracing / Testing
• Monitoring / Reliability
• Transaction
• Storage
• GUI Binding
• Configuration
6
21.5.2010 - Pavel Růžička
Product 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
8
21.5.2010 - Pavel Růžička
Product Development Department

9. How to fetch non-functional
requirements?
• 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
10
21.5.2010 - Pavel Růžička
Product Development Department

11. Exception handling
- What errors can occur on runtime?
- What it should do in case of error?
11
21.5.2010 - Pavel Růžička
Product 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!
12
21.5.2010 - Pavel Růžička
Product 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?
13
21.5.2010 - Pavel Růžička
Product Development Department

14. Tracing - testing
• How to test an application?
• Which parts of the application should traceable?
14
21.5.2010 - Pavel Růžička
Product 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)
15
21.5.2010 - Pavel Růžička
Product Development Department

16. Transaction
• Which operation is „atomic“- what must be proceeded all
at once?
• How to do rollback/cancel an operation?
16
21.5.2010 - Pavel Růžička
Product Development Department

17. Naming conventions
Name 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
17
21.5.2010 - Pavel Růžička
Product Development Department

18. Caching, performance
• Think about scalability
• What to cache
• What must be strictly online
• Prepare fallback scenario in case of outage
18
21.5.2010 - Pavel Růžička
Product Development Department

19. Sources
• http://en.wikipedia.org/wiki/Non-functional_requirement
• http://broadcast.oreilly.com/2010/02/nonfunctional-requiremen
• http://www.stellman-greene.com/2010/02/17/nonfunctional-req
19
21.5.2010 - Pavel Růžička
Product Development Department