Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Better tools for the software requirements / scoping phase?

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 104 posts

Re: Ask HN: Better tools for the software requirements / scoping phase?

#91

Post by Tade0 »

thedancollins wrote: post #66
Tade0 wrote: post #44

Earlier quoted context omitted.

I wonder how effective it would be to at first make the programmers realize all the business processes manually so that out of frustration they would start automating things? A so-called FDD - frustration driven development.

I like it! Some of my most effective code was written that way but the end result of such development tends to be users that feel "cut out" of the process, as if we did not value their input. And with the wrong users in that dynamic you could be turning water to wine and they will still find things to complain about.

The other day I was tasked with extracting over 500 field names and associated labels from an excel file(it was sort of a form template).

Obviously not something I graduated from University for, so I wrote a script that did it for me.

FDD all the way.

Re: Ask HN: Better tools for the software requirements / scoping phase?

#92

Post by dotancohen »

fbonawiede wrote: post #49
dotancohen wrote: post #34

Earlier quoted context omitted.

I am seriously interested, however your website has almost no information and I'll not book a 30-minute appointment at a later time to see how it works. The only informative part of the whole website seemed to be this screenshot: https://www.delibr.com/img/design/features/section2/xstep1.p... Add more screenshots and less "integrates with slack".

Thanks for the feedback! We have avoided putting too many screenshots on the webpage since we made changes all the time initially. However, we are now ready to put screenshots. "I'll not book..."? I guess you meant "I'll book..."? =)

Actually it is "I'll not book". The time to make an impression on the user is while he is visiting your site.

Re: Ask HN: Better tools for the software requirements / scoping phase?

#93

Post by andymoe »

andymoe wrote: post #72

We do this thing we call Discovery & Framing at the kickoff of a new project. It usually lasts 3-6 weeks and involves design, product, engineering and someone with the power to make decisions on the spot. We call this role a product owner. It’s a good way to get stuff out of folks heads, validate the problem and solution with users, and end up with some stuff for everyone to execute on by the end of the process. You…

Since this got some upvotes, if you want a taste for a process like this condensed into and hour you can visit:

https://pivotal.io/office-hours

(Free, staffed by a balanced team over a lunch hour)

Re: Ask HN: Better tools for the software requirements / scoping phase?

#94

Post by fbonawiede »

dotancohen wrote: post #92
fbonawiede wrote: post #49

Earlier quoted context omitted.

Thanks for the feedback! We have avoided putting too many screenshots on the webpage since we made changes all the time initially. However, we are now ready to put screenshots. "I'll not book..."? I guess you meant "I'll book..."? =)

Actually it is "I'll not book". The time to make an impression on the user is while he is visiting your site.

Will you change it to “I’ll book” if I send you a Delibr T-shirt?

Re: Ask HN: Better tools for the software requirements / scoping phase?

#95

Post by fbonawiede »

ken wrote: post #83
fbonawiede wrote: post #49

Earlier quoted context omitted.

Thanks for the feedback! We have avoided putting too many screenshots on the webpage since we made changes all the time initially. However, we are now ready to put screenshots. "I'll not book..."? I guess you meant "I'll book..."? =)

No, nobody wants to spend 30 minutes to see if a vague description of some software might work for them. There's not enough hours in the day. There's about 20 products mentioned here already. That's more than a whole day of doing nothing but having someone try to sell me something which probably doesn't do what I'm looking for.

How about 10 minutes and you’ll get a Delibr T-shirt sent afterwards?

Re: Ask HN: Better tools for the software requirements / scoping phase?

#96

Post by ako »

beat wrote: post #63
mjul wrote: post #22

The underlying assumption with requirements is often not stated explicitly: that people _can know_ everything in detail, in advance. If that is the case, surely we can find better ways to uncover the requirements, and better tooling will help solve the problem. Experience tells me that people don’t know everything beforehand. Thus the key assumption is not valid. Then the question we should be asking is: how do we mo…

