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

81–90 of 104 posts

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

#81

Post by geezerjay »

zolthrowaway wrote: post #73
geezerjay wrote: post #47

Earlier quoted context omitted.

> There's a reason civil engineering isn't "Agile" There are plenty of reasons why engineering isn't "agile" and it's only usable in software development, and one of the main reasons is that software development projects manage a single resource: man/hours. Building the wrong or inadequate solution has its cost, but rebuilding something from scratch does not require additional resources to be allocated to the project…

I 100% agree with you. Software is "soft". Making changes to a code base is very cheap. Iteration just makes sense in software even for critical systems. If you build a suboptimal bridge, you have to live with it. If you write suboptimal software, you can test the actual product and fix it before you even ship. You can't really test a bridge outside of simulations. GP's comparison is apples to oranges in a lot of way…

> You can't really test a bridge outside of simulations.

Just to pick a few nits, actually bridges are indeed tested during and after construction. It used to be standard practice to do test runs with near limit loads to inaugurate bridges, consisting of getting a fleet of military vehicles or water tankers to cross the bridge while surveyors monitored the bridge's response.

Nowadays non-destructive testing techniques are favoured for a number of reasons, including the fact that sensor rigs can also be used throughout the structure's lifetime to help determine its fatigue life.

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

#82

Post by cosinetau »

Aren't there testing frameworks that were supposed to help solve this problem?

Maybe you could engage customers qualitatively, and translate that information into software requirements and acceptance tests? I'm not entirely clear how you want to engage these kinds of users.

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

#83

Post by ken »

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..."? =)

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.

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

#84

Post by chrisweekly »

chrisweekly wrote: post #40
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…

>"requirements are not a document by a process" by -> but

FTR this wasn't a grammar nit; these two different words in this context have opposite meaning! So, as a former teacher of English as a Second Language, I offered the substitution in order to help make the meaning clear.

Misguided downvote, imho. (shrug)

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

#85

Post by pbowyer »

mienski wrote: post #5

As someone that spends most of their days at the design/scoping phase, then watching the product go into development where it encounters constant misunderstandings and gotchas that the customer never told us about or never realised themselves, I completely agree that there is a huge disconnect between the scoping and requirements phase and the build phase. I almost have guilt over feeling like my work of design and s…

> My latest line of thinking is that I need a way to show the user interface, and then the data flow and logic all the way back through the system (usually a back-end DB or a customer legacy system).

Yes, this. It's what I've wanted as a software engineer and as a product manager. A unified overview.

I find the project materials become siloed, and cross-referencing is time-consuming, error prone, and not done enough. There is often a written spec, and a separate set of wireframes, with clickable areas to show interactions. Those two need to be merged together. Then a bunch of JIRA tickets, again separate. These need to be associated with the wireframes and the spec.

I have yet to find any system that makes this work.

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

#86

Post by a13n »

I run Canny (https://canny.io), which is a tool that software companies use to keep track of feature requests from their customers.

One awesome thing you can do is ping everyone interested in a feature, and ask them how they want it to work. See it in action here: https://feedback.canny.io/feature-requests/p/tags. (Scroll down to Sarah's comment on July 20.)

Whenever we're thinking about building a feature, we ping all the stakeholders. This gives us solid context on how they want it to work, which helps us define our MVP. If we need to follow up for more information, it's easy to do that via email / Intercom.

Hope this doesn't come off as salesy – I really felt it was relevant.

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

#87

Post by blackbrokkoli »

chrisweekly wrote: post #84
chrisweekly wrote: post #40

Earlier quoted context omitted.

>"requirements are not a document by a process" by -> but

FTR this wasn't a grammar nit; these two different words in this context have opposite meaning! So, as a former teacher of English as a Second Language, I offered the substitution in order to help make the meaning clear. Misguided downvote, imho. (shrug)

How do they have opposite meaning? Can I use "by" to declare A and B as opposites in such a context? (Trying to learn, I never heard the usage of "by" like this)

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

#88

Post by chrisweekly »

blackbrokkoli wrote: post #87
chrisweekly wrote: post #84

Earlier quoted context omitted.

FTR this wasn't a grammar nit; these two different words in this context have opposite meaning! So, as a former teacher of English as a Second Language, I offered the substitution in order to help make the meaning clear. Misguided downvote, imho. (shrug)

How do they have opposite meaning? Can I use "by" to declare A and B as opposites in such a context? (Trying to learn, I never heard the usage of "by" like this)

"not a (document [created] by a process)"

vs

"not a document but (rather) a process"

In the former (as OP typed it), it's grammatically suspect but also seems to imply a missing "created" like I inserted. In that case it'd be ambiguous whether the OP feels requirements are not documents, or perhaps they are documents, just not ones "by a process".

In the latter, which I took to be the intended meaning, OP is saying "requirements are a process, not a document."

The "not X but Y" is grammatical and clear, equivalent to (boolean pseudocode) "Y && !X".

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

#90

Post by repeek »

mjdease wrote: post #77
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…

Agreed, I've been on many projects where a client only had vague requirements and useful clarification only came in response to seeing the app. This is reasonable, it's human, but does anyone have a good approach to applying an iterative development approach on fixed price contracts? I've been on many fixed price projects that are "agile" in name only, general issues I've observed: - Iteration on requirements becomes…

In a past life as a project manager for a custom software consultancy, we had a rule of thumb based on experience that a functional prototype[0] takes about 25% of a total project's budget.

Whether the contract was time & materials (preferred) or fixed bid, that 25% rule worked well as an early indicator that the project was likely to go over budget. It allowed us to have early conversations with the client about cutting scope or expanding the budget to cover the unknown complexity.

We'd also dramatically increase our rate to reduce our risk on fixed price projects.

[0] Barebones, ugly, but functional from end-to-end.

Post reply on HN