1. Internet Software Development Putting it all together Paul J Krause

2. Software Lifecycle Customer Requirements Functional Requirements Design Implementation Unit Test System Test Acceptance Test

3. Customer Requirements Functional Requirements Design Implementation Unit Test System Test Acceptance Test

4. Why Requirements? “The firms improving their development speed at the fastest rate actually spend more elapsed time and more effort in the customer requirements stage of the project …. These firms spend significantly less time in the testing and integration stage of development.…” Blackburn, Scudder, et al, in Improving Speed and Productivity of Software Development: A Global Survey of Software Developers (1996) Resources spent on Customer Requirements:

5. Tom on ‘Requirement’ Requirement: Concept *026 November 8, 2001 22:16 Requirement: Concept *026 November 8, 2001 22:16 A requirement is a stakeholder-desired Target or Constraint. A requirement is a stakeholder-desired Target or Constraint. Notes: Notes: 1. The constraints can apply to an engineering process, a design or an operational system. 1. The constraints can apply to an engineering process, a design or an operational system. 2. A requirement is an input to a defined level of design process. 2. A requirement is an input to a defined level of design process. 3. Requirements give information to the designer about the necessary nature of their design. 3. Requirements give information to the designer about the necessary nature of their design. 4. Consequently the design, specification or implementation, can be judged {Spec QC, review, test or in operation} in terms of how well it satisfies those requirements. 4. Consequently the design, specification or implementation, can be judged {Spec QC, review, test or in operation} in terms of how well it satisfies those requirements. INTRO

6. Requirement Specification. Requirement Specification. Concept *508. November 8, 2001 1604 Requirement Specification. Concept *508. November 8, 2001 1604 A requirement specification is the readable expression of a requirement and any requirement background. A requirement specification is the readable expression of a requirement and any requirement background.  Related Concepts:  requirement *026 the future state or constraint  specification *137 the readable artifact  background *507 additional information about the requirement

7. Analysis of dangerous common requirements practices.  Mixing real requirements with ‘designs’  Failing to quantify competitive qualities  Failing to derive implied requirements from designs  Failing to set requirements at appropriate level  Failing to include source information  Failing to include priority information  Failing to specify all critical stakeholders requirements  Failing to distinguish between wishes and their profit  Failing to consider all limited resources as requirements  Failure to update requirements evolutionarily  Failure to consider time, location and conditions with requirements  Failure to plan a time series of quality levels

8. Stakeholders: requirements sources  ‘Stakeholders’ are: Any person, group or thing which Any person, group or thing which Can determine our system’s degree of success or failureCan determine our system’s degree of success or failure By having an “opinion” aboutBy having an “opinion” about system performance characteristics system performance characteristics system lifecycle constraints system lifecycle constraints Stakeholders determine requirements! Stakeholders determine requirements! Systems engineers determine which requirements the stakeholders need Systems engineers determine which requirements the stakeholders need Even if the stakeholders are not currently conscious of those needs!Even if the stakeholders are not currently conscious of those needs!

9. Stakeholder: Concept *233. ‘Stakeholders’ are: ‘Stakeholders’ are:  Any person, group or thing  that can determine our systems degree of success or failure,  by having an opinion about  system performance characteristics and  system lifecycle constraints

10. Functional Requirements Customer Requirements Functional Requirements Design Implementation Unit Test System Test Acceptance Test

11. What are Actors and Use Cases?  Actors - users of the system external entities (people or other systems) who interact with the system to achieve a desired goal. external entities (people or other systems) who interact with the system to achieve a desired goal.  Use Cases - what happens when Actors interact with the system by recording all the ways the system is used (“cases of use”) we accumulate all the goals or requirements of the system. by recording all the ways the system is used (“cases of use”) we accumulate all the goals or requirements of the system.

12. Therefore:  The Use Case is a collection of sequences of actions or events relating to a particular goal.  The Collection of Use Cases (the Requirements Specification) should define all system behaviour relevant to the actors to assure them that all their goals are carried out properly.  Any system behaviour that is irrelevant to the actors should not be included in the Use Case.

