Requirements Analysis

This is a summary of the training course of the Requirements Analysis

• Module Focus:

  • Business Analysis
  • Requirements Analysis

Business Analysis:

- Understand and describe a company's processes.
- Example: Life cycle of entities (e.g.: order or book status).

Requirements Analysis:

- Specify the system's functionalities.
- Example: Use cases (user interaction with the system).

Process to build a software:

The software development process involves disciplines and subprocesses, such as analysis, design, construction and validation.

• Analysis: Describes the problem.
• Design: Describes the solution.
• Construction: Implements the solution.
• Certification: Tests and validates the solution before delivery.
• The waterfall model follows a linear sequence, where each step is completed before moving on to the next.
• The waterfall model is best suited for areas such as civil engineering, but is not ideal for software development, which is more dynamic and cyclical.

• The unified process is a framework created by Booch, Rumbaugh and Jacobson, which organizes the disciplines in an iterative and incremental manner.
• The unified process divides development into phases: initiation, elaboration, construction and transition.
• The disciplines (business modeling, requirements, analysis, design, implementation, testing, etc.) are applied in different intensities throughout these phases.
• The unified process is iterative and incremental, meaning that disciplines are applied repeatedly in cycles, with continuous improvement.
• Variants of the unified process include the Rational Unified Process (RUP), OpenUP, and Agile Unified Process (AUP).
• Analysis is a subprocess that describes the problem and is part of an incremental process in software development.

• Comparison with Building Construction:

  • Stages: Analysis (understanding the problem), Design (solution design), Construction (implementation), Homologation (validation).

Artifacts in Business Analysis:

• Business process specification document.
• Entity life cycle.

Artifacts in Systems Analysis:

Requirements Analysis:

• Overview of the system (free document).
• Overview of use cases (diagram).
• Specification of use cases (structured document).

Domain Analysis:

• Conceptual model (data model at the analysis level).

Difference between Artifact and Tool:

• Artifact: what you want to specify (e.g. business process).
• Tool: means used to specify (e.g. UML activity diagram).

Examples of Tools:

• Activity diagram (UML) to specify the flow of actions of the business process.
• State machine diagram (UML) for the life cycle of entities.
• Use case diagram (UML) for an overview of use cases.
• Class diagram (UML) for the conceptual model.

Free and Structured Documents:

• System overview: free document.
• Use case specification: structured document.

Importance of Differentiating Artifact and Tool:

• The artifact is the final product (e.g., business process).
• The tool is just a means to create the artifact (e.g., activity diagram).

Definition of Information System:

• Organizational system used to collect, store and disseminate data.
• Used by companies and organizations to automate business processes.

Characteristics of Information Systems:

• Database with business information.
• Forms, reports and process automation (e.g.: purchases, inventory, employees).

Information Systems Analysis Process:

• Focused on systems for companies and organizations.
• Main subprocesses:
  • Business Analysis: Understanding and describing the business, its rules and processes.
  • Systems Analysis: Understanding the needs and requirements to build the system.

Subdivisions of Systems Analysis:

• Requirements Analysis: Identify what the system needs to do.
• Domain Analysis: Understand the context and environment of the system.

Objective of Information Systems:

• Automate parts of business processes, making them more efficient.
• Example: Automate calculations and payroll generation in the financial sector.

Importance of Business Analysis:

• Understanding the business is a prerequisite for specifying an appropriate system.
• Although it is not a systems analysis, business analysis is essential to the process.

Requirements Overview

Definition of Requirements

• A requirement is a condition or characteristic that the system must meet.
• The classification of requirements varies depending on authors and schools of thought.

Types of Requirements

1. Functional Requirements

• Involve data manipulation (e.g., database operations, queries, saving, etc.).
• Subcategories:
  • With User Interaction:
    • Use Cases:
      • CRUD: Create, Retrieve, Update, Delete (registration screens).
      • Reports: Generate listings or reports based on input arguments.
      • Business Processes: Automation or semi-automation of business processes.
  • Without User Interaction:
    • Batch Processing: Scheduled tasks (e.g., nightly jobs).
    • System Integrations: Data manipulation and information exchange between systems.
    • Internal Processing: Internal operations without user interaction.

2. Non-Functional Requirements

