Security and Usability in the Requirements Process

1. Security and Usability in the Requirements Process Instructor Name

2. Outline • Introduction • The Software Development Life Cycle (SDLC) • The Requirements Process • Model Notation • Use Cases • Security Requirements • Usability and Security Requirements

3. Introduction • Give background in SDLC and requirements engineering for future lectures • “Security requirements are needed because people and the negative agents they create, such as computer viruses and worms, pose real threats to systems.” (Alexander, 2003) • “Security differs from all other specification areas in that someone is deliberately trying to break the system.” (Alexander, 2003)

4. Software Development Life Cycle (SDLC)

5. SDLC • The traditional Software Development Lifecycle (SDLC) is a structured methodology for developing software. • The major phases of the SDLC process include the following: • Requirements process—seeks to clearly define the problem • Design or planning – seeks to create an algorithmic solution for the problem; • Implementation – the solution is coded using a programming language and run for correctness • Testing – formal testing and debugging • Maintenance – the program is maintained, changed, and documented

6. Requirements Process

7. Requirements Process • Phase 1 (elicitation): requirements analyst or system analyst work with the customer to elicit requirements for a software system to be developed by asking questions, examining current behavior, or demonstrating similar systems. • Phase 2 (analysis): requirements are captured in a model or a prototype. • Phase 3 (specification): decisions are made as to which parts of the desired behavior will be implemented in software. • Phase 4 (validation): checks that the specification matches what the customer expects to see in the final project.

8. Requirements Process • During the analysis and validation phases problems or omissions in the models or specification may be exposed that may necessitates revisiting with the customer and consequently a revision to the models or specification. • The requirements process usually culminates with a Software Requirements Specification(SRS), which is used to communicate with other software developers (designers, testers, maintainers) how the final product should behave.

9. Types of Requirements • Functional requirements: describe interaction between the system and its environment. The environment consists of users and other systems or subsystems. • Nonfunctional or qualityrequirements: all requirements that are not explicitly Functional. • include some quality characteristics that the software solution must possess, such as security, usability, fast response time, ease of use, high reliability, or low maintenance costs.

10. Two Kinds of Requirements Documents • Requirements definition: usually written jointly by the client and requirements analyst, it is a complete listing of everything the customer wants to achieve; and is aimed at a business audience, such as clients, customers, and users. • Requirements specification: usually written by the requirements analyst, it restates the requirements as a specification of how the proposed system will behave; and is aimed at a technical audience, such as designers, developers, testers, and project managers • The difference between the requirements definition and the requirements specification is the latter is concerned only with events and states that the system can detect and control in its environment.

11. Example 1: (Jackson & Zave, 1995) Consider a software-controlled turnstile situated at the entrance to a zoo. When the turnstile is fed a coin, it unlocks allowing a customer to push through the turnstile and enter the zoo. Once an unlock turnstile is rotated enough to allow one entry, the turnstile locks again, to prevent another person from entering without payment.

12. Solution 1 • This example’s requirements definition consists of the following two requirements: • no one should enter the zoo without paying an entrance fee, and • for every entrance fee paid, the system should not prevent a corresponding entry. • The requirements specification may be stated as follows: “When a visitor applies a certain amount of force on an unlocked turnstile, the turnstile with automatically rotate a one-half turn, ending in a locked position.”

13. Modeling Notation

14. Model Notation • As an engineering discipline, software engineering has standard notations for modeling, documenting, and communicating decisions. • The vast majority of models, notations and methods can be categorized into approximately ten basic paradigms for expressing information about a problem’s concepts, behavior, and properties (Pfleeger, 2006).

15. Seven of the ten Modeling Paradigms • Entity relationship diagrams • UML class diagrams • Event Traces • message sequence charts • State machines • UML statechart diagrams, petri nets • Dataflow diagrams • Use cases • Functions and relations • Decision tables, Parnas tables • Logic • Object Constraint language (OCL), Z (“zed”), • Algebraic Specifications • Specification and Description Language (SDL),

16. Use Cases

17. Use Cases • Use cases are a technique for capturing the functional requirements of a system • Use cases work by describing the typical characteristics between the users of a system and the system itself. • Use cases provide a narrative of how a system should work

18. Scenario: a sequence of steps describing an interaction between a user and a system. Example: Buy-a-product scenario for an online store (Fowler, 2004) [Scenario 1] “The customer browses the catalog and adds desired items to the shopping basket. When the customer wishes to pay, the customer describes the shipping and credit card information and confirms the sale. The system checks the authorization on the credit card and confirms the sale both immediately and with a follow-up e-mail.”