13. Identifying Actors  Who uses the system?  Who installs the system?  Who starts up the system?  Who maintains the system?  Who shuts down the system?  What other systems use the system?  Who gets information from this system?  Who provides information to the system?  Does anything automatically happen at preset times?

14. Examples of Actors CustomerClerkShipping Company Supplier

15. Use Case Diagram CustomerClerkShipping Company Supplier Place Order Get Order Status Calculate Postage Supply Product Deliver Package

16. Use Case: Place Order Customer Place Order

17. Use Case: Place Order Description: This Use Case describes how a customer selects an item to purchase and then places an order for that item. Level: Primary task Preconditions: The Customer is logged into the system Postconditions: A product has been ordered Primary Actor: Customer Secondary Actors: Credit Company

18. Place Order: Flow of Events Trigger: The Customer selects a Product category 1. The Customer browses the chosen Product category page 2. The Customer selects a specific Product to purchase 3. The Customer adds the Product to their Shopping Cart 4. The Customer may repeat events 1, 2 and 3 to add additional items to their Shopping Cart 5. When ready, the Customer requests that the Order be commited to 6. The Credit Company is notified to authorise the Customer’s credit rating 7. If the credit rating is positive, the Order will be placed

19. Nouns as Candidate Classes Trigger: The Customer selects a Product category 1. The Customer browses the chosen Product category page 2. The Customer selects a specific Product to purchase 3. The Customer adds the Product to their Shopping Cart 4. The Customer may repeat events 1, 2 and 3 to add additional items to their Shopping Cart 5. When ready, the Customer requests that the Order be commited to 6. The Credit Company is notified to authorise the Customer’s credit rating 7. If the credit rating is positive, the Order will be placed

20. Place Order: Exceptional Events The Customer may terminate the transaction at any point before Step 7 and the Order will not be placed 2aIf the Product is out of stock, the customer will be notified and asked to confirm of they wish to continue with the selection 6aIf the Customer’s credit rating is not satisfactory, the transaction will be politely terminated at this point

21. Design Customer Requirements Functional Requirements Design Implementation Unit Test System Test Acceptance Test

22. Identifying classes  Think about general properties of the domain in which you are working  Identify the nouns  These form candidate classes A Publisher produces and markets a Book A Customer purchases a Book An Author writes a Book

23. PublisherBookCustomerAuthor

24. Publisher name address webSite Book bookNumber title unitPrice Customer name email shippingAddress Author name address webSite

25. Associations Publisher name address webSite Book bookNumber title unitPrice R1 publisherpublication Publisher name address webSite Book bookNumber title unitPrice R1 is produced and marketed by produces and markets

26. Association Meanings  Name the association so that it can be unambiguously identified (e.g. R1)  The “association ends” express meaning  An association end may be a role or a verb phrase  Each class in an association has a role (e.g. a Book has the role of a publication) (e.g. a Book has the role of a publication)  But writing meaning in terms of a verb phrase is more descriptive

27. Publisher name address webSite Book bookNumber title unitPrice Customer name email shippingAdd Author name address webSite R1R3 R2 is produced and marketed by produces and markets purchases is sold to wrote was written by

28. Multiplicity  We can also characterise an association by the number of instances (objects) that participate in each instance of the domain relationship  UML allows specific numbers in a multiplicity relation  Recommend you only use four kinds: unconditional;1, or 1..* unconditional;1, or 1..* conditional;0..1, or 0..* conditional;0..1, or 0..*

29. Publisher name address webSite Book bookNumber title unitPrice Customer name email shippingAdd Author name address webSite R1R3 R2 is produced and marketed by produces and markets purchases is sold to wrote was written by 10..*1..* 0..* 1..* There are books not sold to any customer To be a customer you must have purchased at least one book But where do I put the number of books a customer purchased?

30. Publisher name address webSite BookProduct bookNumber title unitPrice Customer name email shippingAdd Author name address webSite R1R3 R2 is produced and marketed by produces and markets is a purchase of is sold as wrote was written by 10..*1..* 0..* 1..* Order quantity salePrice date makes1..* is made by 1

31. Design Customer Requirements Functional Requirements Design Implementation Unit Test System Test Acceptance Test

32. Still to Do  Formalising Use Cases Strengthening the connection between requirements and design Strengthening the connection between requirements and design  Testing