• Do not involve data transformations.
• Also referred to as "quality requirements."
• Examples:
  • Usability: Intelligibility, ease of use.
  • Reliability: Fault tolerance (e.g., resuming processing after an internet outage).
• Classifications:
  • Forbes Mais.
  • ISO 9126 (internal and external quality).
• Observations:
  • Classifications are not mutually exclusive (a requirement can belong to more than one category).
  • Requirements should be organized into topics in the document.

Final Considerations

• Classifications serve as guidance and help organize the requirements document.

Understanding Use Scenarios and Use Cases

Basic Concepts

• System Requirements:
  • Divided into functional and non-functional requirements.
  • Use cases are part of functional requirements.
• Usage:
  • Interaction between actors and the system.
• System Actors:
  • Users who interact with the system (e.g., anonymous user, client, administrator, operator).
  • Interaction = exchange of information (inputs and outputs).

Use Scenario

• Definition:
  • A linear sequence of interactions between actors and the system.
  • Does not include branches, conditions, or loops (e.g., "if", "else").
• Example: Use Scenario "Sell Book":
  1. Input: User provides their identification (e.g., login).
  2. Output: System displays available books (title, cover, price).
  3. Input: Client selects the books they want to purchase.
  4. Output: System informs the total value and presents registered address options.
  5. Input: Client selects the delivery address.
  6. Output: System informs the shipping cost, total amount, and list of registered credit cards.
  7. Input: Client selects a credit card.
  8. Output: System sends the card details and purchase value to the payment processor.
  9. Input: Payment processor provides an authorization code.
  10. Output: System informs the delivery time.

Actors in the Scenario

• Anonymous User: Before identification.
• Client: After identification.
• Payment Processor: Interacts with the system to process the payment.

Differentiation

• Use Scenario:
  • A linear sequence of steps.
  • Does not include branches or error handling.
• Use Case:
  • Includes alternative scenarios, such as registering a new address or handling errors (to be covered later).

Conclusion

• A use scenario is a linear sequence of interactions between actors and the system.
• Use cases are broader and include alternative scenarios.

Understanding Use Case Scenarios

Definition of a Use Case

• A use case is a set of interrelated usage scenarios aimed at a specific objective.
• It includes:
  • Main Scenario: The ideal flow where everything works as expected.
  • Alternative Scenarios: Different paths or exceptions that may occur.

Example of a Use Case

• Use Case: Selling a Book
  • Main Scenario: A linear sequence of steps to sell a book.
  • Alternative Scenarios: Different paths or exceptions, such as invalid identification.

Components of a Use Case

. Main Scenario:

• The ideal sequence of steps. . Exception Scenarios:
• Handle errors, such as invalid identification. . Variant Scenarios:
• User options, such as registering a new address.

Numbering Alternative Scenarios

• Alternative scenarios are numbered based on the step in the main scenario that caused the deviation.
• Example:
  • Exception 1A: Occurs at step 1 of the main scenario.

Data Specificity

• Each step must detail the required information (e.g., street, number, ZIP code).
• This helps developers create accurate screens and functionalities.

Use Case Utility

. Design:

• Guides designers in defining operations and API endpoints. . Implementation:
• Helps developers ensure all requirements are met. . Testing:
• Assists analysts in designing tests aligned with the data and flows.

Use Case as a Contractual Tool

• Demonstrates the complexity of the operation.
• Facilitates cost estimation and pricing for clients.

Complete Example

• Main Scenario:
  • A detailed sequence of steps.
• Exception Scenarios:
  • Example: Exception 1A - Invalid identification.
    • Step 1A.1: The system informs the user that the identification is invalid.
    • Step 1A.2: The system requests the user to re-enter their identification.
• Variant Scenarios:
  • Example: Variant 4.1 - Register a new address.
    • Step 4.1.1: The user provides street, number, complement, ZIP code, city, and state.
    • Step 4.1.2: The process returns to step 6.

Key Notes

• Always specify the data required in each step.
• Ensure clarity for developers to implement the correct functionality.

Documentation: Attributes of a Use Case

This document describes the main attributes of a use case, based on best practices for system modeling.

Attributes of a Use Case

1. Interactivity

• A use case must involve information exchange between the system and the actors.
• Complementary steps can be included for better understanding, but the main focus should be on the exchange of information.

