Requirements Analysis: Process and Techniques

• Requirements Analysis defines the expectations of users for an application, identifying stakeholder needs.
• It involves analyzing, documenting, validating, and managing software or system requirements.
• High-quality requirements should be documented, actionable, measurable, testable, traceable, and defined to facilitate system design.

Requirements Analysis Process involves:

• Eliciting requirements, which means gathering requirements by communicating with customers.
• Analyzing requirements to determine their quality, resolving issues like unclear, incomplete, ambiguous, and contradictory requirements.
• Requirements modeling, documenting requirements in formats like use cases, user stories, or process specifications.
• Reviewing and reflecting on previous iterations of requirements gathering to improve the process.

Requirements Analysis Techniques include:

• Business Process Modeling Notation (BPMN) creates graphs for business processes, simplifying understanding and widely used for process improvement.
• Unified Modeling Language (UML) uses diagrams to specify, visualize, construct, and document software system artifacts and helps in validating software architectural design.
• Flowcharts depict the sequential flow and control logic of related activities, which helps to showcase critical process attributes.
• Data Flow Diagrams visually represent complex systems and processes, describing entities and relationships using standardized notations for identifying shortcomings.
• Role Activity Diagrams represents role-oriented process models, capturing the dynamics and role structure of an organization.
• Gantt Charts provides a visual representation of scheduled tasks and timelines in project planning and help determine start and end dates.
• Integrated Definition for Function Modeling represents the functions of a process and their relationships within an organization.
• Gap Analysis analyzes gaps in software application performance to determine if business requirements are met.

Object-Oriented Design (OOD):

• OOD solves software problems by building a system of interrelated objects
• OOD uses classes, objects, encapsulation, inheritance, and polymorphism to model real-world systems.
• OOD produces system architecture that is modular, adaptable, and simple to understand and maintain.

Importance of Object-Oriented Design (OOD)

• Modularity simplifies development and maintenance by breaking down structures into manageable components.
• Reusability allows objects and classes to be used in different projects, reducing redundancy and saving time.
• Scalability facilitates system growth by enabling the addition of new objects without affecting existing functionality.
• Maintainability simplifies troubleshooting and updates by encapsulating data and behavior within objects.
• Clear Mapping to Real-World Problems makes systems intuitive and easier to understand by modeling software after real-world entities and their interactions.
• Flexibility and Extensibility allows for adapting systems with minimal changes through inheritance and polymorphism.

Object-Oriented Design Fundamental Concepts:

• Encapsulation bundles data (attributes) and methods (functions) into a class, restricting direct component access to prevent interference.
• Abstraction hides complex implementation details, showing only essential object features to manage complexity.
• Inheritance allows a new class to inherit properties and behaviors from an existing class, promoting code reuse and establishing class hierarchy.
• Polymorphism enables objects of different classes to be treated as objects of a common super class, providing a single interface for different data types.
• Composition designs a class using objects of other classes, promoting flexibility and reusability.

Core Object-Oriented Design Principles:

• Single Responsibility Principle (SRP) states a class should have only one reason to change.
• Open/Closed Principle (OCP) states software entities should be open for extension but closed for modification.
• Liskov Substitution Principle (LSP) states subtypes must be substitutable for their base types without altering correctness.
• Interface Segregation Principle (ISP) states clients should not depend on interfaces they do not use.
• Dependency Inversion Principle (DIP) states high-level modules should not depend on low-level modules; both should depend on abstractions.

Modeling Concepts:

• Modeling concept is a structured way of representing and designing systems before implementation.
• Modeling concept involves creating abstract representations to understand, analyze, and communicate system interactions.

Types of Modeling Concepts:

• Structural Models define components and relationships.
• Component Diagrams show Component interactions.
• Class Diagrams defines classes, attributes, methods, and relationships.
• Entity Relationship Diagrams map out data structures and relationships.
• Behavioral Models define interactions and workflows.
• Use Case Diagrams represents user interactions with an application.
• Sequence Diagrams shows component communication overtime.
• State Diagrams models the different states an object can be in and transitions.
• Architectural Models define high-level structure.
• Layered Architecture separates UI, business logic, and data layers.
• Microservices breaks the application into loosely coupled services.
• Client-Server Model defines frontend and backend interactions.
• Event-Driven Architecture uses event notifications for communication.

