V&S, назначение документа

1. Glossary and data glossary
2. User roles and user classes and actors
3. Assumptions, dependencies, limitations
4. Data model

Vision & Scope – описывает требования к проекту, видение решения и различные ограничения.

Состоит из:
http://i.nure.ua/tekhnologiji/1387-gajd-po-sostavleniyu-vision-scope

1. Бизнес требований (Background, Business Opportunities, Business Objectives and Success Criteria)
2. Видения решения (Vision Statement, Major Features, Assumprions Допущения и зависимости также описываются списком. Они могут касаться пользователей (Пример: пользователь может иметь необновлённую версию системы) или вашей системы (Пример: Выход оборудования из строя может привести к потере важных данных).
3. Объем и ограничения (Scope of initial Release, Scope of Subsequent Releases, Limitations and Exclusions)
4. Бизнес контекст (Stakeholder Profiles, Project priorities, Operating Enviroment)

Пример: Скорость передачи изображений будет определяться только состоянием сети. Это assumption .
Когда нужен:

• New Projects: Especially at the start of a new project to set its direction.
• Large and Complex Projects: Where clear communication and alignment are critical.
• Projects with Multiple Stakeholders: To ensure everyone's expectations are aligned.
• Change of Direction: When a project undergoes significant changes in direction or strategy.

Спецификаци к ПО

SRS — структурированный набор требований (функциональность, производительность, конструктивные ограничения и атрибуты) к программному обеспечению и его внешним интерфейсам. Предназначен для того, чтобы установить базу для соглашения между заказчиком и разработчиком (или подрядчиками) о том, как должен функционировать программный продукт.

• Объем работ
• Функциональные требования
• Нефункциональные требования
• Зависимости
• Модель данных
• Предположения
• Ограничения
• Критерии приемки

Структура:

см. тут https://www.youtube.com/@systemsengineering

Glossary

A glossary is a list of terms and their definitions in a particular domain of knowledge. It serves as a reference to ensure consistent understanding of terminology among stakeholders, such as project team members, clients, and end-users. Glossaries are common in many fields, from academic disciplines to technical projects.

Example: In a software development project, the glossary might include terms like "API" (Application Programming Interface), defining it as a set of rules and protocols for building and interacting with software applications, or "Agile," described as a project management methodology focused on iterative development and collaboration.

Data Glossary

A data glossary, on the other hand, is a specific type of glossary focused on data management. It includes definitions of data elements and terms used within an organization's data architecture. A data glossary is crucial for data governance, ensuring that everyone in the organization understands the data in the same way, which promotes data quality and consistency across different departments and systems.

Example: In a company's data glossary, you might find an entry for "Customer Lifetime Value" (CLV), defining it precisely as the total worth to a business of a customer over the whole period of their relationship. It ensures that all departments understand what CLV means in the same way and calculates it consistently.

In conclusion, while both a glossary and a data glossary serve to define terms, their focuses are distinctly different, with the latter specifically aimed at promoting a unified understanding of data across an organization.

User Roles

A user role refers to the specific behavior and set of responsibilities associated with a particular user when interacting with a system. User roles are defined based on what the users can do within the system, their permissions, and their access levels.

Example: In a project management application:

• Project Manager: Can create projects, assign tasks, set deadlines, and monitor progress.
• Team Member: Can view and update the status of tasks assigned to them, log time, and participate in discussions.
• Administrator: Has full access, including user management, system settings, and can view all projects.

User Classes

User classes group users based on common characteristics, needs, or the ways they use the system, rather than their specific individual roles. User classes help in understanding the broad categories of system users to ensure the design accommodates varied user requirements.

Example: For an e-commerce website:

• Casual Shoppers: Users who occasionally visit the site, primarily for browsing without a specific purchase in mind.
• Regular Customers: Users who frequently make purchases and are familiar with the website's navigation and features.
• Business Buyers: Users purchasing on behalf of a company, interested in bulk orders and business discounts.

Actors

In use case and system modeling, an actor represents a role played by an external entity that interacts with the system, typically a user or another system. Actors are used in modeling to identify the external entities that must be considered in system interactions.

Example: In an online banking system:

• Customer: An actor who can log in, view account balances, transfer funds, and pay bills.
• Banking System: An external system actor that processes transactions, updates accounts, and generates statements.
• Administrator: A human actor who can manage user accounts, adjust system settings, and perform maintenance tasks.

Distinctions with Examples

• User Roles vs. User Classes:
• User Role: Focuses on the specific actions and responsibilities a user has within a system (e.g., Project Manager in a project management tool).
• User Class: Groups users based on shared characteristics or interaction patterns with the system (e.g., Casual Shoppers on an e-commerce platform).
• User Roles/Classes vs. Actors:
• User Roles/Classes: These concepts are primarily used for defining and understanding the different types of users and their needs or permissions within the system.
• Actors: Used in use case scenarios to represent anyone or anything (user or system) that interacts with the system, focusing on the interaction boundary rather than internal permissions or characteristics.

Understanding these distinctions is crucial for system analysts and designers to ensure that a system's development accurately addresses the needs of all its users and interacts appropriately with external entities.

Assumptions

Assumptions are statements about the current or future state that are believed to be true but have not been verified. Assumptions are made to move forward with the project planning and execution, even in the absence of complete information.

Example: While planning an online marketplace project, an assumption might be that "The existing customer database can handle the increased load from new online customers without requiring upgrades." This assumption impacts project scope, budget, and timeline.

Dependencies

Dependencies refer to the relationship between tasks or components, where the start or completion of one task/component is reliant on the start or completion of another.

Example: For the development of a new feature in a software application, a dependency might be that "The design team must complete the UI/UX designs before the development team can begin coding." This dependency affects the project schedule and task sequencing.

Limitations

Limitations are constraints or restrictions that may affect the project's scope, delivery, and potential success. These can be related to technology, resources, budget, or other factors that limit the options available for the project team.

Example: A limitation in launching a new mobile application might be "The application will initially only be available for iOS due to budget constraints, delaying access for Android users." This limitation impacts the project's market reach and user adoption at launch.

Summary with Key Distinctions:

• Assumptions are considered true without proof for planning purposes and require validation. For example, assuming that third-party APIs will remain stable during the development of an integration feature.
• Dependencies are about the relationship and sequence between tasks or components, crucial for project planning and execution. An example is the need for the infrastructure team to set up a server environment before deployment can begin.
• Limitations are constraints that restrict project execution or potential. An example might be limited access to skilled developers, affecting the project timeline or the complexity of features that can be developed.

A data model is essentially a blueprint for how data is structured, stored, and accessed within a system. It outlines the relationships between different data elements and defines how data can be manipulated and presented. Think of it as an architectural plan but for data management, instead of buildings.

Why Is a Data Model Necessary?

1. Clarity and Communication: It serves as a visual and conceptual tool, providing a clear way to communicate the structure of the database among developers, database administrators, and business analysts. This shared understanding helps prevent misinterpretations and errors in system development and data handling.
2. Efficiency in System Design and Development: By defining clear rules and relationships for how data is connected and organized, a data model helps in creating more efficient databases. This can lead to faster query responses, more intuitive data manipulation, and easier database maintenance.
3. Data Integrity and Consistency: A well-designed data model enforces data integrity and consistency rules, ensuring that the data stored in the database is accurate, reliable, and reflects the real-world entities it represents. This is crucial for making informed business decisions and maintaining trust in the system.
4. Scalability and Flexibility: As businesses grow and evolve, so do their data needs. A good data model is designed with scalability in mind, allowing for the easy addition of new data elements and relationships without disrupting the existing structure. This flexibility supports the long-term growth and adaptation of the system.
5. Facilitates Data Analysis and Reporting: A logical and well-organized data model lays the foundation for effective data analysis and reporting. It ensures that data is easily accessible and can be combined in various ways to provide valuable insights, supporting strategic business decisions.

Examples:

• E-commerce: For an e-commerce platform, a data model would define how products, orders, customers, and transactions are related. It ensures that when a customer places an order, the system can accurately track which products were ordered, their prices, the customer's information, and the status of the shipment.
• Healthcare System: In a healthcare application, a data model might detail the relationships between patients, doctors, appointments, and medical records. This ensures that doctors can access a patient’s history before an appointment, and any new information added during the visit is correctly linked to the patient’s record.

In summary, data models are fundamental for structuring and managing the data that underpins almost all software applications and systems. They provide a clear framework that guides not only the technical aspects of database design and development but also supports business objectives by ensuring data is accurate, consistent, and usable.