2. Single Session

• The use case must occur within a single session of system use.
• Session: the time interval during which the user is using the system.
• Example: the user starts an operation, performs the necessary actions, and finishes without interruptions.
• Complex operations that require more than one session should be divided into multiple use cases.

3. Consistent Result

• The system must start and finish the use case in a consistent state.
• There must be no pending operations or incomplete calculations at the end of the use case.
• Even in case of failure or abortion, the system must remain consistent.

Examples of Use Cases

• Making a purchase: the user selects items, makes the payment, and completes the purchase in a single session.
• Registering a payment: the user enters payment details and confirms the operation, leaving the system in a consistent state.

---

Conclusion

Following these attributes ensures that use cases are well-defined, promoting clarity and consistency in system development.

Documentation: Use Case Diagram vs. Use Case Detailing

This document explains the key differences between a use case diagram and the detailing of use cases, based on best practices for system modeling.

Key Differences

1. Use Case Diagram

• Provides a high-level overview of the system.
• Displays the actors and the use cases.
• Acts as a panoramic view of the system's use cases.

2. Use Case Detailing

• Contains the true value of the use case.
• Describes the steps and the information exchanged between the user and the system.
• Focuses on best practices and techniques to create effective use cases.

3. Importance of Differentiation

• It is crucial to understand that the diagram is only a high-level overview, while the detailing provides deeper and more practical insights.

Next Steps

• Learn how to create use case diagrams to express the system's overall view.
• Study how to effectively detail use cases using best practices and techniques.

---

Conclusion

Understanding the distinction between use case diagrams and their detailing ensures clarity in system modeling and helps in creating effective use cases.

Documentation: Overview of Use Case Diagrams

This document provides an overview of use case diagrams, their purpose, and how they are used to represent the use cases of a system.

Overview of Use Case Diagrams

1. Purpose of the Use Case Diagram

• The use case diagram is a graphical tool used to present a high-level overview of the system's use cases.
• It is part of the UML (Unified Modeling Language) and is designed to be simple and easy to understand.

2. Key Components

• Use Cases: Represented as ellipses with names, typically starting with a verb.
• Actors: Represented as stick figures (users or systems interacting with the use cases).
• Relationships: Lines connecting actors to the use cases they interact with.

3. Example: Flight Reservation System

• Use cases include:
  • Search for flights.
  • Cancel reservation.
  • Register flight.
  • Search for airplanes.
  • Book flight.
  • Perform flight upgrade.
• These use cases represent the main functionalities of the system.

4. Characteristics of Use Case Diagrams

• Simplicity: A straightforward graphical tool that does not require technical expertise to understand.
• Analysis Specification: Focused on describing the problem, not on technical implementation.
• Accessibility: Designed to be understood by business stakeholders and non-technical users.

5. Purpose in Analysis

• The use case diagram is used to:
  • Represent the use cases (ellipses).
  • Identify the actors (stick figures) interacting with the use cases.
  • Show the relationships between actors and use cases.

---

Conclusion

Use case diagrams are a simple yet powerful tool for representing the high-level functionalities of a system. They are accessible to both technical and non-technical stakeholders, making them an essential part of the analysis phase in system design.

Documentation: Use Case Diagram - Basic Palette Items

This document provides an overview of the basic palette items used in a use case diagram and an example of their application in a flight reservation system.

Overview of Basic Palette Items

1. Key Elements of the Diagram

• Use Case: Represented by ellipses.
• Actor: Represented by a stick figure.
• Interaction: Represented by a line connecting actors and use cases.
• System: Represented by a rectangle that delimits the system or module being specified.

2. Example: Flight Reservation System

Use Cases and Interactions:

• Search Flights:
  • Actors: User (anonymous), Client, and Agent.
  • Interaction: All three actors interact with the "Search Flights" use case.
• Cancel Reservation:
  • Actor: Client.
  • Interaction: Only the client interacts with the "Cancel Reservation" use case.
• Book Flights:
  • Actors: Client and Agent.
  • Interaction: Both interact with the "Book Flights" use case.
• Register Flights:
  • Actor: Secretary.
  • Interaction: Only the secretary interacts with the "Register Flights" use case.

3. Purpose of the Diagram

