Skip to main content

Developing your Requirements

The Requirements phase is where you expand on your idea to fully capture the functional and technical requirements in advance of kicking off the project’s development. The process begins from where you left off in your Digital Blueprint, which is a high-level concept document expressing the essentials of your project and how it can come to life. When you begin working with Requirements, the first thing that happens is that your Blueprint is imported and then locked to prevent any future changes.

Unlike traditional requirements gathering and definition, Archie uses an AI-first approach. In this manner, you let the AI take the lead on defining your requirements. The AI considers everything you have defined up to that point in order to ensure its output is consistent and brings you closer to your desired goal. Archie allows you and your collaborators to edit any AI output and also allows you to rerun the AI if needed.

What’s in it for me?

The Requirements phase is where you and Archie do the detailed work of fully expanding the definition of your idea into an actionable specification. Here you will discover and express requirements related to user types, system modules and features, security, performance, accessibility, and more.

The Requirements will serve as one of the principal guides for team members working to build your vision into a working digital product.

Traditionally, creating detailed project requirements is time-consuming. You and Archie can do the work in a few hours. With Archie you will not only go a lot faster, but Archie will think of things that you might overlook. Archie leverages the power of numerous underlying LLMs (Large Language Models) and is also pre-programmed with decades of software design and development expertise. This experience and codified knowledge, coupled with your vision and expertise, results in a far better and more complete set of designs and specifications than previously possible or feasible.

The result is a development project that can be kicked off with little ambiguity and far more definition – This groundwork leads to a faster, better, and more economical working product.

Overview

The Overview section contains information from the Digital Blueprint, compliance needs, and regulatory requirements.

General

The General tab contains foundational information taken from the Digital Blueprint.

Requirements Overview general tab

Problem to be Solved

Problem to be Solved addresses the purpose of your project: What is the problem you are addressing? What user needs do you want to meet?

This is also where the specific challenges and significance of the problem are documented. What are the risks to users if this problem is not addressed? How much time and money is currently being wasted? You can also list alternative solutions that you have already considered, but will not fully address your problem.

Framing statements are crucial in application development because they clearly define the purpose and scope of your project.

Solution

The Solution section is where you explain how you will solve the proposed problem. It outlines the benefits of using your project and lists key performance indicators.

A clear solution statement acts as a reference point for decision-making and helps maintain focus, ensuring your application stays on track. Having concrete performance indicators means that you have clear success metrics you can measure during testing

Application Type

The type of application or service you want to build. Different product types have different technical requirements and application services. Here are some of the application types available in Archie:

  • Software-as-a-Service (SaaS): Subscription or usage-based service applications (Hubspot, Spotify).
  • Digital Marketplace: Platforms connecting buyers and sellers (AirBnB).
  • Internal Application: Tools for organizational efficiency (custom Excel replacements).
  • Portal: Applications for organizational engagement with customers or stakeholders.
  • Personal Application: Software for individual personal use (personal organizers).
  • SaaS / Marketplace Combo: Hybrid platforms combining marketplace features with a SaaS model (e.g., Upwork).
  • Social Network: Platforms for online social interactions (Facebook, Instagram).
  • AI Assistant or Bot: AI-driven conversational interfaces for enhanced productivity.

Commercialization Model

How your project will generate revenue. A financial model is critical for shaping your application's development, investment, and user engagement strategies.

Here are some of Archie’s suggested commercialization models:

  • No Charge: Free access to users.
  • Subscription-based: Recurring fee model, possibly with a freemium option.
  • Usage-based: Fees based on service consumption levels.
  • One-time Purchase: Single fee for permanent application access.
  • Advertising: Free access with revenue from in-app advertisements.
  • Marketplace: Transaction-based fees in a buyer-seller platform.
  • White-labeling / Licensing: Selling the application for rebranding and resale.
  • Data Monetization: Selling anonymized user data to third parties.
  • Freemium: Basic services for free, premium features for a fee.
  • In-app Purchases: Additional features or content available for purchase within the app.
  • Sponsorship: Partnering with brands or companies who sponsor parts of the app.
  • Donation / Crowdfunding: Voluntary user donations or crowdfunding campaigns.

Design Considerations

Design Considerations reflect your project's style and tone. Design is crucial for user experience, engagement, and trust. Should your app be fun, colorful, and addictive? Or should the design be serious, neutral, with a focus on accessibility?

Requirements Overview Design consideration tab

This section helps all stakeholders get on the same page when it comes to design. First impressions are important. Good design creates an emotional connection with your users, clients, team members, and stakeholders.

Security

The Security tab contains project requirements related to privacy, access, encryption, and other security concerns.

Requirements Overview Design security tab

Security requirements are vital in application development to protect against data breaches, unauthorized access, and other threats. User data must be safe to maintain user trust, which is critical for your project’s credibility and legal compliance. You can prevent legal and reputational risks by implementing robust security measures like encryption, authentication protocols, and regular security audits. This is essential in today's digital landscape where data security is a top concern for users and businesses alike.