Unified Modeling Language (UML):

• UML standardizes a modeling language for specifying, visualizing, constructing, and documenting software systems.

UML Diagram Categories:

• Structure diagrams display static structure.
• Behavior diagrams show dynamic behavior.

Structure Diagram Types Include:

• Class diagrams describes object types in a system and their relationships.
• Component diagrams depicts how components are wired to form software systems.
• Deployment diagrams models the physical aspect of an object-oriented software system.
• Object diagram displays instances, including objects values, to show a snapshot of a system at a point in time.
• Package diagrams shows packages and dependencies between them to show different system views.
• Composite structure diagrams show the internal structure of a class.

Relationships are Important:

• Association represents relationships between instances of types.
• Inheritance adds inheritance to ER diagrams.
• Aggregation is a form of object composition in object-oriented design.

Behavior diagrams types include the following:

• Use Case Diagrams describes functionality with use cases and their environment.
• Activity Diagram Graphical representations of workflows of activities for the target system that involves choice, concurrency & iteration.
• State Machine Diagram describes the behavior of systems with states, transitions, and events
• Sequence Diagram models the collaboration of objects based on a time sequence.
• Communication Diagram models the dynamic behavior and focuses on object collaboration rather than time sequence

Interaction Overview Diagram:

• This Diagram focuses on the control flow of interactions.
• An Interaction Overview Diagram can link up the "real" diagrams and achieve high degree navigability between diagrams inside the Interaction Overview Diagram.

Timing Diagram:

• Timing Diagram visually represents the behavior of objects over time.
• It is a special form of a sequence diagram.

UML Class Notation includes:

• Class A representation of concepts that encapsulates state (attributes) and behavior (operations).
• Attributes shown in single partition format.
• Class operations (methods) are shown in a third section.
• • and # symbols denote attribute and operation visibility.

Parameter Directionality:

• In operations direction, parameters specify direction with respect to caller (in, out, inout).

Class Diagrams Perspectives:

• Perspective choice depends on development process stage.
• Conceptual perspective represents domain concepts
• Specification perspective focuses on ADT (Abstract Data Type) interfaces
• Implementation perspective describes interface implementations

Diagram can be interpreted from perspectives:

• Conceptual perspective represents concepts in the domain
• Specification perspective focuses on the interfaces of Abstract Data Types in the software.
• Implementation perspective describes how classes will implement their interfaces.

Relationships between classes:

• Relationships can be association, inheritance, realization, dependency, aggregation, or composition.

Inheritance (or Generalization):

• A generalization is a taxonomic relationship between a more general classifier and a more specific classifier.
• A specific classifier also inherits features of the more general classifier.
• Represents an "is-a" relationship and an abstract class name is shown in italics.

Association:

• Its a structural link between two peer classes.

Cardinality:

• Cardinality is expressed in terms of: one to one, one to many, many to many.

Aggregation:

• The components represents a "part of" relationship.
• Class2 is part of Class1 and has separate lifetimes.

Composition:

• Its a special type of aggregation where parts are destroyed when the whole is destroyed.
• Objects of Class2 live and die with Class1.
• Class2 cannot stand by itself.

Dependency:

• Its a special type of association.
• Exists between two classes if changes to the definition of one may cause changes to the other.

Realization:

• Its a relationship between the blueprint class and the object containing its respective implementation level details.

Purpose of Object Diagram:

• The use of object diagrams is fairly limited, mainly to show examples of data structures.

Object Diagram at a Glance:

• The object diagram shows this relation between the instantiated classes and the defined class, and the relation between these objects in the system.

Links:

• Links tend to be instances associated with associations.

Use Case Diagram at a Glance:

• The Use Case Diagrams are based on defined system.
• The Actor is the System function