• Provide a high-level overview of the interactions between actors and use cases.
• Focus on who interacts with what in the system.
• Keep it simple and easy to understand without delving into details.

---

Conclusion

The use case diagram is a straightforward tool to visualize the relationships between actors and use cases in a system. By using basic elements such as ellipses, stick figures, lines, and rectangles, it provides a clear and concise representation of the system's functionality.

Generalization in Use Case Diagrams

Overview

This document explains the concept of generalization in UML use case diagrams, as discussed in the lesson.

What is Generalization?

Generalization in use case diagrams works similarly to inheritance in object-oriented programming. It allows actors to inherit behaviors and interactions from a more general actor.

Example:

• Client is a User:
  • The client can access everything a user can, plus additional specific functionalities.
• Agent is a User:
  • The agent can access everything a user can, plus additional specific functionalities.

Benefits of Generalization

• Simplifies the Diagram:
  • By using generalization, the number of lines in the diagram is reduced.
  • Example:
    • Since both client and agent inherit from the user, they automatically interact with the use cases associated with the user.
    • No need to draw separate lines between client/agent and the use cases (e.g., "Search Flights").

How to Read Generalization Relationships

• The relationship is read as:
  • Client is a User.
  • Agent is a User.
• This is similar to the inheritance concept in object-oriented programming.

Key Takeaways

• Generalization helps to organize and simplify use case diagrams.
• It reduces redundancy by grouping shared behaviors under a general actor.
• The relationship is intuitive and follows the "is-a" principle.

---

Example Diagram:

• Actors: User, Client, Agent.
• Use Case: "Search Flights".
• Generalization:
  • Client and Agent inherit from User.
  • No need to draw separate lines between Client/Agent and "Search Flights".

---

Thank you for reading! Feel free to contribute or ask questions.

Extend Relationship in Use Case Diagrams

Overview

This document explains the extend relationship in UML use case diagrams, as discussed in the lesson.

What is the Extend Relationship?

The extend relationship is used to indicate that one use case optionally extends the functionality of another use case. It is represented by a dotted arrow with the label <<extend>>.

Key Characteristics:

• The arrow points from the extending use case to the base use case.
• The extending use case represents optional functionality that occurs in specific scenarios of the base use case.

When to Use the Extend Relationship?

Use the extend relationship when:

• The extending use case is not always executed as part of the base use case.
• The functionality it provides is optional and depends on specific conditions.

Example:

• Base Use Case: "Reserve Flight".
• Extending Use Case: "Upgrade Flight".
• Explanation:
  • A user commonly reserves a flight.
  • Occasionally, the user may choose to upgrade the flight, which is an optional action.
  • The relationship is represented as: Upgrade Flight extends Reserve Flight.

How to Read the Extend Relationship?

The relationship is read as:

• "Upgrade Flight extends the functionality of Reserve Flight."

Scenarios

• There must be scenarios in the base use case where the extending use case is not executed.
• In the detailed steps of the base use case, there should be an indication of the possibility to execute the extending use case.

---

Example Diagram

• Base Use Case: Reserve Flight.
• Extending Use Case: Upgrade Flight.
• Relationship: Upgrade Flight extends Reserve Flight.

---

Key Takeaways

• The extend relationship is used to represent optional functionality in use case diagrams.
• It simplifies the representation of scenarios where additional actions may or may not occur.
• The relationship is intuitive and helps to clarify optional interactions in the system.

---

Thank you for reading! Feel free to contribute or ask questions.

Include Relationship in Use Case Diagrams

Overview

This document explains the include relationship in UML use case diagrams, as discussed in the lesson.

What is the Include Relationship?

The include relationship is used to indicate that one use case always includes the execution of another use case during its process. It is represented by a solid arrow with the label <<include>>.

Key Characteristics:

• The arrow points from the base use case to the auxiliary use case.
• The auxiliary use case is mandatory and will always be executed as part of the base use case.

Differences Between Include and Extend

. Direction of the Arrow:

• In the include relationship, the arrow starts from the base use case and points to the auxiliary use case.
• In the extend relationship, the arrow points to the base use case. . Obligation:
• In the include relationship, the auxiliary use case is mandatory.
• In the extend relationship, the extending use case is optional.

Example

