AyMINE – Technical documentation
User Modules
Task, project & quality management
Manager approval with the task report
Why some data can't be deleted
Adminitration of areas, projects, calendars
Region / project / methodology
Change management process in a project
GDPR and record of qualifications
Qualification of user or contact
Right to Manage Qualifications
Methodology and Quality Management systems
What a methodology / QMS consists of
Customer Service Response Generation
Objects affected by the problem
Return project plan by baseline
Sample tasks and methodologies of the area
Effect of the task on the right to modify the attached object
The person responsible for the task
Working procedure – task definition
Objects related to the task pattern
Contacts and directories module (CRM)
orderSVG Order overview for customer groups
Web management and automation
Receiving a message from the web
Human resources
Human Resources module security
Manage department / division data
Synchronizing staff and system users
Products, assets and sales
Received order for goods or services
Finance management
Metrics and Measurements
Technical Modules
Sabre plugin module
Enterprise Architect connector
Database link to Enterprise Architect database
System Modules
The AyMINE Framework Module
Configure how your system looks and works
Gestures and Keyboard Shortcuts
More about how the system works
Private notes and tags for objects
Filtering in the list of records
System Management
Securing posts and internal discussions
Additional functions with files
Copying and moving files between objects
Files (documents) linked to the object
Formatted texts in the application
Gateway settings for external messages
IMP gateway settings for email communication
Internet Call Gateway Settings
Requirements
A requirement is both a specification and a solution analysis. AyMINE supports working with requirements according to project and analysis standards
- Input requirements and derived requirements
- Types of requirements
- Requirements analysis
- Requirement states
- Synchronising requests to Enterprise Architect
Requirements are part of the governance in project management. More about what all is included in the project management agenda is here. Requirements are designed so that you can use them to document the assignment, perform analysis, and manage the processing of the entire project.
Input requirements and derived requirements
Project input requirements are requirements that come from the external environment, typically from the customer, the project sponsor, or the team that conceived the project. They are generally called user requirements.
In contrast to input requirements are derived requirements, i.e. those that have arisen in the project as a result of the analysis of how to implement the project. Derived requirements are any requirements that have arisen from input requirements or other input to the project. The typical input that generates requirements is an obligation, a methodology, rarely something else.
Types of requirements
The division into input derived requirements results from how the requirements were generated. A more detailed division, described below, is usually used for derived requirements. Of course, only certain types of requirements make sense in a project, depending on what the purpose (product) of the project is.
- User – These has been already described. These are always input requests
- Systemic – Requirements that concern the whole solution, the system (of course, only if a system is created in the project, so it is still the case)
- Software – Requirements that the software being developed in the project has to/needs to meet. These are not requirements for the software used to implement the project, but the software being created
- Hardware – Requirements to be fulfilled by the electronic part of the project, generally hardware
- Engineering – Requirements to be met by the designs produced or developed in the project. Depending on the type of project, this may be a mechanical component being developed, or perhaps a construction project in progress
- Process – Requirements for the process of implementing the requirement. These are specific requirements for how a particular activity or stage is to be implemented, who is to participate, etc. Note that they should not repeat the methodology by which the project is implemented. Thus, if there is a requirement for a process action, e.g. a review, which is given by the methodology, it should not be necessary to write it again as a process requirement (it can be found as an obligation or sample task in the methodology).
- Tests / Examinations – Requirements for testing, verifying and examining any project deliverables. The requirements should collectively define everything to be performed to verify the quality of the work. (Depending on the methodology, this may include tests of input equipment, e.g., calibration of measuring equipment. However, in most cases, these input checking requirements are directly part of the methodology, or should be process requirements because they are in-process checks, not output checks.)
- Business / Business – Requirements resulting from the business aspect of the project. Typically, these are requirements resulting from business needs (may relate to design, production costs, etc.). Note the distinction between requirements and responsibilities. For example, if the business requirement is that the developed product has a production cost of less than 10€, it is good to understand it as an obligation that the project must meet. This obligation is reflected in all activities from project planning to supplier selection, and cannot be clearly said to be fulfilled by anything.
Requirements analysis
If the requirements and especially the system being developed are complex, it is not possible to develop/implement a project directly based on user requirements. These requirements need to be thought through, broken down according to where, how and by whom they will be implemented and often analysed in more detail. These steps are called analysis. In the analysis, derived requirements are created from the input requirements.
Analytical relationships
- User requirements give rise to system requirements
- From system requirements arise requirements for individual parts of the system, often already divided according to the nature of each part of the system (engineering design – technological part, software, hardware).
- Requirements for parts of the system may further break down into sub-requirements, but it is better to try to avoid this and not create another layer. However, if it is a large system, this may be necessary
- Testing requirements can be both input and derived requirements. If they are derived, they are the result of an analysis of what needs to be verified in order to meet typical quality criteria.
How to document relationships
Relationships are documented with the trace binding. A binding always results in a requirement that gives rise to a new, derived requirement. Bindings are easily created using command buttons in the request details.
Requirement states
Requirement processing is controlled by states. Request states are:
- New – it has not been analysed and it is waiting to be processed
- In Analysis – analysis in progress but not yet completed
- Analyzed – Analysis done but should be validated.
- Verified (verified) – Checked as analyzed. Requirement only gets into the state if it is analyzed by someone other than the person in charge (the person in charge is specified in the request). If it is analyzed directly by the person in charge, the validation step is skipped
- Finished – Analysis done. Finished status does not mean that the analyzed solution is realized, but that the analysis of how to execute is completed
-
Invalid – the requirement cannot be analyzed because something prevents it. Typical reasons why a request is invalid are
*The requirement conflicts with other requirements and therefore cannot all be met- The requirement conflicts with constraints that cannot be changed. E.g. it conflicts with generally applicable regulations or cannot be implemented in the price of the work
-
Rejected – the requirement has been excluded from processing. The reason for the rejection should always be given. Typical reasons for rejection are:
- The requirement is duplicative with another requirement that is being processed.
- The requirement has been made by someone who is not authorized to make the requirement
- Cancelled – the requirement has been cancelled by a decision of the contracting authority
Synchronising requests to Enterprise Architect
Requirements and other analysis elements can be automatically synchronized to the model in Enterprise Architect. The synchronization lets you combine the benefits of web-based access to specifications for the entire project team with the full analytical capabilities of your favorite tool.