For example, in a marketplace application, security requirements might include strong user authentication (like two-factor authentication), encryption of data in transit and at rest, and regular security audits. These measures protect sensitive financial data and user identities from cyber threats such as hacking or identity theft.

Compliance

The Compliance section is for projects that need to uphold regulatory compliance standards, such as:

  • Health Insurance Portability and Accountability Act (HIPAA): Healthcare data privacy in the United States.
  • General Data Protection Regulation (GDPR): Data protection in the European Union.
  • Systems and Organization Controls 2 (SOC2): Security framework that specifies how organizations should protect customer data.

Compliance requirements are important for legal and ethical reasons. They ensure your application adheres to specific industry standards and legal regulations, protecting user data and privacy. Non-compliance can lead to legal penalties, loss of user trust, and reputational damage.

Requirements Overview Design compliance tab

For instance, if you are developing a telemedicine app, it must comply with HIPAA. HIPAA regulations set standards for the storage, use, and transmission of protected health information. An application where doctors treat patients will handle patient medical history, diagnostics, and treatment plans.

Performance

The Performance section specifies the key performance metrics your application must meet, ensuring a smooth and performant user experience.

Requirements Overview Design accessibility tab

It outlines essential functionalities related to load time, response time, throughput, and scalability, with a focus on maintaining performance during peak usage. The section also details requirements for server response times, database query efficiency, and front-end processing to uphold application speed and efficiency.

In a marketplace app, performance metrics could include:

  • Load time: The app should load content within 2-3 seconds to ensure a smooth user experience.
  • Response time: Server responses, especially for search queries and transactions, should be under 1 second.
  • Throughput: The app should handle a high number of transactions or user interactions simultaneously, for example, 1000 transactions per minute.
  • Scalability: The ability to handle increased loads, such as during holiday sales, without performance degradation.
  • Database efficiency: Queries should be optimized for speed, with key pages like product listings loading quickly.

These metrics are essential to maintain a seamless and responsive user experience.

User Types

Serving users is the number one goal of any successful application.

The User Types section provides details about user roles and permissions.

Requirements user types

It also lists user needs and pain points for each user type.

Requirements user types user details

For instance, in a fitness app, you might have three user types with unique needs:

  • Casual Exercisers: Prefer easy-to-follow workout plans and basic tracking features.
  • Professional Athletes: Need advanced analytics and performance tracking.
  • Fitness Coaches: Require tools to manage multiple clients and training schedules.

By defining these user types, your application can offer personalized experiences and features tailored to each group's specific requirements, enhancing user engagement.

For the Casual Exercisers in your fitness tracking app, specific user needs might include:

  • Tracking workouts accurately
  • Monitoring health metrics
  • Receiving personalized fitness advice
  • Recommending meal plans based on the day’s workout

Pain points could be:

  • Inputting data is difficult, especially during a workout
  • Tracking is not accurate (for example, step counter)
  • Workouts cannot be customized

Addressing these needs and pain points would involve developing easy data entry interfaces, integrating reliable tracking technologies, and incorporating AI for tailored fitness guidance. All of these components enhance user experience and engagement with the app.

User types are also used to define security restrictions. Assigning roles helps in enforcing the principle of least privilege and simplifying permission management at a granular level. Roles might be combined with groups or profiles to further refine access controls and user management. In a fitness app, the user might want to be able to share their progress with their trainer or friends. But the app would need to make sure that personal information such as birthdays, or information related to HIPAA, is only viewable by the user.

Modules

Modules are the specific, self-contained units of functionality within your software. A module might be a user profile section or a hotel booking portal.

Modular design promotes organized, maintainable, and scalable software architecture. These are the pieces that developers and UX designers will use to build your project.

Modules page

Modules often have well-defined interfaces through which they communicate with other modules. This leads to:

  • Encapsulation: Modules hide their internal implementation details and expose only what's necessary through a well-defined interface. This way, changes inside a module don't affect the rest of the system.
  • Cohesion: A module should have a single, well-defined purpose or responsibility. This concept is known as cohesion, where all the functionalities and elements within a module are closely related.
  • Reduced Coupling: Modules should ideally operate independently, minimizing dependencies on other modules. When modules need to interact, they should do so through clearly defined interfaces.
  • Reusability: One of the benefits of modular design is that modules can often be reused in different parts of an application or even across different projects, as long as the context aligns with the module's functionality.
  • Maintainability: With clear boundaries and limited scope, modules are easier to maintain, debug, and update.

When you expand a module, you can description, UI pattern, view user guidance, user stories, and acceptance criteria. Each user story can have as many acceptance criteria as needed.

Modules expanded row

