FAQ

Yes, once a new user signs-up they will be added to our onboarding process which will provide them with relevant content and details on the software.

You are able to book a demo here.

Alternatively, you can watch our demo videos here.

Requiment doesn’t work offline, therefore an internet connection will be required.

Requiment requirements gathering software guides you through prepared questions to determine a full and detailed requirement specification and project scope based on outcomes. This application acts as a virtual business analyst, guiding users through the requirements process, whilst providing insight and recommendations to the user based on the type of application being designed as well as trends from other users.

Ultimately, our mission with Requiment is to make the process of software requirements capture more accurate, agile and efficient leading to more successful projects.

Requiment guides you through pre-prepared questions to determine a full and detailed requirement specification and project scope based on outcomes.​ The software will speed-up the process, allow easy tracking, save time and money.

Yes, Requiment is suitable for small businesses, large enterprises and individual users.

Requiment is compatible on desktop, laptop and tablet and works on Chrome, Edge and Safari.

Yes, there is a 14-day free trial available for new sign-ups.

Head over to our sign-up page for more details.

A full set of demo videos are available to view to help you get started with Requiment.

For support, please email support@fieldimp.com.

Guided Process

By following a structured format, your project will begin to take shape and include all the details you need to fully understand it. AI is used to help define the entities of your project.

Output Reports

Requiment produces a Word document from your inputs, providing easy and shareable overview of your project

Create Wireframes

Automatically generate wireframes from your requirements at the click of a button.

Update Easily

Update any aspect of your project at any time and easily generate a new document, eliminating the risk of misunderstandings or miscommunication.

Task Generation

Requiment task generation uses your requirements to generate the tasks required in order to build your project, helping it to remain on track and save time.

Yes, Requiment’s Task feature is fully integrated with Atlassian Jira Boards, watch our video on how to do this here.

Databases are updated regularly (on a weekly, monthly and yearly basis), ensuring we are in a position to easily restore any lost data.

Yes. Multiple users are able to edit the same requirements document.

Software development companies

Define software requirements for custom-built systems and products.

Guides users through the process.

Formalises requirements so your team and your clients stay on the same page.

Businesses and start-ups

Define your requirements and understand what you are looking for in a system.

No experience required, Requiment can guide you through the process.

Produces a full requirement spec, allowing you to then source a partner to implement your vision.

Public sector organisations

Can help produce detailed requirements specifications included in tender documents.

Reduces ambiguity in submitted proposals and ensures bidding companies are clear on what is involved.

Internal software development teams

A requirements gathering software provides a centralised platform for all stakeholders, including business analysts, project managers, developers, and clients, to collaborate and communicate effectively. This reduces miscommunication and ensures everyone is on the same page regarding project goals and expectations.

Requiment allows for structured documentation of project requirements, user stories, use cases, and other essential project details. Clear documentation helps in avoiding ambiguity and ensures that everyone involved understands the project scope and objectives.

Requiment includes traceability features that link requirements to specific project outcomes, test cases, and deliverables. This traceability helps in ensuring that each requirement is adequately addressed and tested during development.

Visit our pricing page for a full breakdown on the packages available

Credit or Debit Card details are not necessary to sign-up for the Requiment 14-day trial. At the end of the trial, payment card details are required to begin your subscription and continue using Requiment.

Unless otherwise stated by us or required by law. All payment obligations are non-cancellable and all amounts paid are non-refundable. Subscription to Requiment can be cancelled at any time to avoid the next payment being taken. Access will end after the last paid for period has ended.

A subscription can be upgraded/downgraded/changed at any time during the subscription period. You can add more users to a subscription, change tier (Bronze/Silver currently available), and change whether you require monthly or yearly billing.

Cancelling a subscription can be done from the ‘Manage Subscription’ page in Requiment. For full details on how to cancel a Requiment subscription, download our guide: Subscription Cancellation

Contact info@fieldimp.com.

Contact support@fieldimp.com.

Yes, we’ll maintain Requiment, fixing bugs and providing updates where necessary and this is included in the subscription.

Requiment utilises Amazon Web Services to store the data held in Requiment, making use of DynamoDB database tables and S3 Buckets, both of which AWS holds to a high security standard. We also make use of IAM and Cognito for user directory and authentication server. We also make sure to adhere to industry standards for data protection. More on this can be found here.

Please refer to Requiment’s privacy policy. We also follow standard GDPR rules.

Requirements gathering is the process of identifying and documenting the needs and expectations of stakeholders for a particular project or system. This process helps to ensure that the final product or solution meets the needs of all stakeholders and is aligned with the overall goals and objectives of the organisation.

It involves a range of activities, such as conducting interviews and focus groups, analyzing existing systems and processes, and creating user stories or functional requirements. The outcome of the requirements gathering process is a set of clear and well-defined requirements that can be used as the foundation for designing, building, and testing the final solution.

Project requirements are typically divided into two groups:

• Business requirements: What the project should accomplish. These are also known as “functional requirements.”
• Technical requirements: How your project will meet organisational needs. These are also known as “nonfunctional requirements.”

What is required of the product is laid out in a requirement document. The product vision and the means by which it must be realised by the project’s conclusion are among the items it specifies. However, it makes no mention of how it will be supplied in detail. More emphasis should be placed on setting the product’s context, such as the necessity for the product or the issue it resolves. There are no specifics about how it will carry out this.

Using software for requirements gathering can benefit the process by improving discovery of requirements, standardising the process and improving its quality, creating more accurate and clear documentation, and facilitating collaboration among stakeholders. Software can be more flexible in the workflow of requirements gathering and provide features beyond simple templates. It can also ensure that a consistent and structured process is followed, making the organisation more resilient to staff changes and resulting in better quality requirements gathering.

