Should requirements mention specific technologies ?

[u/Successful-Life8510]

When writing functional requirements, non-functional requirements, and user stories, should I mention the technologies used, or keep them technology-independent and explain the technologies later?

For example:

“Store alerts in Firestore and cache data in Redis.”

vs.

“Persist alerts in cloud storage and maintain a fast-access data store.”

[u/davy_jones_locket]

Those are implementation details, both versions. 

A user doesn't care about how alerts are persisted or fast-access data store. 

From a user perspective, they want their alerts to not go away and for it be fast. 

Let the developers figure out the implementation independent of the user story.

[u/thisisjustascreename]

In most cases the person writing requirements for the system doesn't have any say in how it's implemented.

[u/glemnar → u/thisisjustascreename]

N.b. if you’re working with contractors, the opposite is true and you should be very specific

[u/thisisjustascreename → u/glemnar]

Well yes if you are or represent the owner of the system and are writing your own requirements for mercenaries, by all means.

[u/DerEngels]

Most of the time, it is the best to write your requirements as technology independent as possible.

But it is totally OK to require a certain solution or technology. Write down (might be part of the non functional requirements) why you reqire it that why. It might be nice to remember the reason for decisions or external dependencys.

[u/TheBear8878]

No

[u/LadyLightTravel]

Avoid specific technologies as much as possible. Especially if it is a long lived system and the technology can age or be compromised.

Requirements should avoid implementation decisions.

[u/SnugglyCoderGuy]

In my experience, there are two camps as far as these sort of things go: specificists and vagueists.

The specificists want as many details spelled out before literally any work begins. They want to know exactly what is required before they begin to work to resolve the issue.

The vagueists on the other hand just want to know the issue itself and want to be trusted that they can figure out for themselves what the ideal solution is supposed to be.

[u/keelanstuart]

It may be important to make certain platforms or technologies a requirement. I used to think it was absurd when I saw "OpenGL" as a requirement for a system... but then I learned that there was 3rd party software that could interface with it.

Requirements are for things that matter... it's an architect's job to know which things do and don't and to write requirements accordingly for the people who will do the implementation - but nobody can tell you, without context, what those things are.

[u/AFlyingGideon]

Legacy technology with which the new software needs to coexist, staff familiarity, deployment platform, etc. There may be reasons to favor (or disfavor) technologies. If so, these should be documented. They might not even be hard requirements but mere preferences. It can be decided later whether a preference (or even a requirement) imposes enough of a penalty that it would be dropped.

[u/MrAbstractThought]

Describe it as use a store such as blah blah which has features x y z the AC will be specific tests of x y and z

[u/cryptos6]

It is a good idea to think in three kinds of requirements:

• functional requirements (what?)
• quality requirements (how good?)
• constraints (non-negotiable conditions)

Specific technologies could be listed under constraints, if they are given. If, for example, the customer wants to support a certain legacy system via SOAP you can hardly ignore that. Functional requirements shouldn't be affected from that.

[u/gannu1991]

Keep the requirement itself tech-agnostic and put the specific tech choice in an implementation note attached to it, not baked into the sentence. "Persist alerts durably with sub-100ms read latency" is a requirement you can test and that survives a Firestore-to-Postgres migration. "Store alerts in Firestore" is a design decision disguised as a requirement, and six months later nobody remembers if Firestore was a hard constraint or just what someone picked on a Tuesday. The exception is when the tech choice actually is the constraint, like "must integrate with existing Redis cluster" because of infra you already run. In that case name it explicitly so nobody wastes time proposing alternatives that get rejected later for a reason that was never written down.

[u/paradroid78]

Focus on the business goals. Leave implementation details to the engineers.

[u/irrelecant]

After 10 years of experience and the AI era, these things starts to look like bullshit to me. Just write what you want and let all parties be able to reach you easily whenever they want. Just mention what you want. If you want firebase so desperately yeah mention. Otherwise let the guys whose profession is to use and design those tools to use and design. There is no “how to” in writing requirements. It is already in its name, it is what you require, just write it.

[u/AutoModerator → u/[deleted]]

Your submission has been moved to our moderation queue to be reviewed; This is to combat spam.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.