19. Alternative scenarios to Scenario 1 • Scenario 2: credit card authorization fails • Scenario 3: Have a regular customer for whom you don’t need to capture the shipping and credit card information. • Scenarios 1, 2 & 3 all have a common goal: to buy a product

20. Definitions: (use case, actor) • Use case: a set of scenarios tied together by a common user goal. • Actor: a role that a user plays with respect to the system. • Actors include: customer, customer rep, sales manager, product analyst and other systems • Actors carry out use cases.

21. Use Case Text Example: No standard way to write the content of a use case (Fowler, 2004)

22. Use Case Diagram Example

23. Use Case Diagram • It’s a graphical table of contents for the use case set • Shows the actors, use cases and the relationship between them • Which actor carry out which use cases • Which use cases include other use cases • Advice: Don’t put to much effort into use case diagrams; instead, concentrate on the textual content of the use cases.

24. Levels of Use Cases • Sea-level use cases: typically represent a discrete interaction between a primary actor and the system • Deliver something of value to primary actor • Fish-level use cases: there because there are included by sea-level use cases • Kite-level use cases: show how sea-level use cases fit into wider business interactions

25. More About Use Cases • A valuable tool to help understand functional requirements of a system • Should be made early in the requirements phase • Use cases represent an external view of the system: don’t expect any correlation between them and the classes inside the system • Big danger: people make them to complicated and get stuck; you’ll get less hurt by doing too little

26. Security Requirements

27. Security Requirements • Definition: requirements that aims to ensure the security of the system under design. • Exist because people and the negative agents they create (such as computer viruses) pose real threats to systems. • Security differs from other specifications in that an entity is deliberately threatening to break the system. • Future lectures will look at the security requirements techniques that we outline next.

28. Security Requirements Elicitation Methods • Misuse Cases – “misuse or abuse cases apply the concept of negative scenario in a use-case scenario.” • Soft Systems Methodology (SSM)- “deals with problem situations in which there is a high social, political, and human activity component.” • Quality Function Deployment (QFD) - “an overall concept that provides a means of translating customer requirements into the appropriate technical requirements for each stage of product development and production.” (Frequently Asked Questions About QFD) • Controlled Requirements Expression (CORE)– “a requirements analysis and specification method that clarifies the user’s view of the services to be supplied by the proposed system.”

29. Security Requirements Elicitation Methods • Issue-based Information Systems • Joint Application Development • Feature-oriented Domain Analysis • Critical Discourse Analysis • Accelerated Requirements Method

30. Usability and Security Requirements

31. Usability • Usability has multiple components, so that a usable system is endowed with the following attributes (Nielsen, 1993): • Learnability--easy to learn • Efficiency--once the user has learned the system, a high level of productivity should be possible • Memorability-- easy to remember,so that the casual user is able to return to the system • Errors--should have a low error rate, so that users make few or no errors while using the system • Satisfaction--should be pleasant to use, so that users are satisfied when using it

32. Relationship between Usability and Security Requirements • Usability requirements are probably just as important as security requirements • Usability complements security because security is enhanced when security systems are usable • Like security, usability is a non-functional requirement • Many of techniques used to garner security requirements are also used for usability requirements; but with usability the emphasis is on the user • Future lectures will examine how usability fits into the security requirements outlined above

33. Questions?

34. References Alexander, I. (2003). Misuse Cases: Use Cases with Hostile Intent. IEEE Software , 58-66. Allen, A., Barnum, S., Ellison, R., McGraw, G., & Mead, N. (2008). Software Security Engineering: A Guide for Project Managers. Boston, MA: Addison-Wesley. Cockburn, A. (2001). Writing Effective Use Cases. Addison-Wesley. Fowler, M. (2004). UML Distilled: A Brief Guide to the Standard Object Modeling Language. (3, Ed.) Boston, MA, USA: Addison-Wesley. Frequently Asked Questions About QFD. (n.d.). (QFD Institute) Retrieved July 19, 2009, from http://www.qfdi.org/what_is_qfd/faqs_about_qfd.htm Jackson, M., & Zave, P. (1995). Deriving Specifications from Requirements: An Example. Proceedings of the Seventeenth International Conference on Software Engineering (pp. 15-24). CA: IEEE Computer Science Press. Pfleeger, S. L., & Atlee, J. M. (2006). Software Engineering: Theory and Practice (Third ed.). Upper Saddle River, NJ: Pearson Prentice Hall. Standish Group Web site. (n.d.). The Standish Group. (The Standish Group) Retrieved February 8, 2009, from http://www.standishgroup.com/