• Base Use Case: "Register Flight".
• Auxiliary Use Case: "Search Aircraft".
• Explanation:
  • Whenever the secretary executes "Register Flight", they must always execute "Search Aircraft" as part of the process.
  • However, "Search Aircraft" can also be executed independently, without being tied to "Register Flight".

How to Read the Include Relationship?

The relationship is read as:

• "Register Flight includes the functionality of Search Aircraft."

Why Represent It in the Diagram?

Although "Search Aircraft" is included in "Register Flight", it is also an independent use case. For example:

• The secretary can log into the system, search for an aircraft, and exit without registering a flight.

---

Key Takeaways

• The include relationship is used to represent mandatory functionality in use case diagrams.
• It ensures clarity in scenarios where a use case depends on another but also allows for independent execution of the auxiliary use case.
• The relationship helps to simplify and organize the representation of system interactions.

---

Thank you for reading! Feel free to contribute or ask questions.

Lesson Theme: Detailing System Use Cases

Definition of Detailing:

• Also known as use case expansion.
• Specifies the steps of interaction between users and the system.
• Includes:
  • Main Scenario: A list of primary steps.
  • Alternative Scenarios:
    • Exceptions: Error handling.
    • Variants: User options (not errors).

Forms of Description:

. Textual Structured Description (Preferred):

• Simple and straightforward.
• Specifies inputs and outputs of information. . Tabular Description:
• One column for the actor and another for the actions performed.
• Details the information exchanged in each step. . Graphical Description:
• Uses activity diagrams (action flow diagrams).
• Can become overloaded with too much information.

Considerations:

• Specification should be quick and agile to save time.
• UML does not define a standard for the textual description of steps.
• Best practices will be covered in future lessons.

Use Case Documentation Template

This repository provides a basic template for describing use cases. The template includes the main sections and guidelines to ensure clarity and completeness when documenting functional requirements.

Template Overview

1. Actors and Stakeholders

• Identify the actors involved in the use case.
• Specify stakeholders, such as departments or other interested parties (e.g., Marketing Department).

2. Preconditions and Postconditions

• Preconditions: Conditions assumed to be true before the use case starts (e.g., operator logged into the system).
• Postconditions: Conditions assumed to be true after the use case ends successfully (e.g., book sold).

3. Overview

• A brief explanation of the use case to help with quick identification and understanding.
• Can be used for cost estimation purposes.

4. Main Success Scenario

• The most common sequence of steps where everything works as expected without errors.

5. Alternative Scenarios

• Variants: Different options the user can follow.
• Exceptions: Error scenarios and how they are handled.

6. Additional Information

• Include complementary details such as:
  • Screen prototypes.
  • Related requirements or business rules.
  • Mathematical formulas or expressions.
  • Technological variations (e.g., mobile vs. desktop behavior).
  • Open questions (e.g., pending decisions about payment methods like PIX or credit card).
  • Detailed descriptions of data if too extensive to include in the main steps.

Example Use Case Structure

# Use Case: [Use Case Name]

## Overview
A brief description of the use case.

## Actors
- [Actor 1]
- [Actor 2]

## Stakeholders
- [Stakeholder 1]
- [Stakeholder 2]

## Preconditions
- [Precondition 1]
- [Precondition 2]

## Postconditions
- [Postcondition 1]
- [Postcondition 2]

## Main Success Scenario
. [Step 1]
. [Step 2]
. [Step 3]

## Alternative Scenarios
### Variants
- [Variant 1]
- [Variant 2]

### Exceptions
- [Exception 1]
- [Exception 2]

## Additional Information
- [Prototype links, business rules, or other relevant details]

Use Case Steps Documentation

This document provides an overview of the types of steps used in use cases, their purpose, and examples.

Step Types in Use Cases

1. Mandatory Steps

Mandatory steps represent the exchange of information between actors and systems. These steps are essential for the success of the project and must be included to clarify the required interactions.

• Prefixes:
  • IN: Input (e.g., user provides data).
  • OUT: Output (e.g., system returns results).

Examples:

. Step 1 (Input): The user provides a movie title and a range of years. . Step 2 (Output): The system displays a list of movies with their codes and titles. . Step 3 (Input): The user selects an item from the list. . Step 4 (Output): The system displays detailed information about the selected movie (e.g., code, title, duration, year, and total cost).