By having a clear and accurate document outlining the requirements of a project, stakeholders and the development team can reduce the chance of missing vital requirements, improving estimation, and reducing project overruns and potential failure.

In requirements gathering, fields are the specific characteristics or attributes of an entity that are relevant to the system being developed. Fields can also be called properties, data elements or columns. For example, in an entity called “customer,” fields might include “customer name,” “address,” “phone number,” and “email address.”

In an entity called “product,” fields might include “product name,” “description,” “price,” and “quantity in stock.” Defining the fields for each entity helps to clarify the data that the system needs to collect, store, and manipulate in order to meet the requirements.

In requirements gathering, actions refer to the operations or functions that can be performed on an entity by the system being developed. Actions can also be called behaviors or methods. Examples of actions for an entity might include:

• Retrieving or displaying information about the entity (e.g. “View Customer Details”)
• Creating new instances of the entity (e.g. “Add new Product”)
• Updating or modifying existing instances of the entity (e.g. “Edit Customer Information”)
• Deleting instances of the entity (e.g. “Delete Product”)
• Performing calculations or other processing on the entity’s data (e.g. “Calculate total cost of all products in an Order”)

Defining the actions for each entity helps to clarify the functionality that the system needs to provide in order to meet the requirements.

Usability requirements are a type of non-functional requirement that describe how user-friendly, efficient, and satisfying the system being developed should be for the end-users. These requirements are used to ensure that the system is easy to use, understand, and navigate. Usability requirements can include aspects such as:

• Ease of learning: The system should be easy for new users to learn and understand how to use.
• Efficiency of use: The system should allow users to accomplish their tasks quickly and easily.
• Memorability: The system should be designed in such a way that users can remember how to use it after not using it for a period of time.
• Error recovery: The system should provide appropriate feedback and guidance to users when they make errors, and should allow users to recover from errors easily.
• Satisfaction: The system should be pleasant to use and should not cause frustration or dissatisfaction for the users.

The inclusion of usability requirements in the requirements gathering process is crucial to ensure that the end product is user-friendly and meets the needs and expectations of the users.

Security requirements are a type of non-functional requirement that describe the measures that need to be taken to protect the system and its data from unauthorised access, use, disclosure, disruption, modification, or destruction. These requirements are used to ensure the confidentiality, integrity, and availability of the system and its data. Security requirements can include aspects such as:

• Authentication: The system should be able to verify the identity of users before granting them access.
• Authorisation: The system should be able to enforce access controls to ensure that users can only access the resources they are authorised to access.
• Data encryption: The system should be able to encrypt sensitive data to protect it from unauthorised access or disclosure.
• Data integrity: The system should be able to detect and prevent unauthorised changes to data.
• Access control: The system should be able to restrict access to certain resources or functionality based on user roles or other attributes.
• Auditing and logging: The system should be able to track and log user actions for security and compliance purposes.

The inclusion of security requirements in the requirements gathering process is crucial to ensure that the end product is secure and meets the needs and expectations of the users and stakeholders.

Performance requirements are a type of non-functional requirement that describe the required performance characteristics of the system, such as response time, throughput, capacity, scalability, and availability. These requirements are used to ensure that the system meets the performance expectations of the users and stakeholders. Performance requirements can include aspects such as:

Response time: The time it takes for the system to respond to a user’s request.

Throughput: The number of transactions or requests that the system can handle in a given period of time.

• Capacity: The maximum number of users or amount of data the system can support.
• Scalability: The ability of the system to handle an increase in load or workload.
• Availability: The percentage of time that the system is operational and available to users.

The inclusion of performance requirements in the requirements gathering process is crucial to ensure that the end product meets the performance expectations and can handle the expected load.

Reliability requirements are a type of non-functional requirement that describe the required level of dependability and consistency of the system, such as its ability to function correctly and without failure over time. These requirements are used to ensure that the system meets the reliability expectations of the users and stakeholders.

Supportability requirements are a type of non-functional requirement that describe the necessary level of support and maintenance that the system needs in order to be used effectively and efficiently. These requirements are used to ensure that the system can be supported, maintained and upgraded over time.

Legal and regulatory requirements are a type of non-functional requirement that describe the necessary compliance with laws, regulations, standards, and policies that the system must abide by. These requirements are used to ensure that the system meets the legal and regulatory requirements of the country, industry or sector it will be used in. Legal and regulatory requirements can include aspects such as:

Data Privacy: Compliance with regulations such as General Data Protection Regulation (GDPR) and Health Insurance Portability and Accountability Act (HIPAA) to protect sensitive information

• Accessibility: Compliance with accessibility standards such as Web Content Accessibility Guidelines (WCAG) to ensure that the system can be used by people with disabilities.
• Payment card industry data security standards (PCI-DSS) for systems handling credit card transactions
• Health Information Portability and Accountability Act (HIPAA) compliance for systems handling medical information
• Compliance with industry standards such as ISO 27001 for information security management systems.

The inclusion of legal and regulatory requirements in the requirements gathering process is crucial to ensure that the end product meets the legal and regulatory requirements and can be used legally and ethically.

System requirements are a type of non-functional requirement. This is how the system will run on different platforms. Sometimes referred to as web browser support requirements refer to the necessary level of support and compatibility that a web application or website needs in order to be used effectively and efficiently across different web browsers. These requirements are used to ensure that the application or website can be accessed and used by a wide range of users, regardless of which web browser they are using.