1. CS628 - Object Oriented Analysis And Design

2. The Four Pillars of Successful Software Development -Avoid Classic Mistakes -Apply Development Fundamentals -Manage Risk to Avoid Catastrophic Mistakes -Apply Schedule-Oriented Practices

3. Requirements Clients do not present the requirements-analyst with concise, complete, and well organized list of requirements. It is the responsibility of the analyst to: - Ask questions involving all stakeholders -Write down the requirements -Organize the requirements

4. Software Requirements Relationship of Software Requirements to Other Project Processes

5. Software Requirements Project Planning Process serve as input to Reduces scope before base-lining

6. Software Requirements Project Planning Process serve as input to reduces scope before base-lining Project Tracking and Control Process status is tracked as part of

7. Software Requirements Project Planning Process serve as input to reduces scope before base-lining Project Tracking and Control Process status is tracked as part of Change Control Process request change in scope is used to change are the baseline for

8. Software Requirements Project Planning Process serve as input to reduces scope before base-lining Project Tracking and Control Process status is tracked as part of Change Control Process request change in scope is used to change are the baseline for System Testing Process are reference for verifies correct implementation of

9. Software Requirements Project Planning Process serve as input to reduces scope before base-lining Project Tracking and Control Process status is tracked as part of Change Control Process request change in scope is used to change are the baseline for System Testing Process are reference for verifies correct implementation of are the basis for User Documentation Process

10. Software Requirements Project Planning Process serve as input to reduces scope before base-lining Project Tracking and Control Process status is tracked as part of Change Control Process request change in scope is used to change are the baseline for System Testing Process are reference for verifies correct implementation of are the basis for Construction Process are the basis for work products are traced to User Documentation Process

11. Software Requirements Project Planning Process serve as input to reduces scope before base-lining Project Tracking and Control Process status is tracked as part of Change Control Process request change in scope is used to change are the baseline for System Testing Process are reference for verifies correct implementation of are the basis for Construction Process are the basis for work products are traced to User Documentation Process

12. Requirements Categorized 1.Business Requirements 2.Non-Functional Requirements 3.Functional Requirements 4.Business Rules 5.Data Definitions 6.Solution Ideas 7.Constraints 8.External Interface Requirements

13. 1.Business Requirements Describe financial, marketplace, or other benefits that your client, or your client’s customer, can gain from the development of the new software system. “We are planning to increase our efficiency by 30% in the next year. The new order and tracking system is developed to reach and support this goal.” Example: Requirements Categorized (continued)

14. 2.Non-Functional Requirements Statements that indicate how well a system performs some behavior or lets the user perform some function are quality attributes or non-functional requirements. Keywords to listen for are: -Fast - Easy -Intuitive -User-friendly -Robust - Reliable - Efficient An analyst has to work with the clients to define what clients mean by these ambiguous and subjective terms. Requirements Categorized (continued)

15. “The new management information system tool must be able to calculate the financial models fast.” Examples: “We need to be able to train new users quickly in using the new order and tracking system” Requirements Categorized (continued)

16. Non-Functional Requirements Product Requirements Delivery Requirements Organizational Requirements External Requirements Interoperability Requirements Standard Requirements Implementation Requirements Portability Requirements Usability Requirements Efficiency Requirements Reliability Requirements Privacy Req. Ethical Requirements Legislative Requirements Performance Req. Space Req. Safety Req.  Ian Sommerville 2000

17. Non-Functional Requirements: Requirements Categorized (continued) Usability The system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized. Un-verifiable Non-Functional Requirement Experienced controllers should be able to use all the system functions after a total of hours training. After this training, the average number of errors made by experienced users should not exceed two per day. Verifiable Non-Functional Requirement

19. 3.Functional Requirements Describe the functions or services the software system must perform. They describe what the system must be able to do or provide in the context of an actor action. “The user must be able to add new parts to the inventory system.” Examples: “The user must be able to print out the total sales at the end of the day”. Requirements Categorized (continued)

20. 4.Business Rules Are operating principles about a business process. “The weight of ‘Category 4’ packages in the warehouse tracking system cannot exceed 30 lbs.” Examples: “The date-of-birth must be earlier than or equal to the current (today’s) date.” Requirements Categorized (continued)

