What does an embedded software analyst do?

Software analysts are integral to what we do at Bluefruit. Each of our analysts has a different area of expertise and set of skills, but they all work towards the same goal: making sure that we produce the software clients need. From consulting with clients and development teams to creating comprehensive documentation, they bring immense value to any project.

In this blog, software analyst Tamsen tells us more about her role…

As a software analyst, I use problem-solving, organisation, and collaboration skills to bridge the gap between stakeholders and keep the focus on the highest value work and goals. High levels of collaboration are essential, and we keep the big picture in mind. This helps us ensure we’re building the right thing and identify opportunities and potential improvements.

Creating user stories

I work closely with stakeholders to fully understand their needs and goals. To achieve this, I conduct user story mapping sessions and create user stories. User stories are short, simple descriptions of a feature or functionality, what it will do and what the impact will be. They are written from the perspective of the end-user and typically take the form of: As a [user], I want [functionality], so that [goal].

User stories encourage conversations about the benefits and details of the piece of work and help development teams keep the end user in mind. This approach ensures that the final product is aligned with the needs of the end-users and stakeholders and can be a useful way of explaining highly technical features in a more straightforward way. This allows more people to be involved in gauging the business value when making prioritisation decisions.

By breaking complex requirements down into smaller, manageable chunks, user stories also make the project requirements easier for the development team to understand and implement. Additionally, they can be prioritised and organised into sprints, allowing the development team to focus on delivering the most important or risky functionality first.

Writing detailed requirements

Another of my responsibilities is to create detailed requirements and specifications that the development team can use. This step is crucial in the software development process, as it ensures that the final product meets not only the needs of the end users but also aligns with the stakeholders’ goals. By providing clear and comprehensive requirements and specifications, we can make sure that all stakeholders are on the same page about what the final product should look like. This prevents misunderstandings, costly delays, and rework.

When writing requirements, it’s important to avoid ambiguity, vagueness, and complexity. Requirements should be specific and clearly defined so that there is no confusion about what the software needs to do. It’s also important to avoid duplication and overlap of requirements, as this can lead to confusion and inefficiency. Requirements should also be testable, meaning they should be written in such a way that the testing team can verify and validate them. This ensures that the software meets the requirements, works as expected, and complies with industry standards.

To achieve all this, I often break down the requirements into smaller, more manageable chunks and use clear, concise language that is easy to understand. I may use diagrams, flowcharts, or other visual aids to help communicate the requirements more effectively. I also write test cases and test plans that the testing team will use to ensure the software meets the requirements and works as expected. Often, these test cases can be automated as part of behaviour-driven development (BDD), which makes verifying the requirements easier.

We have requirement quality checklists and a review process to ensure they are accurate and high quality.

Ensuring excellent documentation

Excellent documentation is essential when writing software that must adhere to medical compliance standards. It is my responsibility to write and collate this documentation before and during development to meet these compliance standards, including performing risk assessments.

A risk assessment is a process of identifying and evaluating potential risks to users, the business, and data. Including it in the development process is essential because it helps identify and mitigate any potential vulnerabilities in the software. This includes evaluating the likelihood and impact of potential harm to people and identifying any areas where additional controls may be necessary to reduce this risk.

While the documentation provides transparency and traceability—which makes it easy to verify and validate the software’s compliance at any given time—the risk assessment helps to identify and mitigate potential vulnerabilities. It protects users and helps meet the regulatory requirements for the country in which it is being used.

For projects in regulatory sectors, the documentation must also include information about the software development process itself (You can read about documenting IEC62304 in our blog.), including how it was tested and validated for compliance and how it will be maintained to continue to meet compliance standards over time.

Often, we create living documentation to make it quicker and easier to produce documentation. Living documentation is stored alongside the code and will match the implementation. It is automatically built when the code changes. Regular, small updates and automation keep it easy to manage.

Delivering value

One of the key elements of my role is to ensure that our work is focused on delivering the greatest value to our users and the business. By utilising an Agile approach, I am able to stay flexible and responsive to new information and changing priorities. I work closely with stakeholders to assess progress and make adjustments as needed. For instance, when working on a mobile phone app, if we identify a new feature—such as wireless updates— as being of a high priority for our users or the business, I will adjust our priorities accordingly to ensure that it is developed, tested, and delivered as soon as possible.

I work with the testing team to ensure software meets the organisation’s needs and to troubleshoot any issues that arise. This is a crucial step as it allows us to identify and fix any bugs or problems before the software is released. I might also work with the development team to identify and fix the root cause of the problem.

Essential flexibility

As a software analyst, my role and duties vary significantly. Each project is unique and requires different skills, knowledge, and approaches. For example, one client might require me to act as a Product Owner and focus on user story mapping and creating and prioritising user stories. Another may need me to write requirements and ensure compliance with regulations and guidelines set by the medical industry.

Despite the variations in my role and duties, I take a flexible approach to each project. By adapting my skills and knowledge to meet specific needs, I ensure that assignments are completed to the highest standard.

It is a challenging but rewarding job, and I’m always excited to see the positive impact that software can have on users.

Written by Tamsen Cooper.