Business Analyst Artifacts in Software Development: Definition and Types

Business Analyst Artifacts in Software Development: Definition and Types

What are artifacts in business analysis?

Artifacts in business analysis are tangible outcomes or deliverables created during a project. These can include business analyst documentation, models, reports, and other forms of output. Artifacts serve as records of a project's progress and are used to inform future initiatives. 

Essentially, artifacts are the physical evidence of the work done by business analysts. They come in various forms, from formal business analyst documents to informal sketches, and are essential for effective communication and maintaining project history. 

This article explores how Business Analyst artifacts can make a difference in custom software projects, especially for startups and during the launch of new products. We take a closer look at the specific, more complex and useful artifacts and deliverables of a business analyst, and the ways they can help your business succeed. 

Business model canvas

Business Model Canvas (BMC) is a business analysis document that visually and simply demonstrates a business idea and conveys a concept. Most often, it’s a one-page summary or a scheme with consistent structuring. It emphasizes only the key ideas of the business as a whole, or an individual product. 

 

Canonically, the right side of BMC focuses on the customer, while the left side focuses on the business. Together they form the outer and inner parts, respectively. Both external and internal factors converge around the value proposition (the exchange of values between a business, its customers and suppliers).

BMC usually focuses on sales and product/service offerings. On the positive side, BMC provides a clear overview in a visual format, promotes teamwork, encourages feedback-driven progress, and offers a systematic approach to business analysis. However, it's crucial to be aware of potential limitations, such as oversimplification of the business model, and difficulties in translating ideas to action. 

Project backlog

A project backlog is a prioritized list of tasks, features, or business analysis requirements that need to be addressed or implemented in a project. It serves as a dynamic repository where new items can be added or existing ones can be reprioritized as the project progresses. 

In Agile methodologies, such as Scrum, the project backlog is a key component and is often managed and refined during sprint planning sessions. This list allows the team to understand what work needs to be done and when. It contains the order in which functions or tasks will be solved, and, as a result, aids in effective project management and decision-making.

The backlog allows the team to quickly take into account new requirements or change existing ones. This ensures that the most important work will always be done first.

Project backlog allows you to define strategy, target audiences, and effective ways to reach the market. 

On the picture, you can see an example of one of our project backlogs. It consists of a list of requirements, and the implementation tasks are assigned to specific members of the team. 

project backlog example

Product vision board

A product vision board is one of the popular artifacts of a business analyst. It usually includes key elements such as the product's purpose, target audience, key features, and desired results. 

Let's take a look at the significance of this tool in determining the direction of the project. Usually, a product vision board is a graphical representation of the key elements associated with the product.

It may include basic ideas, values, customer needs, and opportunities. 

Using a product vision board can provide various benefits for your business, such as: 

Coordination of stakeholders. It serves as a visual representation of the product vision, ensuring that all stakeholders share a common understanding of the main goals and directions. By providing a real guideline, the council facilitates discussions and collaboration by combining different points of view into a single vision.

Clarity of goals. A clear statement of the goal is the key to successful communication and understanding of the expected results and benefits. Stakeholders gain clarity on how their contributions align with the broader vision, which increases their commitment to the project.

Improved collaboration. Collaboration is easier during discussions, seminars or planning sessions, ensuring everyone's active participation in shaping the direction of the product. In addition, this approach encourages open communication  

Increased flexibility. There is also room for flexibility and iteration as the product develops. Stakeholders can easily contact the board of directors when changes or adjustments are needed, ensuring that the changes are consistent with the overall vision. 

In the picture, you can see a simple product vision board example. This is a product vision we created before the development of new Apiko website. 

product vision board example

Alternatively, you can also use a traceability matrix. It is a tool used in project management and software development to ensure that all requirements are linked to their associated business analyst deliverables and vice versa.

It establishes clear links between requirements, design, development, testing, and other phases of the project. By creating this matrix, the team can easily track and verify that each requirement is being met and tested throughout the project life cycle. 

Quality attributes

Quality attributes in software refer to the measurable characteristics that indicate how well a software system performs. These are essential traits or features that determine the software's overall quality and effectiveness. Quality attributes help to understand if the software meets the requirements and expectations of its users and stakeholders. 

