Methods for Software Specification

1. Methods for Software Specification Jan Kožusznik. Dept. of Computer Science Technical University of Ostrava jan@kozusznik.cz http://www.kozusznik.cz

2. Used literature • COCKBURN, A. Use Cases Jak efektivně modelovat aplikace. CP Books, a.s., 2005. ISBN 80-251-0721-3. • FOWLER, M. UML Distilled: A BriefGuide to the Standard Object Modeling Language. Addison-Wesley Professional, 2003. ISBN 978-0321193681. • GAMMA, E., HELM, R., JOHNSON, R. AND VLISSIDES, J.M. Design Patterns: ElementsofReusableObject-Oriented Software. 1st ed.: Addison-Wesley Professional, 1994. ISBN 978-0201633610. • PFLEEGER, S.L. AND ATLEE, J.M. Software Engineering: Theory and Practice. PrenticeHall, 2009. ISBN 0136061699. • POHL, K. Requirements Engineering: Fundamentals, Principles, and Techniques. Springer, 2010. ISBN 978-3642125775 • PRESSMAN, R.S. Software engineering : a practitioner'sapproach. 7th ed. New York: McGraw-HillHigherEducation, 2010. xxviii, 895 p. p. ISBN 9780073375977. • SOMMERVILLE, I. Software engineering. 9th ed. Harlow: Addison-Wesley, 2010. xxiii, 840 p. p. ISBN 978-0137035151. • WARMER, J. AND KLEPPE, A. TheObjectConstraintLanguage: GettingYourModelsReadyfor MDA. Addison-Wesley Professional, 2003. ISBN 0321179366.

