1. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Slide 1 Analysis Workflow l The primary activities of the Analysis workflow are aimed at building the analysis model, which helps the developers refine and structure the functional requirements captured within the use case model. l This model contains realizations of use cases that lend themselves to design and implementation work better than the use cases.

2. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 2 Slide 2 Analysis Workflow vs Requirements Workflow l Requirements Workflow – Users external view of the system l Analysis Workflow – expansion of the requirements deliverables to further describe the system from a developers point of view.

3. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 3 Slide 3 Analysis Workflow Tasks l GOAL: l The goal of object-oriented analysis and the analysis workflow is to l REFINE THE REQUIREMENTS. l To do this we need to deliver use case realizations.

4. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 4 Slide 4 Analysis Workflow Tasks l The analysis use case realization is essentially a model that contains behavioral and structural diagrams. Structural diagrams are the Class diagrams. Behavioral diagrams are the Collaboration or Sequence diagrams l (we stop at use case descriptions for this class and continue with behavioral specifications in the second class)

5. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 5 Slide 5 Analysis Workflow Tasks l STEPS l 1. Class Analysis Analysis class diagrams (no methods) l 2. Use Case Realizations Use Case descriptions Sequence Diagrams (next class) l 3. Advanced Items Analysis Packages Metadata Definition Analysis Patterns

6. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 6 Slide 6 Analysis Workflow l Why not do this during the requirements workflow? The requirements artifacts must be totally comprehensible by the client l The artifacts of the requirements workflow must therefore be expressed in a natural (human) language All natural languages are imprecise

7. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 7 Slide 7 Analysis Workflow l Example from a manufacturing information system: “A part record and a plant record are read from the database. If it contains the letter A directly followed by the letter Q, then calculate the cost of transporting that part to that plant” l To what does “it” refer? The part record? The plant record? Or the database?

8. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 8 Slide 8 Analysis Workflow l Two separate workflows are needed The requirements artifacts must be expressed in the language of the client The analysis artifacts must be precise, and complete enough for the designers (although they may be reviewed with sophisticated users)

9. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 9 Slide 9 Analysis Workflow l Specification document (“specifications”) Constitutes a contract It must not have imprecise phrases like “optimal,” or “98 percent complete” l Having complete and correct specifications is essential for Testing, and Maintenance l The specification document must not have Contradictions Omissions Incompleteness