1 / 44

Inception

Inception. > Spring 2010, Amirkabir university, CS department. Amin Gheibi. Inception. A short initial step to answer: What is the vision and business case for this project? Feasible? Buy and/or build? Rough estimate of cost: Is it $10K-100K or in the millions? Should we proceed or stop?

bendek
Télécharger la présentation

Inception

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Inception > Spring 2010, Amirkabir university, CS department Amin Gheibi

  2. Inception • A short initial step to answer: • What is the vision and business case for this project? • Feasible? • Buy and/or build? • Rough estimate of cost: Is it $10K-100K or in the millions? • Should we proceed or stop? • Just investigate the high-level requirements (not a deep drilling)

  3. Inception • Inception may be very brief • It is absolutely feasible (you had a same project) • Stakeholder is determined

  4. Vision • Vision document (contractual): • Problem Statement • Stakeholder responsibility • Very high-level requirements and features to give the reader an understanding of the system to be developed • design constraints • User Description • User Environment

  5. Business Case • Business Case: • describe the business issue that the recommended project would solve • Describe the anticipated outcomes. “What are we aiming for?” • Summary of recommendations • Justify why the recommended project should be implemented • List and describe any assumptions • List and describe any limiting factors

  6. Requirement • Requirements: • capabilities and conditions to which the system—must conform • Challenge: How to find and record real requirement • Requirement Mang. • It is not waterfall attitude (freezing requirements) • a systematic approach to finding, documenting, organizing, and tracking the changing

  7. Requirement

  8. Requirement

  9. Requirement

  10. Requirement

  11. No. 1 suspect

  12. Type of req. (Book’s categories) • Functional: • features, capabilities, security • Usability: • human factors, help, documentation • Reliability: • frequency of failure, recoverability, predictability • Performance: • response times, accuracy, availability, resource usage.

  13. Type of req. (Book’s categories) • Supportability: • adaptability, maintainability, internationalization, configurability. • It is helpful to use this kind of categories as a checklist for requirements coverage, to decrease the risk • Some of these requirements are quality attributes, or functional vs. non-functional

  14. Req. record • Functional requirements are explored and recorded in the Use-Case Model • Other requirements can be recorded in the use cases they relate to, or in the Supplementary Specifications artifact.

  15. Use Case • an excellent technique to understand and describe requirements is writing use cases: stories of using system • The best way to capture customers’ need is the simplest and most familiar one (especially for cusomer Bcz they can contribute)

  16. Example (informal format) • We need a structured format to capture requirements

  17. Definitions • Actor • A person, a system, or an organization with behavior: a cashier, tax calculator, inventory system … • Scenario (Use case instance) • a specific sequence of actions and interactions between actors and the system under discussion • Use case • a collection of related success and failure scenarios that describe actors using a system to support a goal.

  18. Example (Casual format)

  19. Focus in writing use cases • How can we use system to fulfill user’s goal or answer his need? Add value to user • Don’t look at them as laundry list of system’s functions • Black-box use case: • do not describe the internal workings of the system, • Rather, describe the system as having responsibilities

  20. Focus in writing use cases • it is possible to specify what the system must do (the functional requirements) without deciding how it will do it (the design)

  21. Degrees of formality • Brief (informal) • One paragraph about Main scenario • Casual: • Some paragraphs, also covers alternatives • Fully dressed • All steps and variations are written in detail, and there are supporting sections, such as preconditions and success guarantees

  22. Example • Open your book at page 50

  23. Questions ?

  24. Level of UC granularity • Which of these is a valid use case? • Negotiate a Supplier Contract • Handle Returns • Log In

  25. Elementary Business Process • A task performed by one person in one place at one time, in response to a business event (need), which adds measurable business value and leaves the data in a consistent state. • It’s not a single small step like • It doesn’t take days and multiple sessions

  26. Elementary Business Process • it is frequently useful to create separate "sub" use cases representing sub-tasks or steps within a base use case • To avoid duplication of the text • an EBP-level use case is called a user goal-level, to emphasize that it serves to fulfill a goal of the primary actor.

  27. Recommended procedure • Find the user goals • Define a use case for each • Rather than asking "What are the use cases?", one starts by asking: "What are your goals?" • Hierarchy of goals • Example: pp.62

  28. Subfunction • Is it always helpful? • The most common, valid motivation to express a subfunction goal as a use case is when the subfunction is repeated

  29. Primary actors • Use cases are defined to satisfy the user goals of the primary actors. • So to find use cases: • Choose the system boundary • Identify the primary actors • For each, identify their user goals • Define use cases that satisfy user goals (some exception e.g. CRUD)

  30. Choose the system boundary

  31. Identify the primary actors and goals • Actors: • Primary (call) • Supporting (is called) • Offstage (has some interest) • The team brainstorm and generate a mixture of both. Sometimes, goals reveal the actors, or vice versa. • Some reminder questions

  32. Actor-goal list

  33. Boundary • Why is the cashier, and not the customer, the primary actor in the use case Process Sale? • Why doesn’t the customer appear in the actor-goal list?

  34. Define Use Cases • Define one EBP-level use case for each user goal • Name use cases starting with a verb • A common exception is to collapse CRUD (create, retrieve, update, delete) into one CRUD use case, idiomatically called Manage <X>

  35. Iterative Improvement • Congratulations; Use Cases Have Been Written, and Are Imperfect • ongoing personal communication • XP Practice: User full-time on the project, in the project room

  36. Writing use cases in Essential Style • Focus on intention (goal) rather than interface • For example: log-in and authentication (maybe we offer fingerprint)

  37. Essential Style (example) • The design solution to these intentions and responsibilities is wide open

  38. Concrete Style (example) • Do not use them in early requirement analysis

  39. Use Case Diagram

  40. UCs in UP • Requirements are primarily recorded in use cases • Use cases are an important part of iterative planning. • Use-case realizations drive the design. • Use cases often influence the organization of user manuals • In one word: GOOD STARTING POINT

  41. Inception • Only 10% of the use cases written in any detail • Business Use Cases vs. System Use Cases

  42. Artifatcs

  43. Supplementary Spec.

More Related