3. Software engineering • The IEEE Computer Society defines software engineering as: • “(1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. • (2) The study of approaches as in (1).”1

4. Software development „reality“

5. Users‘vs. developers‘ view • How developers see users • Users don’t know what they want. • Users can’t articulate what they want. • Users are unable to provide usable statements of needs. • Users have too many needs that are politically motivated. • Users want everything right now. • Users can’t remain on schedule. • Users can’t prioritize needs. • Users are unwilling to compromise. • Users refuse to take responsibility for the system. • Users are not committed to development projects. • How users see developers • Developers don’t understand operational needs. • Developers can’t translate clearly stated needs into a successful system. • Developers set unrealistic standards for requirements. • Developers place too much emphasis on technicalities. • Developers are always late. • Developers can’t respond quickly to legitimately changing needs. • Developers are always over budget. • Developers say “no” all the time. • Developers try to tell us how to do our jobs. • Developers ask users for time and effort, even to the detriment of the user’s important primary duties.

6. Software process – key disciplines

7. Requirement specifications Requirements expressed in : • Natural language sentences • Structurednatural language • Design description language • Graphical notations • Formal specifications

8. Requirements • Requirement is • A condition or capability needed by a user to solve a problem or achieve an objective. • A condition or capability that must be met or possessed by a system or system component to satisfy a contact, standard, specification, or other formally imposed documents. • A document representation of a condition or capability as in (1) or (2). • Requirement artifact is a documented requirement. • Requirement types: • Functional requirements • Quality requirements • Constraints.

9. SRS should be • Correct • Unambiguous • Complete • Consistent • Ranked for importance and/or stability • Verifiable • Modifiable • Traceable

10. Functional requirements Functional requirementsare statements of services that a system should provide, how the system should react to particular inputs and how the system should behave in a particular situation. In some cases, functional requirements may also state what the system should not do. Example: If a sensor detects that a glass pane is damaged or broken, the system shall inform the security company, Mainly defines: data, functions, and behavior.

11. Quality requirements I A quality requirement defines a quality property of the entire system or of a system component, service, or function. Types of quality requirements • Important primarily for developers • Maintainability • Portability • Reusability • Testability • Important primarily for users • Availability • Efficiency • Flexibility • Integrity • Interoperability • Reliability • Robustness • Usability

12. Quality requirements II A quality requirement defines a quality property of the entire system or of a system component, service, or function. Types of quality requirements • Important primarily for developers • Maintainability • Portability • Reusability • Testability • Important primarily for users • Availability • Efficiency • Flexibility • Integrity • Interoperability • Reliability • Robustness • Usability

13. Quality requirements III A quality requirement defines a quality property of the entire system or of a system component, service, or function. Types of quality requirements • Important primarily for developers • Maintainability • Portability • Reusability • Testability • Important primarily for users • Availability • Efficiency • Flexibility • Integrity • Interoperability • Reliability • Robustness • Usability

14. Non-functional requirements Non-functional = Underspecified functional requirements Quality requirements The system shall be secure. • Each user must log in to the system with theiruser name password prior to using the system. • The system shall remind the user every four weeks to change thepassword. • When the user changes thepassword, the system shall validate that the new password is at least eight characters long and contains alphanumeric characters. • Users‘password stored in the system must be protected against password theft.

15. Constraints I. A constraint is an organizational or technological requirement that restricts the way in which the system shall be developed. • Organizational process • Resources • Documentation • Standards • Design (operational environment) • Physical environment • Interface • Users

16. Constraints II A constraint is an organizational or technological requirement that restricts the way in which the system shall be developed. • Organizational process • Resources • Documentation • Standards • Design (operational environment) • Physical environment • Interface • Users

17. Constraints III A constraint is an organizational or technological requirement that restricts the way in which the system shall be developed. • Organizational process • Resources • Documentation • Standards • Design (operational environment) • Physical environment • Interface • Users • Constraints affecting the system: • Withrespect to current conditions defined by the insurance company, only the security technicians are allowed to deactivate the control function of the system. • A fire protection requirement demands that terminals in the sales rooms do not exceed the size 120cm x 90 cm x 20 cm. • Constraints affecting the development process: • The effort for development of the system must not exceed 480 man-months, • The system must be developed using RUP.

18. Creation of textualrequirement I oug deletion To g s h u t distortion Thoughts generalization Specific thoughts

19. Creation of textualrequirement II oug deletion To g s h u t distortion Thoughts generalization Specific thoughts

20. Creation of textualrequirement III oug deletion To g s h u t distortion Thoughts generalization Specific thoughts

21. Use cases Use case is specification of a sequence of actions, including variants that a system (or other entity) can perform, interacting with actors of the system. • Benefits: • goalidentification, • exceptional situation.

22. Requirements and use cases • They are really requirements • Cover only a part of requirements – it lacks: • External interface, • Data format • Business rules, • Complex formulae. • Cover one third of all requirements.

23. Use case structure • Scope: <design scope, what system is being considered black-box under design> • Level: <one of: Summary, User-goal, Subfunction> • Primary Actor: <a role name for the primary actor, or description> • Stakeholders & Interests: <list of stakeholders and key interests in the use case> • Precondition: <what we expect is already the state of the world> • Minimal Guarantees: <how the interests are protected under all exits> • Success Guarantees: <the state of the world if thegoal succeeds>

24. Primary actorsandstakeholders gathering • Interactions between Actors with Goals • Actors have goals • Goals can fail • Interactions are compound • A use case collects scenarios • Contract between Stakeholders with Interests Actors havegoals supported by described system.The system should ensure interests of stakeholders.

25. Design scope I Design scopeis the extent of the system

26. Design scope II • "Enterprise" scope • "System" scope • "Subsystem" scope

27. Design scope III • "Enterprise" scope • "System" scope • "Subsystem" scope

28. Design scope IV Design scopeis the extent of the system • "Enterprise" scope • "System" scope • "Subsystem" scope

29. THREE NAMED GOALLEVELS

30. THREE NAMED GOALLEVELS II

31. THREE NAMED GOALLEVELS III

32. THREE NAMED GOALLEVELS IV

33. Use case structure I • Context of use: <a longer statement of the goal, if needed, its normal occurrence conditions> • Scope: <design scope, what system is being considered black-box under design> • Level: <one of: Summary, User-goal, Subfunction> • Primary Actor: <a role name for the primary actor, or description> • Stakeholders & Interests: <list of stakeholders and key interests in the use case> • Precondition: <what we expect is already the state of the world> • Trigger: <what starts the use-case may be a time event> • Minimal Guarantees: <how the interests are protected under all exits> • Success Guarantees: <the state of the world if thegoal succeeds>

34. Use case structure II • Context of use: <a longer statement of the goal, if needed, its normal occurrence conditions> • Scope: <design scope, what system is being considered black-box under design> • Level: <one of: Summary, User-goal, Subfunction> • Primary Actor: <a role name for the primary actor, or description> • Stakeholders & Interests: <list of stakeholders and key interests in the use case> • Precondition: <what we expect is already the state of the world> • Trigger: <what starts the use-case may be a time event> • Minimal Guarantees: <how the interests are protected under all exits> • Success Guarantees: <the state of the world if thegoal succeeds>

35. Use case structure III • Context of use: <a longer statement of the goal, if needed, its normal occurrence conditions> • Scope: <design scope, what system is being considered black-box under design> • Level: <one of: Summary, User-goal, Subfunction> • Primary Actor: <a role name for the primary actor, or description> • Stakeholders & Interests: <list of stakeholders and key interests in the use case> • Precondition: <what we expect is already the state of the world> • Trigger: <what starts the use-case may be a time event> • Minimal Guarantees: <how the interests are protected under all exits> • Success Guarantees: <the state of the world if thegoal succeeds>

36. Scenarios and steps I • Main success scenario – a typical scenarioin which the primary actor’s goal is delivered and stakeholder‘s interests are satisfied • Common surroundingstructure • Condition of scenario • a goal to achieve • a set of action steps • an end condition, • a possible set of extensions. • The scenario body • an interaction between two actors, • a validation step to protect an interest of a stakeholder, • an internal change to satisfy a stakeholder.

37. Scenarios and steps II • Main success scenario • Common surroundingstructure • condition of scenario • goal to achieve • set of action steps • end condition, • possible set of extensions. • The scenario body • an interaction between two actors, • a validation step to protect an interest of a stakeholder, • an internal change to satisfy a stakeholder.

38. Scenarios and steps III • Main success scenario • Common surroundingstructure • Condition of scenario • a goal to achieve • a set of action steps • an end condition, • a possible set of extensions. • Scenario body • interaction between two actors, • validation step to protect interest of the stakeholder, • internal change to satisfy the stakeholder.

39. Different level of goals and precondition The use case on thesummary level gives context for use-cases on lower levels. The precondition indicates theuse-case performed previously.

40. Action Steps – guideline 1: It uses simple grammar Subject ... verb... direct object... prepositional phrase. Example: The system ... computes... provision... from the invoiced amount.

41. Action Steps – guidelines 2:It shows clearly, "Who has the ball“. • At each step one actor "has the ball". That actor is going to be the subject of the sentence, the first actor named, probably as the first or second word in the sentence. • The "ball" is the message and data that gets passed from actor to actor.

42. Action Steps – guidelines 3:It is written from a bird's eye point of view. • Beginning use case writers write the scenario as seen by the system: • Get anATM card and PIN number. Deduct theamount from theaccount balance. X • A better form is: • The customer inserts the ATM card and PIN. • The system deducts the amount from the account balance. v

43. Action Steps - guideline 4: It shows the process moving distinctly forward Avoid small steps – find a slightly higher-level goal for a step, ask "Why is the actor doing that?“. Example: A userhits thetab key. Why is the user hitting the tab key? To get to the address field. Why is he trying to get to the address field? Because he has to enter her name andaddress before the system doesanything. A userenters name and address.

44. Action Steps – guidelines 5:It shows the actor’s intentions, not movements. It is user interface designer’s job to invent a user interface but we are interested in the semantic description of the interface in the requirements document 1. System asks for name. 2. User enters name. 3. System prompts for address. 4. User enters address. 5. User clicks ’OK’. 6. System presents user’s profile. 1. User enters name and address. 2. Systempresents user’s profile. more data items being passed Customer enters name, address, phone number, secret information, emergency contactphone number. Customer enters - name - address - phone number - secret information - emergency contact phone number

45. Action Steps – guidelines 6:It contains a ’reasonable’ set of actions. • The primary actor sends a request and data to the system. • The system validates the request and the data. • The system alters its internal state. • The system replies to the actor with the result. Version 1 – All interaction are in one step. Version 2 – a/ 1. b/ 2., 3., 4. Version 3 – a/ 1. b/ 2. c./ 3., 4. Version 4 – a/ 1. b/ 2. c./ 3. d/ 4. Version 5 – a/ 1. b/ 2. c./ 3. d/ 4( to anactora) e/ 4(to anactor b)

46. Action Steps – guidelines 7:It doesn’t "check whether", it "validates“ • Verifying step is often written as “System … checks” it is not a good action verb because it does not move process distinctly forward – it is followed by “If the (condition) … ” 2. The system checks whether the password is correct 3. If it is, the system presents available actions to the user. 2. The system validates that the password is correct. 3. The system presents available actions to the user.

47. Action Steps – guidelines 8:It optionally mentions the timing • Feel free to put in the timing, but only when you need to. • At any time between steps 3 and 5, the user will ... • As soon as the user has ..., the system will ...

48. Action Steps – guidelines 9:Idiom: "User has System A,kick System B“ • The user hits theFETCH button, at which time thesystem fetches the data from system B. 4.The user signals to the system to fetch data from system B. 5. The system fetches the background data from system B." 4. The user has system A, fetch data from system B.

49. Action Steps – guidelines 10:Idiom: "Do steps x-y until condition" only one step being repeated "The user selects one or more products." "The user searches through various product catalogs until he finds the one he wants to use.„ several steps to be repeated 1. The customer supplies either theaccount identifier or name and address. 2. The system brings up the customer's preference information. 3. The user selects an item to buy, marks it for purchase. 4. The system adds the item to the customer's "shopping cart". The customer repeats steps 3-4 until indicating that he/she is done. 5. The customer purchases the items in the shopping cart (see use case xxx).

50. Action Steps – guidelines 10:Idiom: "Do steps x-y until condition“ - II Variant – “Steps x-y can happen in any order.” 1. Thecustomerlogs on 2. The system presents available products and services. Steps 3-5 can happen in any order. 3. The user selects products to buy. 4. The user specifies thepreferred form of payment. 5. The user givesthedestinationaddress. 6. The user indicates shopping spree is complete. 7. The system initiates anorder withtheselected products to be charged against theform of payment and to be sent to the destination address.