21. 5.Data Definitions Every time a client is describing a data item or the format, allowed values, or default value for data items, they are presenting a data definition. “The Zip Code consists of five digits, followed by an optional hyphen and an optional four digits.” Examples: “The weight of packages in the new order and tracking system is stored as a number with a precision of three digits after the decimal point.” Requirements Categorized (continued)

22. 6.Solution Ideas Clients describing a specific way to interact with the system to carry out some action or function. The client is suggestion a solution, not a requirement. “We would like the user to be able to use a barcode reader to help them quickly identify parts in the warehouse.” Example: Requirements Categorized (continued)

23. 7.Constraints Conditions that limit the choices available to the designer or programmer developing the software system. “The standard database tool in our organization is Oracle. We require that Oracle is used for the new software system.” Example: Requirements Categorized (continued)

24. 8.External Interface Requirement Describe the connections between the software system you are developing and other software systems or devices. “The software system must be able to read signals from.” Examples: “The new order and tracking system must be able to read information (files) from the existing marketing information system.” Requirements Categorized (continued)

25. Writing Requirements 1.Writing the right requirements 2.Writing the requirements right

26. Characteristics of Quality Requirements Specification: -Complete -Consistent -Modifiable -Traceable Writing Requirements (continued) Writing Requirements (continued)

27. Characteristics of Quality Requirements: -Correct -Feasible -Necessary -Prioritized -Unambiguous -Verifiable Writing Requirements (continued) Writing Requirements (continued)

28. Imperatives are those words and phrases that command that something must be provided. Examples: - Shall - Must - Is required to - Are applicable -Are to -Should -Will -Responsible for Writing Requirements (continued) Writing Requirements (continued)

29. Weak Phrases are clauses that are apt to cause uncertainty and leave room for multiple interpretations. Such phrases cause requirements to be ambiguous. Examples: - Adequate -Appropriate -Be able to - Be capable of -Easy to -Effective -Timely - As required - Normal -User friendly Look at these terms from the programmers perspective. Writing Requirements (continued) Writing Requirements (continued)

30. Example: “The product should be able to provide status messages at regular intervals not less than every 60 seconds” Incomplete:What are the status messages and how will they be displayed to the user? Ambiguous:What part of the product are we talking about? Is the interval between messages really supposed to be at least 60 seconds? So showing it every 10 years is okay? Writing Requirements (continued) Writing Requirements (continued)

31. Another Example: “Charge numbers should be validated on-line against the master corporate charge number list, if possible.” Feasible:What does “if possible” mean? Is it technically feasible? Is it really needed? Avoid imprecise words such as “should”. Writing Requirements (continued) Writing Requirements (continued)

32. Risk Management Risk involves future happenings Risk involves change, change of plans Risk involves choices Risk involves: -Uncertainty -Loss if risk happens [Peter Drucker, 1975] “While it is futile to eliminate risk, and questionable to try to minimize it, it is essential that the risk taken be the right risk.”

33. Risk Management (continued) Risk Management (continued)

34. Risk Identification -Product Size -Business Impact -Customer Related Risks -Process Definition -Development Environment -Technology to be Built -Staff Size and Experience -Time Needed to Develop System

35. Testing Verification Are we building the product right? Is the function implemented correctly? Validation Are we building the right product? Did the requested function get implemented?

36. Testing (continued) Testing (continued) Testing is a set of activities that -can be planned ahead -must be conducted systematically using test plans

37. Testing (continued) Testing (continued) Project Risks (waterfall process) Know risks Technical Risks Business Risks -product does not meet business requirements -loss of management support Predictable risks (from past exaperience) Unpredictable risks

38. Testing (continued) Testing (continued) Unit Testing -Number and type of parameters for functions -Boundary conditions: input/output of a module or class -Inconsistent data types -Are files opened and closed -End of file conditions -Overflow issues (integer maximum) -Boundary conditions with array processing

39. Testing (continued) Testing (continued) Integration Testing -Test modules put together -Incrementally integrated -All at once integrated Regression Testing -Test earlier integrated modules when a new module is introduced

40. Testing (continued) Testing (continued) System Testing -Test the system in a given environment. Example: on a PC with other applications. Stress Testing Performance Testing -In particular for real-time systems and embedded systems. -Resources, memory, network issues.