User stories and acceptance criteria are important because they provide a clear, user-focused perspective on what the module should achieve. User stories describe the functionality from the user's point of view, ensuring the development is aligned with real user needs. Acceptance criteria define the conditions that must be met for the user story to be considered complete, serving as a checklist for quality assurance. This approach ensures that each module is developed with a clear understanding of its purpose and functionality as it relates to the end user's experience and needs.

A travel booking app might have a module called "Hotel Booking." A user story for this module might be: "As a traveler, I want to easily find and book hotels based on my preferences." The acceptance criteria could include:

  • Ability to search for hotels by location, date, and number of guests.
  • Filter options for price range, hotel amenities, and ratings.
  • View detailed hotel descriptions, photos, and reviews.
  • Seamless process to select a room and complete the booking.

These criteria ensure the module effectively meets the traveler's needs for finding and booking hotels, enhancing the app's usability and user satisfaction.

Application Services

Application Services are the underlying technical services in your application. For example, in a social media app, application services might include a user authentication service, a notification service, and a transactional text messaging service.

Application Services are incredibly important in supporting the overall functionality, user experience, and architecture of an application. Properly constructed, application services become reusable services inside of your application.

Requirements Application Services

Similar to modules, when you click on a building block, you can view user stories and acceptance criteria.

Requirements Application Services expanded row

For a social media application, you might have a building block called "User Profile Management." A user story could be: "As a social media user, I want to easily create and update my profile to reflect my personal information and interests."

The acceptance criteria might include:

  • Ability to add and edit basic personal information like name, bio, and profile picture.
  • Options to link or mention interests, hobbies, or affiliations.
  • Customizable privacy settings for different profile elements.
  • A straightforward interface for updating and saving profile changes.
  • A profile interface that is easy to update on desktop and mobile devices.

These criteria ensure the building block is developed to meet the user's needs for personalizing and managing their profile, enhancing user engagement and experience on the platform.

UX/UI

The UX/UI section uses your Design Considerations to generate a sitemap, list of screens, and wireframes.

General

On the General tab you can select foundational design requirements. Requirements UX UI

Web Interface

A web interface is the part of an application that users interact with via a web browser. It is a graphical user interface (GUI) that includes elements like buttons, text fields, images, and navigation menus. This interface provides a user-friendly experience, allowing users to interact with the application's functionalities over the internet.

Progressive Web Application

A Progressive Web Application (PWA) is a type of application software delivered through the web, built using technologies such as HTML, CSS, and JavaScript. They are intended to work on any platform that uses a standards-compliant browser. PWAs are designed to work offline. They have capabilities similar to a native app, such as push notifications and access to device hardware, while being accessible via a web browser. They offer an app-like user experience and are often seen as a bridge between traditional web pages and mobile applications.

Native Applications

A native application is a software program developed specifically for a particular operating system or platform, like iOS or Android. These apps are built using platform-specific programming languages and tools, and they are installed directly on a device. Native applications can take full advantage of the device's hardware and software capabilities. This offers high performance and a user experience that aligns closely with the platform's standards. They typically provide more robust and responsive interactions compared to web-based applications.

Form Factors

Form factors refer to the size, shape, and physical design of computing devices. Common form factors are mobile, desktop, and tablet.

A user’s device influences how they interact with your application. Each form factor has different interface and usability characteristics, making it essential to consider them when designing software to ensure optimal user experience.

Accessibility

The Accessibility section contains your requirements for upholding Web Content Accessibility Guidelines (WCAG), the international accessibility standard. Some countries have adopted the international standard, for example, the United States has Section 503.

Accessibility tab

Ensuring that your project is accessible is important for ethical, monetary, and compliance reasons. Many government organizations require that public-facing applications or services meet WCAG 2.2 level AA.

Making your application accessible also means you will reach a larger audience. It’s very common for disabled users to rely on new technology to improve their lives, like speech-to-text or online shopping. Be My Eyes is an app that connects the visually impaired with people who can see, to help them with things like grocery shopping, using their cellphone’s camera. If your project is not accessible, it means many users will not bother to try it out.

Site Map

Your site map will be displayed as a mind map. The site map outlines how different pages or sections are interconnected, helping in planning the navigation and flow of the application. It ensures logical organization and easy access to features.

Screens

This is where you find your generated sitemap, screens, and mid-fidelity wireframes. These will follow the design style set on the General tab. These components provide a visual representation of your app’s structure and user interface. These pieces help the developers and UX designers who are building your application. They are also great tools when you are working with clients who do not have technical backgrounds. Sitemaps, screens, and wireframes guide the design and development process, ensuring a cohesive and visually effective application.

Screens tab

The list of screens shows each screen name and a brief description. Screens might include the homepage, contact page, user registration, authentication, etc.

Wireframes

Clicking on a screen will open the associated wireframes. Wireframes represent the visual layout of each page, showing where elements like buttons, text, and images are placed. They help in visualizing and refining the user experience, ensuring that the app is intuitive and user-friendly. Wireframes are incredibly helpful when you need to explain what your project is, you want to show clients what you are building, or you are trying to impress potential investors.