The most important quality attributes are. 

  • Reliability: Refers to the consistency and fault-free operation of software over time and under specific conditions.
  • Maintainability: Measures how easily software can be updated, fixed, or enhanced without causing disruptions to other parts of the system.
  • Usability: Evaluates the ease of use and overall user satisfaction when interacting with the software
  • Portability: Indicates the ability of software to be transferred or adapted to different environments or platforms.
  • Correctness: Ensures that the software performs tasks accurately according to predefined requirements and conditions.
  • Efficiency: Measures the performance of the software in terms of resource utilization and response time for completing tasks.
  • Security: Focuses on protecting the software from unauthorized access, data breaches, and malicious attacks.
  • Testability: Determines how easily the software can be tested to identify and fix bugs or issues.
  • Flexibility (Modifiability): Reflects the software's ability to adapt to changes in technology, business rules, or market demands
  • Scalability: Refers to the software's capability to handle increasing loads or user demands without sacrificing performance.
  • Compatibility: Ensures that the software can seamlessly integrate with other systems or platforms and function correctly across different environments.
  • Supportability: Measures the software's ability to provide useful information for identifying and resolving issues when they occur.
  • Reusability: Indicates how easily components or modules of the software can be reused in other applications or within the same application.
  • Interoperability: Evaluates the software's ability to communicate and exchange data with other systems, regardless of differences in operating systems, protocols, or formats.

Non-functional requirements

Functional requirements define which features the system should have. 

Non-functional requirements, on the other hand, describe in detail how the system should perform certain tasks. Examples of non-functional requirements include response time, system availability, security policy, and compliance with industry standards.  

For instance, here are non-functional requirements for one of Apiko’s projects: 

  • NF1. User info like personal contact, payment methods must be protected and should not be accessible to unauthorized personals.
  • NF2. The website must have an SSL-certificate. 
  • NF3. When the app data increases, the app must be capable of handling them without delay by optimizing the way storage is done and accessed.
  • NF4. All data must be displayed with pagination controls. 
  • NF5. It should not take more than 15 seconds to load the initial screen.
  • NF6. The website must be usable on Apple iPad 3rd & 4th generation, Air & Air 2 and Pro 9.7-inch.
  • NF7. The website must be optimized for desktop computers and laptops
  • NF8. The following list of browsers must be supported: Chrome, Safari, Firefox, Opera, Edge (latest official versions).
  • NF9. The following screen resolutions must be supported: 1366×768, 1920×1080, 1440×900, 1536×864.
  • Performance requirement. 100 users should be able to use the system at the same time. The response time of the system should be 2 seconds at most.
  • Design constraint. JavaScript must be used as a primary programming language. 

The balance between quality attributes and non-functional requirements

In business analysis in software development process, the balance between quality attributes and non-functional requirements with functional requirements is crucial. This balance ensures that the software is not only rich in functionality, but also works reliably and efficiently in various environments, contributing to user satisfaction. 

Achieving a balance may involve trade-offs, as improving one attribute may affect another; for example, optimizing performance may require considering resource usage.

Moreover, quality attributes and non-functional requirements serve as criteria for testing and verifying software. QA experts conduct performance testing to ensure that the system meets expectations, contributing to the sustainability and reliability of the final product. 

Let’s keep in touch

Want to know which BA artifacts will suit your business case? Schedule a consultation with a professional today. 
Michel Rokosh
 

Use cases

Use case is a detailed scenario describing the user's interaction with the system to achieve a specific goal. They provide an overview and understanding of how the system works, recording steps, inputs, and possible options. 

This artifact defines user scenarios and ensures that the system meets the different needs of users. It also describes the features and capabilities expected by users. It guides the development process and provides a clear understanding of the desired behavior of the system from the point of view of the customer. 

