Domain Partitioning Resources

The problem domain^[1] was defined during project initiation^[2] and problem analysis^[3]. The results of this work were captured in a set of models: the use case model, the object model, and the dynamic model. These models form the baseline for the partitioning decisions. The models each reveal something different about the problem domain.

• The use case model: The use case model describes what the users expect to see when they interact with the finished system. These expectations are expressed as goals, like “withdraw money” and “transfer funds.” These goals imply functionality. For example, the user must be able to provide the bank account number and the amount of money to withdraw. The use cases provide the basis for functional partitioning.
• The Object Model: The object model defines the resources of the problem domain. These resources are the information that the system must manage in order to support the use cases. The use cases may create or alter the resources. At the very least, the use case must have access to the information that the objects own. Consequently, the object model is partitioned to coincide with the functional partitions.
• The Dynamic Model: The dynamic model includes two types of interaction diagrams: the sequence diagram^[4] and the collaboration diagram^[5]. Both diagrams illustrate how objects talk to one another. The interaction diagrams describe the communication between the participating objects and thus provide valuable information about the attributes and interfaces of the participating domain objects. When the object model is partitioned, the associations between objects must be preserved because they translate into dependencies between partitions.

Creating a System Requirement Specification (SRS) document using UML diagramming tools involves several steps. UML (Unified Modeling Language) diagrams help in visualizing, specifying, constructing, and documenting the artifacts of a software system. Here’s a step-by-step guide on how to create an SRS document using UML:
Step-by-Step Process

1. Understand the System Requirements:
   • Gather requirements from stakeholders through meetings, interviews, surveys, and observations.
   • Document functional and non-functional requirements.
   • Identify user roles and use cases.
2. Define the Scope:
   • Clearly define what the system will do and what it will not do.
   • Establish the boundaries of the system.
3. Identify Key Use Cases:
   • List all the major use cases that the system will handle.
   • Each use case should represent a specific functionality or interaction with the system.
4. Create Use Case Diagrams:
   • Use case diagrams represent the interactions between users (actors) and the system.
   • Draw actors and use cases and show the relationships between them.
   • Example tools: Lucidchart, Visual Paradigm, Enterprise Architect.
5. Detail Use Cases:
   • Write detailed use case descriptions for each use case, including the main flow, alternate flows, preconditions, and postconditions.
6. Create Class Diagrams:
   • Class diagrams show the static structure of the system, including classes, attributes, methods, and relationships.
   • Identify key classes from the use cases and define their attributes and methods.
   • Show relationships (associations, generalizations, dependencies) between classes.
7. Create Sequence Diagrams:
   • Sequence diagrams depict how objects interact in a particular scenario of a use case.
   • Show the sequence of messages exchanged between objects to accomplish a specific goal.
8. Create Activity Diagrams:
   • Activity diagrams illustrate the flow of activities within a system.
   • Show the sequence of actions or control flows for different processes within the system.
9. Create State Diagrams:
   • State diagrams represent the states of an object and transitions between those states.
   • Useful for modeling the behavior of classes that have significant state-dependent behavior.
10. Create Component Diagrams:
    • Component diagrams show the organization and dependencies among components.
    • Identify the major software components and their interactions.
11. Create Deployment Diagrams:
    • Deployment diagrams illustrate the physical deployment of artifacts on nodes.
    • Show the hardware and software configuration of the system.
12. Document Non-Functional Requirements:
    • Specify performance, security, usability, reliability, and other non-functional aspects of the system.
13. Review and Validate:
    • Review the diagrams and specifications with stakeholders to ensure accuracy and completeness.
    • Validate the requirements and diagrams against user needs and expectations.
14. Compile the SRS Document:
    • Assemble all the diagrams and detailed descriptions into a comprehensive SRS document.
    • Include sections such as Introduction, Overall Description, System Features, Non-Functional Requirements, and Appendices.

Example Structure of an SRS Document

1. Introduction:
   • Purpose
   • Scope
   • Definitions, Acronyms, and Abbreviations
   • References
   • Overview
2. Overall Description:
   • Product Perspective
   • Product Functions
   • User Characteristics
   • Constraints
   • Assumptions and Dependencies
3. System Features:
   • Detailed Use Cases
   • Use Case Diagrams
   • Sequence Diagrams
   • Activity Diagrams
4. Data Requirements:
   • Class Diagrams
   • Data Flow Diagrams
5. Behavioral Requirements:
   • State Diagrams
6. Architectural Requirements:
   • Component Diagrams
   • Deployment Diagrams
7. Non-Functional Requirements:
   • Performance Requirements
   • Security Requirements
   • Usability Requirements
   • Reliability Requirements
8. Appendices:
   • Glossary
   • References
   • Index

Conclusion Creating an SRS document using UML diagramming tools involves a structured approach to understanding and documenting system requirements. UML diagrams provide a visual representation of various aspects of the system, making it easier to communicate requirements and design decisions with stakeholders. By following these steps, you can create a comprehensive SRS document that serves as a blueprint for the development and implementation of the software system.

[1]Problem domain: The area of the business that is under evaluation during a discussion or project.

[2]Project initiation: The first phase of the project life cycle in which the clients establish their expectations for the system.

[3]Problem analysis: This is the second phase of the project life cycle in which the analyst researches the resources of the problem domain and defines their purpose and interfaces.

[4]Sequence diagram: The UML diagram designed to model the interaction between objects overtime. The scope of the diagram is typically a single scenario.

[5]Collaboration diagram: One of the two UML standard interaction diagrams designed to model the communication between objects.