1. Analysis Stage (Phase I) The goal: understanding the customer's requirements for a software system. n involves technical staff working with customers n involves all the stakeholders in the system

2. Requirements phase problems? n Who ARE the stakeholders? n Stakeholders don't really know what they want. n Stakeholders express their requirements in their own terms n Different stakeholders may have conflicting requirements

3. Requirements phase problems? n The requirements may change during the process n New stakeholders may emerge on the scene

4. Analysis Viewpoints: n Partitioning: Identifies the structural relationships between system components u Top-down design u Bottom-up design n Projection: Identifies different ways of looking at a problem u What is the “best” solution? u How is the problem currently solved if it is? u Are there alternative solutions that will work?

5. Social and Organizational factors effect all systems! Software systems are used within a social and organizational context.

6. Social and organizational factors CAN dominate system requirements.

7. Software is not designed in a vacuum! There is no single “correct” viewpoint. Effective software involves combining all viewpoints.

8. Good analysts must be very sensitive to different views. There is no systematic way to factor them into the analysis process.

9. In the Initial Analysis (SRS) only the user's environment was described.

10. In the Design Stage (Phase II) the System ("product") is described in terms of the software environment as well as the user's environment.

11. A careful, thorough design, increases a product's: n dependability n maintainability n (higher) quality

12. The better the design -- The more effective and efficient the implementation.

13. The Design process can be rather formal. The Design can: n use formal specification notations and languages (Program Design Language (PDL)) n conform to set standards of quality and content for the product (local standards) n verify and validate the specification

14. Verification and Validation? Are they different?

15. n Validation: Are we building the right product? n Verification: Are we building the product right?

16. "The [Design] Specification shall clearly and precisely describe the essential functions, performances, design constraints, attributes and external interfaces. Each requirement shall be defined such that its achievement is capable of being objectively verified..."

17. ANSI/IEEE standards: Purpose of Phase II 1) to translate the user-oriented requirements into a form that is meaningful in terms of software development 2) Ideally to create a design so that an automated (tool intensive) development of the software product is possible 3) to commit our organization, and that of the customer, to a set definition of the product

18. The Design Stage is for the software team. n Why do the specifications twice? n Why not do the design directly and skip the Project Plan or SRS? n Why can't we code directly from the SRS?

19. Why a Phase II? 1. The SRS is by definition: imprecise 2. The SRS is a general outline, it is an initial planning document. 3. Design stage is a formal specification of how the problem will be solved!

20. Why a Phase II? 4. We are looking toward the eventual automation of the development process. 5. The Design is another opportunity to make sure the "plan" meets the users needs. 6. The Design finalizes the definition of the product. (??!!)

21. Phase II Moving from Requirements to Design

22. What is a good design? software requirements A good design is one that creates a solution which satisfies the software requirements.

23. Design problem have three stages: 1) Study and Understand the Problem

24. Design problem have three stages: 2) Identify one or more possible solutions. IDEAS?

25. Design problem have three stages: 3) Use some form of abstraction to describe the solution

26. Design 1) Study and Understand the Problem u Examine the problem from all possible viewpoints to discover the design requirements. Note: Design requirements are not the same as the customer’s/user’s requirements! u Identify and talk to stakeholders.

27. Design 2) Identify one of more possible solutions: u There is rarely only one possible solution. u Evaluate alternative solutions. Select the most appropriate depending on the designer's experience and available resources 3) Use some form of abstraction to describe the solution u Use graphical, formal or other descriptive notations to describe the components of the design!

28. The design process involves "decomposing" the system. n Develop system models at different levels of abstraction. n The more design alternatives provided, the more likely the solution will accurately reflect the design.

29. Design takes place in overlapping stages.

30. Design for large scale software includes: n Architectural design u Identify sub-systems n Abstract specification u Specify sub-systems n Interface design u Describe sub-system interfaces

31. Design for large scale software includes: n Component design u Decompose sub-systems into components n Data Structure design u Design data structures to hold the problem's data n Algorithm design u Design algorithms for problem functions

32. In principle... Top-down design involves starting at the uppermost components in the system and working down – level by level.

33. In practice... Large systems design is never really top-down! Some branches are designed before others. Designers reuse experience (and sometimes components) during the design process.

34. The Design has different purposes: n basis for detailed implementation n serves as a communication medium between the designers of sub-systems n provides information to system maintainers about the original intention of the system designers

35. Phase II is a description the Design-- Phase II is for programmers and other developers. It includes: (1) Graphical notations (2) Program Design Languages (PDL) (3) Informal text

36. What are the qualities of a GOOD Design?

37. Design Quality: n Design quality is an elusive concept. n Quality depends on specific organizational priorities n A "good" design may be the most efficient, the cheapest, the most maintainable, the most reliable... n Quality characteristics are equally applicable to function-oriented designs as object-oriented designs

38. Understandability of a design is critical because anyone changing the design must first understand it. Change is inevitable!