Agile requirements gathering in embedded project [duplicate]


Agile requirements gathering in embedded project [duplicate]

This question already has answers here:

Scrum for Embedded system devices

                                    (4 answers)

Closed 4 years ago.

I am working on a project where we develop an embedded application for a Linux-based device handling data from different sensors and visualizing them to the end user. We try to use Scrum process but came across different difficulties related to our and management team perception of Requirements Engineering.
Basically Scrum recommends User Stories maintained in a Backlog prioritized by the Product Owner. Scrum assumes that there is no "requirements freeze" or single document describing the project at the start.
User stories can be added "on demand" when stake holders thinks they are necessary to have a "releasable" software version.
On the other hand embedded system due to tight coupling with hardware need upfront specification of different system features, e.g.

HW / SW interfaces (e.g. shared memory between main CPU and FPGA)
Data formats, what and how will be stored with what frequency
hard real time requirements, how fast must the system react on certain events
interaction with other disciplines, eg. HW, optics, mechanics

What are the best practices to handle requirements engineering in embedded systems in a lightweight (Agile) way (in contrary to e.g. automotive processes) ?


Answer 1:

Scrum is not concerned with requirements freezing or not. Scrum works equally well if you start with 100 stories in your backlog that never change, or 5 stories with more being added/changed all the time. Scrum is supposed to be an iterative process and it requires a totally different mindset than more traditional waterfall models.

Technically with Scrum you could have several sprints where all the user stories are gather requirements for foo, gather requirements for bar, etc. I really recommend not doing this though, because it will waste a ton of effort trying to gather every requirement when you know the least about what you are building.

What I do recommend is working to prioritize all the high level features that you know you need, and then start with the highest priority and gather requirements only for that single feature and then begin implementing them, and only move to the next feature when you believe you have completed the current feature. The reason this is a superior approach is because at the worst case, its the same as the other approach, but in most cases it will save effort overall. If any assumptions/early requirements you made about the highest priority feature change during development using this method there is no chain reaction of other requirements affected because you haven’t created them yet, instead when you get to related features you have many things you know because parts of the system already exist.

Answer 2:

I don’t have personal direct experience in embedded systems – but I do understand waterfall and agile and the differences between the two, as I am sure you do too. I have also discussed this issue – of applying Agile in industries such as embedded software development, semiconductor design/ development, etc. with friends who work in those industries – so hopefully, I have some understanding of the issues you are facing..

The fundamental objective of Agile is to ensure that what you ultimately deliver to your customer/ business user is timely, works as per requirements and most importantly, is done in a manner that allows you to handles changes to requirements effectively along the way. These were the biggest challenges of waterfall projects – and in spite of careful planning and large up-front efforts to define the perfect requirements – caused delivery of software that did not meet business requirements.

Given what you have said about the need for upfront requirements and design due to hardware dependencies, etc. I’d say that to become (more) agile, you can try break up your overall product scope into the most ‘feasible’ (self-contained) modules (or themes, epics or MVPs, whatever you choose to call them) and define all the requirements/ user stories up-front for each such module, including hardware dependencies, et al.

Depending on the size of the modules, you can then still build each module in multiple sprints, taking either the highest priority users stories first – or taking them in the order of ‘functional dependencies’ between user stories. This way, you ensure that at the end of each sprint, you are delivering working features onto a staging server/ device that allows you to demo it to your product owner/ business users/ customers – collect feedback, especially any changes to requirements – or new requirements – and incorporate them into future sprints/ modules.

So, instead of looking at this as an “agile requirements gathering” issue, perhaps you just need to focus on overall “agile product development” that helps your team(s) delivery early, deliver often and ultimately deliver right?

Just my 2 cents. Hope it helps.

Answer 3:

Does the software team has any influence on the hardware specs? Or is it purely the other way around (hardware team dictates low-level software interface)?

In the latter case, a HAL (hardware abstraction layer) person must sit with hardware team to write the low-level software interface; GUI team can work at their own pace, possibly using Scrum or any other Agile methodology.

If the hardware and software co-evolves, it is going to be a rapid prototyping project. The focus is on maximizing learning rates (will-works and won’t-works), keeping cost under control (spending it wisely, knowing it very well that prototyping means a lot of throwaway work and is going to be expedited, making it much more costly than typical projects).

There are many Q&A on rapid prototyping, on this site and elsewhere.

If it is rapid prototyping, it is probably not going to be scrum. It might still be Agile in spirit but it might be different from any of the mainstream Agile frameworks – because mainstream Agile frameworks mostly cater to purely-software, market-driven development.

You certainly have to “Responding to change over following a plan”; it’s being forced onto you because hardware and software co-evolve projects are full of “won’t-works”.

Scrum has the so-called “spikes”, but if a project is full of spikes, you typically don’t call it scrum. Instead of fixed time-box sprints, you will have milestones, where each milestone has some deliverables, and the milestone ends only if these items are delivered or otherwise having some of the items amicably cancelled by the stakeholders.

Scrum management software might still work, stand-up meetings will always work, etc.

Answer 4:

While the question, as posed, has broad scope, the core issues seem to be:

…Scrum assumes that there is no ‘requirements freeze’…

…embedded system due to tight coupling with hardware need upfront specification…

Scrum aims to produce high quality increments of a deliverable solution. It does not aim to minimise re-work or minimize time to production of a final product, for example. You need to consider if this priority is appropriate to your environment.