This is largely wrong. No, people cannot know "everything in detail, in advance". That doesn't mean that they don't know anything . They know a lot. Nobody with any actual experience in requirements-gathering expects 100% perfection. So the underlying assumption about the underlying assumption is wrong. After 20+ years in this industry, I'm long past believing the conventional wisdom that running systems are the best…

Core to agile is small incremental releases. Most technological innovation is done agile: in small releaseable increments. For example, We've been releasing small improvements for cars and planes for over 100 years. Every year a new model, with small improvements.

Humans are really bad at designing and building large improvements from paper requirements. Small improvements mean you understand most of the requirements are known and tested, and only small parts are uncertain.

The real problem is that testing requirements is really hard. You need to build the product to test the requirement. That's why most industries have an intermediate between requirements and product that is testable: this could be small scale prototypes, but more and more it's a virtual model that can be tested through software algorithms.

If we want to make real progress in the software industry, we need to move beyond word documents with requirements that are by definition not testable, to testable software models that don't require a full implementation. Low-code, model driven development is an example where this is happening.

Re: Ask HN: Better tools for the software requirements / scoping phase?

#97

Post by adrianN »

carlmr wrote: post #71
adrianN wrote: post #69

Earlier quoted context omitted.

I've found that writing (pseudo-)code is absolutely necessary to find problems in the requirements. Often enough the requirements are self contradictory or just contain too many unnecessary corner cases. I've seen requirements that sounded really simple in the requirement doc, but turned out to be extremely hard to test because they implicitly defined a state machine with dozens of transitions.

Especially because English is often a terrible language to express requirements.

Especially when it's written by people who aren't native speakers but work in a "we're a modern company now" environment.

Re: Ask HN: Better tools for the software requirements / scoping phase?

#98

Post by dotancohen »

fbonawiede wrote: post #94
dotancohen wrote: post #92

Earlier quoted context omitted.

Actually it is "I'll not book". The time to make an impression on the user is while he is visiting your site.

Will you change it to “I’ll book” if I send you a Delibr T-shirt?

I'll change it to "I'll book" because I see that you are seriously dedicated to the product!

I don't need the T-Shirt but let's respect each other's time and try to do it in ten minutes. You personally are invited to contact me at "fbonawiede at dotancohen dot com" but please do not add me to any mailing lists. Thank you.

Re: Ask HN: Better tools for the software requirements / scoping phase?

#99

Post by dolessdrugs »

beat wrote: post #76
gilbetron wrote: post #70

Earlier quoted context omitted.

The OPs statement isn't wrong, or even largely wrong, it is largely right. There was no statement of skipping all requirements gather, but skipping the idea that you can do one requirements gathering and have everything you need to develop the entire system. Your push back to waterfall development is driving me crazy - we already tried that for decades and you can only get it to (kinda) work with a ridiculous investm…

So the OP was fighting a strawman. Like I said, nobody out in the real world believes in pure waterfall anymore. Everyone knows that, realistically, a completely up-front requirements process doesn't do enough. But the quote agile unquote response is every bit as reactionary, and does happen out in the real world... "You guys start writing code, I'll go get the requirements". Writing code is expensive , even in agile…

"nobody out in the real world believes in pure waterfall anymore"

I'd allow that this might be true within large software organizations, this is definitely not the case where most software is written: in non-software organizations.

Re: Ask HN: Better tools for the software requirements / scoping phase?

#100

Post by SyneRyder »

duncanawoods wrote: post #48
SyneRyder wrote: post #21

Earlier quoted context omitted.

That looks intriguing, though I'd be more interested if it was a desktop app rather than a website. It reminds me a bit of Soulver, though Soulver is focused more on numbers & calculations: https://www.acqualia.com/soulver/

Soulver is very cool! We have lots of tools for calculations it's funny we have so few for reasoning. If beta-users find the web-app useful then I can release native apps but I must resist until its proven!

Ahhh, excellent! I definitely agree with proving the demand for an app before spending time expanding it. Great strategy!
Post reply on HN