Back to Forum

How to conceptualize/structure certain requirements

Last post 11:34 pm April 10, 2024 by Ian Mitchell
1 reply
James Ward
08:25 am April 10, 2024

Something I've been pondering in my mind.

If you imagine you're doing a project to implement a COTS system, which is becoming increasingly common for corporate BA's. It's likely you'd have gathered some user requirements around the goals & functionality that the system needs to accommodate, so that the right system could be selected. Once the system has been selected, you are unlikely to go through a detailed functional requirement phase because its an already developed system. However there is bound to be a fair bit of configuration to do within the COTS platform.

If we take for example an ecommerce engine, there is going to be a lot of analysis work to:

  • Understand the clients product catalog and how this needs to be modelled within the ecommerce engine 
  • Understand the clients pricing model so this can be mapped into the ecommerce engine (e.g. customer specific pricing, volume pricing, discounts etc.)
  • Understand shipping options that the client wishes to offer so these can be set up

I'm pondering where this kind of information gets stored and how it gets translated into requirements / backlog items etc. A lot of it isn't functional requirements in the sense of 'user needs to do something'. A lot of it is more about having the right business rules configured, and right data model set up, the right data migrated etc. 

How does everyone conceptualise this kind of information as requirements, and structure them along with all the more typical 'user shall be able to..' requirements.

Ian Mitchell
11:34 pm April 10, 2024

I'm pondering where this kind of information gets stored and how it gets translated into requirements / backlog items etc

It doesn't, because the "detailed functional requirements phase" you refer to wouldn't be expected to happen in Scrum. If it was possible to capture the requirements in such a prescribed manner, you wouldn't need Scrum at all.

Complexity may well exist in the configuration of a COTS system, and the use of Scrum may indeed be appropriate. If so, then the value of Scrum will, as always, lie in the ability to run small experiments early and often. However scope is captured on a Product Backlog, it should simply grease the wheels of this experimentation.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.