Inception

1. Inception What needs to be done? • Describe the vision and business case for this project. • Determine if the project is feasible. • Determine if the enterprise should build or buy the necessary system. • Make a rough estimate of the cost of the project. • Determine if we should go ahead with the project. YES ….. If the answer is

2. Artifact Comment Inception Artifacts generated during Inception Describes the high-level goals and constraints and provides an executive summary Vision and Business Case Describes the functional requirements of high-level goals, and related non-functional requirements Use-Case Model Supplementary Spec. Describes other requirements Begin keeping a dictionary of key domain terminology Glossary Prototyes and proof-of-concepts To clarify the vision and validate techincal ideas Describe what to do in the first Elaboration Iteration Iteration Plan

3. Inception ATM Example: (Partial) Vision Version Date Description Author Inception Draft Sept. 1, 2004 First draft to be refined primarily during Elaboration J. TenEyck Introduction and Problem Statement We envision a banking system that provides automatic teller machines (ATMs) at which customers holding a bank card can make deposits and withdrawls to and from their accounts. The ATM machines will belong to a consortium of banks participating in this project.

4. ATM Vision (cont.) Business Opportunity ATM machines will be attractive to banking customers because they allow access to their accounts outside of regular business hours. They allow the bank to expand customer services and geographical reach without the cost of building additional branches or hiring additional tellers. Product Position Statement Here we state the outstanding or unique features of this system, who it is for and what additional potential customers it might attract, and what differentiates it from the competition. Stakeholder Descriptions Participating Banks – Want to make sure that access to their customer account information is safe and secure, transaction information is accurate and reliable, and that their own account card is readily recognizable at a large number of ATMs. Bank Customers – Want easy, low-cost, remote access to their accounts, but want to be assured that their accounts are secure and not accessible to hackers or other third parties.

5. ATM Vision (cont.) High-level Goal Fast, robust, and secure automated teller network. Priority -- high Problems and Concerns -- Client bank must be able to handle multiple simultaneous transactions (and possible simultaneous transactions to the same joint account). Banks owning an ATM must be able to determine the cash on hand in the ATM. The cash in the ATM must be secure. Consortium server must be able to identify the home bank of the customer card.

6. ATM Vision (cont.) User Goals Customer – Make withdrawls, deposits, and balance checks to his/her account. Home Bank – Provide secure access for customer to his/her account. These indicate high-level use cases to be initiated during Inception Product Overview The ATM network will consist of a large number of ATM machines distributed over a wide geographical area. The network must be able to handle a growth in ATM terminals and an expanding geographical area. It will have to be able to readily form an interface with other ATM networks in other parts of the world. The ATM network will provide services to users and collaborate with other banking networks as indicated in the diagram on the next slide.

7. Customer Use services Use services System Administrators <actor> Member Bank Customer Accounts Use services ATM Vision (cont.) ATM Network Consortium Computer System Actors Note! External agents may also be other, in-place Systems

8. Supporting Feature Stakeholder Benefit ATM Vision (cont.) Summary of Benefits Functionally, the system will provide teller services to bank customers Automated, remote access to user accounts. Real-time transactions with member bank systems using industry standard protocols Timely account updates and transaction recording Pluggable business rules at various scenario points during transaction processing Flexible business logic configuration This table relates the goals, benefits and solutions at a higher level not solely related to use cases.

9. ATM Vision (cont.) Summary of System Features • Transaction capture • Transaction authorization • Security of transaction information • Real-time transactions with other interconnected ATM networks • Definition and execution of customized “pluggable” business rules at fixed common points in the processing scenarios • Real-time interaction with member bank account processing systems Other elements of the Vision Statement include: Assumptions and Dependencies and/or Constraints Cost and Pricing of the System under construction Licensing and Installation of ATM terminals Plans for allowing expansion of the network

10. “The Vision Thing” The Vision Document is a useful tool for management to make determination of whether to build, buy, redefine, or abort consideration of the system. It provides sufficient non-technical detail for evaluating the system under consideration. The Vision Document is also useful to the Technical people for beginning the process of determining and describing the requirements of the system. It indicates the important high-level and stakeholder goals that need elaboration in the use cases. Note that the class project is a system “taken out of any particular context”. The problem statement will serve instead of a vision document, and the remainder of the inception process will proceed from there.

11. The Glossary During Inception, the Glossary should be a simple listing of terms with brief descriptions or definitions. During Elaboration, the Glossary expands into the role of a Data Dictionary. Term Definition and Information Aliases A banking terminal and required software for processing customer transactions Automatic teller machine ATM It is important to start early in keeping a glossary of terms so that all members of the design team have the same concept of what each term means. In the example shown here, The term ATM refers to both the physical terminal and the supporting software that it contains.

12. The Glossary In subsequent elaborations the Glossary is refined to include • Format (type, length, unit) • Relationship to other terms (attributes, associations, methods) • Range of values • Validation rules

13. Use Cases During Inception some of the most important stakeholder goals should be developed as use cases. During Inception, it is not necessary, nor necessarily desirable, to generate a fully dressed use case, nor is it necessary to develop any but the most important of the stakeholder goals into use cases. Essential Use Case Statements Name ATM Withdrawl Valid Member Bank Account Holder Primary Actor Account Holder, Member Bank Stakeholders and Interests Useful in determining the problem domain Concepts and providing guidelines for elaboration of success scenarios, Brief Narrative Preconditions User must have a valid bank card, must indicate an amount < balance Post-conditions User obtains proper cash, user account correctly debited, transaction recorded at bank

14. Supplementary Specifications The difference between the component features of the supplementary specification and the Vision is that the Supplementary Specification contains information more particular to the technical specialists whereas the Vision is a broader document that is most useful for “management:. Components of the Supplementary Specification Document Human Factors Reliability Performance Adaptability Configurability Implementation Constraints Interfaces Business Rules Legal Issues Text vfisible from at least 1 meter. Clear, step-by-step instructions for use. The consortium computer must keep a transaction record for member banks to use for comparison Each transaction should require less than 1 minute of customer’s time Projected growth rate of the ATM base and member banks. Will use an X.25 based intranet to connect ATMs and member banks with consortium computer Recommend a Linux based consortium server and java as the programming language for ATM client code. Card reader in ATM. Touch screen monitor. Receipt printer. Fee structure charged by member banks.

15. Iteration Plan Time frame for the iteration: Start date: Sept. 15, 2004 End Date: Oct. 6, 2004 Deliverable Artifacts Use cases: Access Account Deposit Withdraw Balance Statement Identify concepts within the ATM network to help develop an initial concept model diagram Identify boundary between system and identified actors Use Case Diagrams Domain Model (Concept Model Diagram) State Diagram Identify states and state transitions for each user initiated button event A simulation demonstrating the user interaction with an ATM terminal Software prototype Test Plan Develop and Execute a Plan to ensure that the various user events do not cause the system to enter an error state or to hangup.

16. Iteration Plan (cont.) Preliminary User Manual Developed Describe the appearance of the screen and the sequence of actions that the user must perform