Other Requirements

1. Other Requirements http://flic.kr/p/5i4Bo5

2. What are you goingto learn about today? • How to capture non-functional requirements • More UP requirements artifacts http://flic.kr/p/8JpkTg

3. Recall: Iterative development process We are here http://en.wikipedia.org/wiki/File:Iterative_development_model_V2.jpg

4. Recall: FURPS+ Classification of Requirements • Functional: features, capabilities, security • Usability: human factors, help, documentation • Reliability: frequency of failure, recoverability, predictability • Performance: response times, throughput, accuracy, availability, resource usage • Supportability: adaptability, maintainability, internationalization, configurability

5. Use cases are good for capturing… But what about these non-functional requirements? Functional: features, capabilities, security\ Usability: human factors, help, documentation Reliability: frequency of failure, recoverability, predictability Performance: response times, throughput, accuracy, availability, resource usage Supportability: adaptability, maintainability, internationalization, configurability

6. Supplementary specification • Catch-all for things that don’t fit well in UCs • Structural elements: • Functionality (that didn’t fit in UCs) • Usability • Reliability • Performance • Supportability • Implementation constraints • Application-specific domain rules

7. POS Example: Functionality • Logging and error handling • Log all errors to persistent storage. • Pluggable rules • At various scenario points of several UCs support the ability to customize the functionality of the system… • Security • All usage requires user authentication Why are UCs less than ideal for capturing these requirements? http://flic.kr/p/9ksxQa

8. POS Example: Usability • Human factors • The customer will be able to see a large-monitor display of the POS. Therefore: • Text should be easily visible from 1 meter. • Avoid colors associated with common forms of color blindness. • Speed, ease, and error-free processing are paramount in sales processing, as the buyer wishes to leave quickly. • The cashier is often looking at the customer, so signals should be conveyed with sound. Can you think of some guidelines for writing usability specifications? http://flic.kr/p/9ksxQa

9. POS Example: Usability Be precise • Human factors • The customer will be able to see a large-monitor display of the POS. Therefore: • Text should be easily visible from 1 meter. • Avoid colors associated with common forms of color blindness. • Speed, ease, and error-free processing are paramount in sales processing, as the buyer wishes to leave quickly. • The cashier is often looking at the customer, so signals should be conveyed with sound. Explain why Can you think of some guidelines for writing usability specifications? http://flic.kr/p/9ksxQa

10. POS Example: Reliability • Recoverability • If there is a failure to use external services (e.g., payment authorizer, etc.) try to solve with a local solution (e.g., store and forward) in order to still complete the sale. Can you think of another reliability specification? http://flic.kr/p/9ksxQa

11. POS Example: Performance • Buyers want to complete sales processing very quickly. One bottleneck is external payment authorization. • Our goal: authorization in less than 1 minute, 90% of the time. Can you think of another performance specification? Be precise! http://flic.kr/p/9ksxQa

12. POS Example: Supportability • Adaptability • Different clients have unique business rule and processing needs while processing a sale. Pluggable business rules must be enabled at defined points in scenarios. • Configurability • Different clients desire different, changing network configs. System must be configurable to reflect these needs. Can you think of another supportability specification? http://flic.kr/p/9ksxQa

13. POS Example: Implementation constraints • Client insists on a Java solution, predicting this will improve long-term porting and supportability, in addition to ease of development. Can you think of another constraint that a client might ask for? Explain why. http://flic.kr/p/9ksxQa

14. POS Example: Application-specific domain rules Broad domain rules (such as laws) belong in a separate artifact (Business Rules). These are more application-specific rules

15. Note that the Larman example containsmore types of supplementary specifications You may consider using any of these http://flic.kr/p/anWc2v

16. UP has a few other requirements artifacts • Vision • What: Brief summary of functional requirements • Why: Quickly introduce someone to the project • Glossary • What: List of terms and definitions • Why: Enhance clarity and terseness of other artifacts • Domain rules • What: Rules/laws that crosscut an application domain • Why: Shareable by multiple projects

17. UP has a few other requirements artifacts I can’t emphasize the importanceof this one enough! • Vision • What: Brief summary of functional requirements • Why: Quickly introduce someone to the project • Glossary • What: List of terms and definitions • Why: Enhance clarity and terseness of other artifacts • Domain rules • What: Rules/laws that crosscut an application domain • Why: Shareable by multiple projects

18. Summary • Supplementary specification • Glossary • Also… • Vision • Domain rules http://flic.kr/p/YSY3X