Requirements

Various requirements make the core content of any project. They are stated, implied, or even unknown yet to a client and revealed only during the analysis. Formally captured requirements compile the project scope.

A requirement is a condition or capability a stakeholder needs to solve a problem or achieve an objective. It is also a condition or capability that must be met or possessed by a solution or a solution component to satisfy a contract, a standard, a specification, or other formally imposed documents. A requirement is also a documented representation of conditions or capabilities stated above.

Levels of requirements

Requirements define what should be done but don't describe how exactly it should be done.

Software requirements include three distinct levels:

• Business requirements represent a high-level business objective of the organization that builds a product.

  Business requirements should be stated in the form of a goal for automation. They can be financial (decrease costs, increase profit) and non-financial (increase customer satisfaction, process more significant volumes with the same resources), and they designate automation reasons. Business requirements should operate with exact numbers, which are present as a part of the success criteria for automation, for example, decrease processing time by 30%, manual effort by 15%, achieve 20% of STP, and so on. Success criteria should serve as a baseline for particular metrics to measure project success.

• User requirements identify a goal or task that a specific class of users should be able to perform with the help of a solution.

  User requirements consolidate requirements related to user tasks or specific user roles in the process. For example, a task to process incoming applications requires a user to read new emails and download attachments manually. As user requirements, it can be transformed into the requirements to receive a notification once a document is available for reconciliation in Workspace, receive processing statistics on dashboards, and so on.

• Functional requirements describe behavior a system will exhibit under specific conditions.

  Functional requirements contain a technical description of system behavior under certain conditions. For example, user requirements to notify about documents available in Workspace should be split into functional requirements to connect to a mailbox, read new emails, download attachments, move emails to a processed folder, send attachments to OCR, extract data with the help of ML, send documents to Workspace, and send a link to the task to the user's mailbox.

Business processes should also meet different constraints that can't be captured as functional requirements. Such parameters are called non-functional requirements, which identify property or characteristic that a system must exhibit or a constraint that it must respect, for example, operating hours, technical standards, number of requests to handle simultaneously, and so on.

Functional and non-functional requirements should be properly documented and signed off with a client.

Quality of requirements

High-quality requirements should meet the following characteristics:

• Complete. Each requirement should be complete and self-contained without missing information. Also, the entire set of requirements should represent all relevant details of the feature.

• Correct. Errors in requirements lead to incorrect assumptions and estimations and incorrect solutions.

• Unambiguous. Individual requirements should be clear and precise. They should allow only one interpretation and should be intended for both technical and non-technical readers.

• Consistent. Individual requirements should not contradict or describe the same requirement using different wording.

• Feasible. Requirements should be implementable within the existing infrastructure, budget, timeline, and available resources. The Data Analyst needs to work with the team to make these determinations.

• Testable. Each requirement should be testable, which means a test can be designed to check if a solution meets a requirement and to prove that a requirement has been fulfilled.

Format of requirements

In most cases, you can present requirements in three formats: text, a table, or a model:

• Text

  Textual requirements describe solution capabilities, conditions for a requirement to operate, business rules, constraints, user scenarios, and so on. To set up effective textual requirements, mind the following rules:

  • Express only one requirement at a time.
  • Avoid complex conditional clauses.
  • Do not assume your reader has domain knowledge.
  • Use consistent terminology.
  • Express requirements as a verb or a verb phrase.
  • Write in the active voice, clearly describing who or what is responsible for fulfilling each requirement.
  • Use terminology familiar to stakeholders who review or use the requirements.

• Table

  Business Analysts use tables when they want to convey a set of requirements with a complex but uniform structure that can be broken down into elements applying to every entry in the table.

  Tables are often used for fields mapping, data dictionaries, test cases, prioritizing requirements by mapping them against project objectives. The tabular form is also used for traceability of requirements to each other and gap analysis.

• Model

  A model is a simplified representation of a complex reality used for understanding that reality and making decisions regarding it. Models can be textual or graphical, or a combination of both. Graphical models are often referred to as diagrams.

  The choice of which model to use for a particular set of requirements is determined by the type of information to be communicated and the audience who will consume the information. Models can describe processes, define their boundaries and components, show business logic, components, and their relationships.

  Models are usually included in the documentation requirements in their final form, for example, in the form of a process diagram with a textual description.