Inception in OOAD: Quiz and Flashcards

Inception is the first phase of Object-Oriented Analysis and Design (OOAD) methodology, which involves gathering information and understanding the requirements for a new software project.
The main objective of the inception phase is to establish the scope of the project, identify the stakeholders, and define the initial set of requirements.
Activities involved in the inception phase include:
- Identifying the problem: analyzing the problem that the software is intended to solve.
- Defining the scope: defining the features, functionality, and limitations of the software.
- Identifying stakeholders: identifying the users, customers, and developers involved in the project.
- Establishing project goals and objectives: establishing the goals and objectives of the project, including timelines, budget, and resource requirements.
- Creating the initial requirements: developing the initial set of requirements for the software.

Vision and Business Case: describes the high-level goals and constraints, the business case, and provides an executive summary.
Use-Case Model: describes the functional requirements, including the names of most use cases and their detailed analysis.
Supplementary Specification: describes other requirements, mostly non-functional, including key non-functional requirements that have a major impact on the architecture.
Glossary: includes key domain terminology and data dictionary.
Risk List and Risk Management Plan: describes the risks (business, technical, resource, and schedule) and ideas for their mitigation or response.
Prototypes and proof-of-concepts: clarifies the vision and validates technical ideas.
Iteration Plan: describes what to do in the first elaboration iteration.
Phase Plan and Software Development Plan: provides a low-precision guess for elaboration phase duration and effort.
Development Case: describes the customized UP steps and artifacts for the project.

Requirements are capabilities and conditions needed by a user to solve a problem or achieve an objective.
Types of requirements:
- Functional Requirements: describe the specific functions and features that the software system should perform.
- Non-functional Requirements: specify the characteristics of the software system that are not related to its functionality but are essential for its effective operation.
Categories of requirements:
- User Requirements: describe the needs and expectations of the end-users of the software system.
- System Requirements: describe the hardware and software infrastructure that the software system needs to operate correctly.
- Design Requirements: describe the technical design of the software system.
- Domain Requirements: are the requirements that are characteristic of a particular category or domain of projects.

A use case represents a sequence of actions that the system performs in response to an external event to achieve a specific goal or objective.
Elements of a use case:
- Actors: persons, organizations, or systems that interact with the software system being developed.
- Use Case Name: a concise name that describes the specific functionality of the use case.
- Description: a detailed narrative of the steps involved in the use case.
- Preconditions and Postconditions: describe the conditions that must be true before the use case can be executed and the state of the system after the use case is completed.
Use Case Model: defines the user's objective, the interactions between the system and the user, and the system's behavior required to meet these objectives.
Components of the Basic Model:
- Actor: a person, organization, or system that interacts with the software system.
- Use Case: defines how actors use a system to accomplish a specific objective.
- Associations: define the associations among actors and use cases.

Use Case Diagrams are used to model the behavior of a system, subsystem, or class.
Components of a Use Case Diagram:
- Actors: the users that interact with a system.
- System: a specific sequence of actions and interactions between actors and the system.
- Goals: the end result of most use cases.
Use Case Diagram symbols and notation:
- Use cases: horizontally shaped ovals that represent the different uses that a user might have.
- Actors: stick figures that represent the people actually employing the use cases.
- Associations: a line between actors and use cases.
- System boundary boxes: a box that sets a system scope to use cases.
- Packages: a UML shape that allows you to put different elements into groups.

The library system project involves two users: Librarian and Student.
Both Librarian and Student can perform activities after logging in to the library management system.
Librarian activities: add publication, add books, add branch, add student, issue book, return book, apply penalty, change password, view reports.
Student activities: search book, issue/return book report, penalty report, change password.

An activity diagram visually presents a series of actions or flow of control in a system, similar to a flowchart or data flow diagram.
Activity diagrams are often used in business process modeling.
Symbols used in activity diagrams:
- Activity nodes: represent the different actions or steps in the process.
- Control (Activity) flow arrows: connect the activity nodes and represent the sequence of actions in the process.
- Decision nodes: indicate a branching point in the process, where the flow can follow different paths based on a condition.
- Merge nodes: indicate a point in the process where multiple flows come together into a single flow.
- Swimlanes: used to organize activities and show the different actors or organizations involved in the process.
- Synchronization: used to split a single incoming flow into multiple concurrent flows and join multiple concurrent flows back into a single outgoing flow.
- Flow final nodes: indicate the end of a flow.
- Object nodes: represent objects or entities involved in the process.