DEV Community

Discussion on: How best to write Requirements?

Collapse
recursivefaults profile image
Ryan Latta

There are a few things coming to mind from your post, but I'm going to start by creating two extremes of a spectrum:

  • Requirements are known and communicated
  • Requirements are unknown and discovered through trial

Now, it sounds like you're in some weird place where one group believes the first, but the team realizes its closer to the second. The itch to resolve this must be overwhelming.

If you got the requirements perfect with your customers and built to that, would you be willing to bet your job they'd love it?

My experience with that above statement is that they are never happy and only know what they want when they see something they don't. So this is where agility comes in. If you can get your customers aligned to working with you and your team very closely you can avoid poor scope and inevitable scope creep while managing expectations.

  1. Get everyone aligned to the vision
  2. Create high-level user-centered epics to accomplish the vision
  3. For each of those create the things that need to happen and options to do it
  4. Build a very thin version across all the epics before you iterate and improve on it

To give a set of examples around these steps. Lets talk about logging in. Upon conversation, the reason for logging in is to know who is in the product to audit and customize. Ok, so the first story might be selecting from a list a role. That customizes the application. The next iteration might be asking for an email address. The next could be standard user name and pw/social. The last may be full MFA.

While my example about login may seem ridiculous, I go through this very specifically with all my clients. Many thoughtlessly assumed you have to have a login feature without a reason why. Once we get to the why and provide options, we can cut scope thoughtfully and move on. Thats part of the power of iterative development.

Anyway, happy to help further, but thought I'd offer my little bit here.

Collapse
greggomatic profile image
Greg Thomas Author

Hey Ryan - thanks for this - no your example is a great one.

The problem, I think we're encountering is getting the PM/BA/Requirements people to adopt this style. At the end of the day, every client will give you their information in whatever form they have available, but it's that middle person(s) that provide the real magic in being able to provide the translation between the two so the rest of the team can follow the story.