2. Risk: Developing Software is a Risky business l complex systems l break new ground l rarely work in totally familiar environment l mistakes occur l Most new software fails to achieve viability

3. Risk Reduction l What if we had reusable components? l What benefits might be achieved?

4. Advantages of reusable components. l dealing with proven components l known characteristics l no development time l "error-free"

5. Software Acquisition l Should we buy software or write it ourselves? l Make-buy decision

6. Software Acquisition: Make or Buy a) purchase off-the-shelf software b) modify or customize off-the- shelf software c) design custom-built software

7. The decision is really based on COST! 1) Will the delivery date of "off-the-shelf" software be sooner than that for internally developed software? 2) Will the cost of acquisition plus the cost of customization be less than the cost of developing the software internally? 3) Will the cost of outside support be less than the cost of internal support?

8. Software Development Takes a long time. The longer a product remains in development, the greater the risk of –discouragement or boredom on part of team –disillusionment on the part of management

9. Risks -- What risks? So what if the system doesn't work quite the way we planned? What could happen?

10. Remember we are building Software Systems for Customers! l Software consists of the computer programs and associated documentation required to develop, operate, and maintain the programs. l A customer is a person, or persons, who pay for the system and usually decide the requirements

11. Remember we are building Software Systems for Customers! A system is an association of interdependent devices, people, rules, and/or procedures organized to form an integral whole to achieve a common purpose. –General Motors is a "system" for making and selling cars. –A college is a "system" organized to provide students with a post-secondary education.

12. Problems in SE are l immensely complex l understanding the problem can be very difficult l often difficult to understand the nature of the problem

13. Definition Development Maintenance

14. Project - Three stages: 1) Requirements -- Definition 2) Implementation -- Development 3) Final -- Verification, Release and Maintenance

15. Project - Stage One Stage 1 = Phase 1 Software Requirements Specification (SRS) Requirements -- Definition l "bounded description of the scope of [the] software effort" l The purpose of software planning is to provide a initial indication of a project viability

16. Project - Stage Two Implementation -- Development 1) Design = Phase II - concentrates on design, description of architectural and data design - modular structure is developed - interfaces are defined 2) Implementation = Phase III - coding -- directly traceable to a detailed design description - documentation

17. Project - Stage Three Final -- Verification, Release and Maintenance l Testing l Find and correct the maximum number of errors before shipment l Maintains software throughout its useful life

18. Where are we now: Requirements Analysis Phase I Determining a System’s Requirements is the process of establishing the services the system should provide and the constraints under which it must operate.

19. Software Requirements Specification(SRS) -- Phase I In other words.... We are being asked to identify the problem the customer wishes to have solved. It including the qualities and tasks the the solution needs to perform. It is generated using customer-supplied information

20. How do we gather data to determine a Project’s Requirements? l Observation - Watch l Interview - Listen l Research - Learn

21. Observation: Watch, Who, Where, Why? l Watch the way it is done: Go to the customer’s site, spend time in the users real-world environment! l Who does the job? l Where is it done? l Why is it done in this particular way? Learn everything you can about the way the process is done. At this stage it doesn’t matter if it is done by hand or by computer.

22. Interview l Determine who are the project’s stakeholders! l Talk to customers l Talk to users l Talk to other stakeholders

23. Research l Study documentation provided by the customer. l Collect materials generated by the existing system, even if such materials are paper- and-pencil versions l Examine the input and output currently generated

24. What is a General Requirement? l A requirement is a statement (specification) of what a system must do ! l The things about the system users can observe. l The “goal” of the system. l Written in English (natural language)

25. What is an SRS? "Architecture" of the system

26. Characteristics of “good” requirements. 1. They are precise, with no room for misinterpretation by users or implementers. 2. They specify just what the system must do, NOT how to do it. 3. They show conceptual integrity (Each requirement interacts well with the others).

27. “Good” requirements Could it be argued that the requirements are the user interface?

28. Constraints or Nonfunctional Requirements A constraint is a limitation on possible implementations of the system. A constraint does not contribute to the functionality of the system. For example: - particular language required by customer - particular algorithm for one part of the system - particular format for temporary data storage

29. Constraints l In designers best interests to negotiate away constraints since they limit implementation freedom. l However, since the customer is paying for the product, they normally get to impose constraints if they really want them.

30. Implementation Detail Any property of the system that should NOT be visible to users

31. Analysis/Definition Phase Accuracy and completeness are the primary characteristics of good analysis. This is the plan!

32. Project Plan Must Be Complete! l Missing information represents errors by omission! l Checklists help l Select clear-cut, rational, measurable goals for the product and process

33. Software Requirements Specification The SRS: NOTdesign l Is NOT a design document. –Design focuses on how the problem will be solved! –The SRS focuses of WHAT IS the problem? l Should set out what the system should do without specifying how it should be done. l One-to-one mapping from software requirements document onto the final system design.

34. Software Requirements Specifications -- This is a reference tool!

35. Software Requirements Specification (SRS) l Identifying need is the starting point in the evolution of a computer based system. l Analyst assists the customer in defining the goals of the system (product) –What information will be produced? –What information is to be provided? –What functions and performances are required?

36. Software Requirements Specification (SRS) Distinguishes between Customer "needs" -- AND Customer's "wants" --

37. Research and Observation How do we get what we need to create the Software Planning Document? l Obtain copies of ALL operating documents l Assess existing documents l Assess current procedures l Focus on identifying visible l Observe current procedures l Cross “fertilization”

38. The Interview Process l not everything spoken is the truth l sometimes people lie or forget facts l most often they speak from their own ignorance or point of view l interview many people to balanced information l evaluate what you are hearing l watch body language

39. The Interview Process l Provide feedback l What is it I heard? l What do I understand? l Rephrase critical information l Ask the same question in a slightly different way, do you get the same response?

40. The Interview Process l Put person you are interviewing at ease. l Avoid or Reduce interruptions. l Focus attention

41. The Interview Process l Meeting of minds: –review as you go along l Note taking? l What happens after?

42. What happens after the interview? l Immediately write down interview results. l Research show that even in a life-and-death situations: 50% of what took place is forgotten within 30 minutes. l Follow-up Memo

43. The Interview Process: Follow-up Memo l Thank You l Summarizing discussion l Identify additional questions