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

51–60 of 104 posts

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

#51

Post by pronouncedjerry »

fbonawiede wrote: post #15

I'm a co-founder of a Swedish startup, and we have built a tool targeting product owners and product managers. It aims to eliminate endless email threads and disconnected workflows that are common in product development. It sort of replaces Word, Google docs, and Confluence and integrates with Jira and Slack. I would be happy to give you a quick demo! https://www.delibr.com/demo

I was introduced to this last week and I am going to try it on my next project. I see it superior to Google Docs for this use case.

edit: looks like you have an admirer https://thorny.io/

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

#52

Post by crdoconnor »

mariopt wrote: post #14
hyperpallium wrote: post #10

This was the inspiration for "Extreme Programming": You make a minimal cost mockup ASAP, for the client to try out, to see if it's what they wanted. Clients can't appreciate requirements, so (like, actual) architects make a scale model first. The alternative, of doing requirements as a separate phase, was ridiculed as the "waterfall model". In reality, there's interactions between the so-called phases of req, spec, d…

> What's the point of spending the time and money on beautiful engineering, if it's going to be scrapped tomorrow anyway (or even before it's finished)? Good luck maintaining that code. Don't forget about the team, a messy codebase and/or poor requirements, eventually, will break a team's morale until the day news devs come along and demand a refactor. I start to love the idea of a waterfall model for software. Peopl…

This was the exact attitude I held for the first 5 years of my career until I realized that:

* There's a ridiculous amount of code that either gets tossed or goes almost totally unusued and time spent on beautiful engineering on that is 100% waste. This is, I think, why languages with incredibly strict type systems that try to 'force' good design up front never end up being widely deployed. They make prototyping way too expensive.

* Only juniors demand to rewrite or refactor anything. Being a really good developer means being able to figure out creative ways to fix the most enormous technical debt incrementally and knowing that you shouldn't ever have to 'demand' to do that because you can just do it.

* Pretty much every project I've ever seen that does anything useful starts out with nasty code because the programmers who worry about making it beautiful before it's useful never make it useful to begin with.

* People who dream up architecture before writing the code dream up the worst architectures. The best architectures, on the other hand, happens as a result of a lot of time spent tediously refactoring code.

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

#55

Post by mysterydip »

Pamar wrote: post #39
mysterydip wrote: post #30

I recently took a model-based systems engineering course that opened my eyes to some helpful methods. Use UML, SysML, etc to diagram out your requirements (starting at high level at first, more granular as the system matures). Now build a high-level model of your system design (software and hardware if required). Match parts of your system to the requirements. This lets you see gaps in two directions: requirements yo…

UML? Really? Most Business Users want to discuss the UI and (if you are lucky) the data structures, two things that UML is not really very concerned with. In my experience, UML has been a really bad choice to work on requirements for corporate sw.

Agreed, it's not what business users want to (or should) see. This is an aid for what your team does internally, instead of just lists and documents.

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

#56

Post by sailfast »

Many people have said this but here goes anyway: The tooling will not help you better define the specifications. The tooling will not help you manage changing specifications. You can cover all the bases easily in a free Github project (Edit: pick your web-based tool, basically) without too many issues.

I would argue that the reason things get called out as poorly defined or change is because risks are not addressed early, and hypotheses are assumed to be theorems.

Make sure your teams test the main assumptions early, with actual code if at all possible. That will call out why your stories aren't clear enough.

Tools are useful, but they won't solve your problem.

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

#57

Post by ryanmarsh »

The solution to a “complex” problem is only knowable after the fact, versus merely complicated problem which is knowable before the fact. Any sufficiently useful computer program is typically “complex”, though not always.

That said it is still incredibly helpful for everyone to agree on what we’re building in the present iteration/sprint. You mentioned BDD which can be very helpful when paired with a team practice such as Example Mapping[0].

Other practices such as DDD can help you bound the problem and define it. Also there are some helpful lessons in Feature Driven Design.

Source: I teach BDD workshops for a living

[0] https://cucumber.io/blog/2015/12/08/example-mapping-introduc...

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

#58

Post by motohagiography »

I've been doing a variation of this for security, as it's the main need that requires abstraction-on-down definition, and it doesn't translate well into agile environments where developers are designing solutions. (qtra.io, in private beta, so no free experience yet)

The fit problem I'm having is getting technical threat hunters who populate the market to think about risk and security design, or product/project managers to reason even high level about a domain they delegate to technologists.

Still iterating for fit, but so glad there is a thread of people thinking about architecture.

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

#59

Post by a_dantorp »

pronouncedjerry wrote: post #51
fbonawiede wrote: post #15

I'm a co-founder of a Swedish startup, and we have built a tool targeting product owners and product managers. It aims to eliminate endless email threads and disconnected workflows that are common in product development. It sort of replaces Word, Google docs, and Confluence and integrates with Jira and Slack. I would be happy to give you a quick demo! https://www.delibr.com/demo

I was introduced to this last week and I am going to try it on my next project. I see it superior to Google Docs for this use case. edit: looks like you have an admirer https://thorny.io/

Google docs on steroids! ;-)
Post reply on HN