Use cases usually consist of the following sections: 

  • Use case number and application. This section assigns a unique identifier to each use case for record-keeping purposes. 
  • Use case name and description. The use case name and description serve as titles for the use case and are crucial for documentation purposes. The name is typically concise, while the description provides additional context. For example, 
  • Actor. An actor is someone or something that performs a behavior within the system. It can represent individuals, entities, or even external systems interacting with the software. 
  • Stakeholder. Stakeholders are individuals or entities with a vested interest in the system's behavior and success, even if they don't directly interact with it. For example, 
  • Primary actor. The primary actor is the person or system whose goals are fulfilled by the software. While they often initiate use cases, it's not always the case. 
  • Preconditions. Preconditions are statements about the conditions that must be met before and after the use case occurs. They outline necessary steps or truths for the subsequent actions to take place. 
  • Triggers. Triggers are events that prompt the initiation of a use case study or report. They can be internal or external and often signify a need for action or investigation. 
  • Basic flow. The basic flow, or main success scenario, represents a use case that unfolds perfectly without encountering errors or exceptions. It serves as a reference for understanding how the system should ideally operate. 
  • Alternative path. An alternative path, also known as an alternative flow, depicts variations of the main success scenario that occur when errors or exceptions arise. These alternative paths address potential deviations from the ideal flow. 

User stories

User stories are user-oriented short descriptions of features and functions written from the point of view of the end user. These artifacts created by business analysts follow a simple pattern and convey the aspects of "who", "what" and "why". 

User stories describe how the system works, highlighting specific features and functions in the way the user expects. User stories provide a compact but comprehensive view of the desired behavior of the system.

Max Rehkopf from Atlassian recommends to think about the following aspects when making user stories: 

  • Definition of "Done": Make sure you know when exactly the story is completed. Define the specific task or goal that the user should accomplish. 
  • Subtasks or tasks: Break down the user story into manageable subtasks and assign responsibilities for each of the tasks. This helps to track progress. 
  • User personas: Identify the target audience or users for whom the story is relevant. If there are different types of users, consider creating separate stories tailored to each persona.
  • Ordered steps: If the user story involves multiple steps or stages, write a separate story for each step. This helps to improve organization and keep everything clear. 
  • Listen to feedback: Gather insights and feedback from users to understand their needs and challenges. Use their language and experiences to shape the user stories. 
  • Time considerations: While it can be difficult to estimate timelines aim to keep user stories manageable within a single sprint. If a story seems too large, break it down into smaller, more achievable tasks or consider treating it as its own epic.

Examples of artifacts in business analysis

Although the specific details of startups' internal processes are often proprietary, there are many examples of startups using business analysis artifacts to improve their projects. Here are some common scenarios:

User stories and use cases example: A successful mobile app startup used user stories and use cases to identify features and prioritize. This approach ensured the creation of a product that met the needs of their target audience, contributed to positive reviews and widespread adoption.

Project backlog example: The technology startup used a well-managed backlog of projects in agile methodologies, which allowed them to quickly adapt to changing market demands. This facilitated iterative development cycles, ensuring that the product evolved based on real-time feedback.

Business Model Canvas example: The fintech startup used the Business Model Canvas (BMC) to formulate and coordinate its business strategy. The visual presentation of the key components was successful, helping stakeholders understand the business model, contributing to successful funding rounds and partnerships.

Non-functional requirements example: A medical technology startup has focused on reducing risks related to data security and compliance. Business intelligence artifacts, including comprehensive documentation on non-functional requirements, ensured that the development team complied with industry standards, which led to the creation of a secure product. 

These examples illustrate how thoughtful use of artifacts in software development can positively impact product development, user satisfaction, and overall startup growth. 

For example, during the discovery phase, Use Cases and User Stories can be used to detail end-user interactions with the white-label platform. Such branded pages can be integrated and additional features can be included to meet all sorts of unique customer needs. 

Conclusion

Business analyst artifacts from documentation and requirements to use cases and user stories provide a structured framework for guiding the development team. By capturing key aspects of a project, artifacts used by a business analyst help minimize risks and improve decision-making throughout the software development lifecycle. 

Startup software development projects are inherently uncertain and quickly iterable, which further increases the importance of business analysis documents

As a result, business analysis in software development plays an important role in the success, especially in the dynamic environment of startup projects. 

At Apiko, we provide software development services of any complexity. Whether you’d like to make a proof of concept, start mvp development, mobile banking app development, or white label app development, we’re always ready to lend you a hand. We also offer managed IT services in case you need us to maintain and support your IT infrastructure.

With us, you can be sure that your software development contract is legally compliant and that you can avoid the risks of outsourcing.