---

2. Complementary Steps

Complementary steps do not involve information exchange but help clarify the context of the use case.

Examples:

. "Operator accesses the use case":

• Optional step to indicate the start of the use case. . "Go to step X":
• Clarifies the flow, especially in alternative scenarios. . "Use case aborted":
• Indicates the termination of the use case due to an error. . "Administrator chooses an option":
• Specifies variant scenarios (e.g., insert or update).

---

3. Improper Steps

Improper steps include internal system processes and are not recommended for use cases. These steps do not involve user interaction and should be avoided to keep the use case focused on inputs and outputs.

Examples:

. "The system calculates a fine":

• Internal processing, irrelevant to the use case. . "The system saves data to the database":
• Technical detail that does not add value to the use case.

---

Best Practices

• Focus on user interactions and the exchange of information.
• Avoid including internal system processes in the use case steps.
• Use complementary steps only when necessary to clarify the flow or context.

---

Writing Style Guidelines

This document outlines best practices and mandatory rules for writing use cases and system descriptions.

Best Practices

1. Maintain Consistency

• Always follow a consistent structure for describing inputs and outputs.
• Example:
  • Input: "The actor provides the following data."
  • Output: "The system presents the following data."

2. Focus on Information Exchange

• Use cases should describe the exchange of information between actors and systems.
• Avoid unnecessary details about interfaces or technologies.

3. Use Essential Verbs

• Use verbs that describe core functionalities, such as:
  • informs, selects, presents.
• Avoid technology-specific terms like:
  • clicks, swipes, prints.

4. Avoid Conditionals in Scenarios

• Do not use "if" or "else" in scenario steps.
• Scenarios should be linear and free of flow deviations.
• Use alternative scenarios to describe different conditions.

5. Optional Steps

• Optional data can be described as:
  • "The user optionally provides the phone number."

6. Avoid Consecutive Steps

• Combine multiple input or output steps into a single step when possible.
• Example:
  • Instead of:
    1. "The user provides their name."
    2. "The user provides their phone number."
    3. "The user provides their dependents' names."
  • Use:
    • "The user provides their name, phone number, and dependents' names."
• Exception: When a step can generate an exception (e.g., CPF validation).

Examples

Good Example

• "The buyer provides their name, CPF, and email."

Avoid

• "The buyer fills in their name, CPF, and email on screen XYZ."

Good Example for Optional Data

• "The user optionally provides their phone number."

Avoid Conditionals

• Instead of:
  • "If the stock is available, the system updates the cart."
• Use:
  • "The system updates the cart (alternative scenarios handle stock unavailability)."

---

By following these guidelines, use cases will be clearer, more consistent, and easier to use for analysis, design, implementation, and testing.

Happy writing!

DS Delivery - Week Dev Superior

Welcome to the DS Delivery project! This repository contains the source code and documentation for the application developed during the Week Dev Superior event. The project focuses on creating a delivery system with features like order registration, location tracking, and map integration.

Overview

The DS Delivery project was designed to provide a hands-on learning experience for students and professionals. It covers the entire development process, from initial requirements to deployment, and aims to help participants build a portfolio-ready application.

Key Concepts

1. Premises

• A list of initial objectives that guide the system's conception.
• Example: "The system must support order registration and delivery tracking."

2. Scope

• Defines what is included and excluded in the system.
• Example: "The system will include order registration but will not handle payment processing."

3. Wireframe

• An initial sketch of the system's screens.
• Used to support the initial conception and serve as a base for UI/UX design.

Use Cases

1. Register Order

. The system displays a list of products (name, price, description, photo). . The customer selects products and provides a delivery location. . The system generates and displays an order code.

2. Deliver Order

. The system displays a list of pending orders (code, total value, time, items). . The delivery person selects an order. . The system displays a map with the delivery route. . The delivery person marks the order as delivered.

Wireframe

The wireframe was created using Figma and includes:

• Home Screen: Navigation bar, logo, and "Place Order" button.
• Order Screen: Product catalog with name, price, description, and photo.
• Map Screen: Displays the delivery location and route.

Final Design

The final design was developed by a professional designer and includes:

• Differentiation for selected items.
• Responsive layouts for mobile and desktop.
• Enhanced UI/UX for a seamless user experience.