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

11–20 of 104 posts

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

#11

Post by bpizzi »

Those days I just sketch wireframes in a Google Slides presentation.

Bonus point for the interactivity: I can share the URL for remote work sessions, and the stakeholders on the other end of the line can see me create/adapt wireframes and notes in real time, while I'm explaining everything on the phone (using anonymous access for those not logged into 'The Google').

Google Docs has version management since this year (I think), so I can pinpoint the evolution of specifications over the time. When I'm done I'll just export a PDF and attach to a "Spec done!" mail to everyone.

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

#12

Post by beaker52 »

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…

Can I suggest you involve your entire team in the discovery phase, meaning talking to the customer and interacting with the problem from the very start?

Shared understanding (passing what you've learnt on behalf of the rest of the team doesn't count) can help everyone, (including the customer!) understand the whys, whats and hows of their own problem space. Then as a whole team you can come up with and vet the solution - qualified by the deeper understanding everyone in the team has.

This deeper understanding will help you arrive at a better solution, wasting less time building the wrong thing and reduce the friction in "handing-off" to development (because there isn't a hand off).

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

#13

Post by meh2frdf »

Redsquare wrote: post #3

You can engage all stakeholders via a series of eventstorming sessions http://ziobrando.blogspot.com/2013/11/introducing-event-stor...

Engaging isn’t sufficient, it’s a start. What is typically lacking is someone with the intelligence to properly understand the problem, and map out a roadmap to get there. There is too often a naive belief that the stakeholders will put you on the right path, they don’t, they just give you information that feeds into the design process. Sure you solution should be regularly validated with the users, however in my experience the tend to lack the ability to give a vision which isn’t just an incremental improvement on the current solution.

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

#14

Post by mariopt »

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. People can still iterate on the problem with wireframes, even high fidelity ones, and speaking with customers, market research, etc.

There is a lot of value, time and money saved when you have a decent level of accuracy in the specification.

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

#15

Post by fbonawiede »

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

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

#16

Post by namdnay »

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…

It really depends on what you're building. There's a reason civil engineering isn't "Agile" - this also applies to major IT systems. A tiny difference in requirements can have massive impacts.

Honestly, in these cases, there's nothing better than waterfall, partly to save development time, but mostly for contractual protection: If a small change can cost millions more (and from experience, they can), you need to know who is responsible for paying those millions...

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

#17

Post by groestl »

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…

Software that is used, changes, because successful software influences the world around it, which in turn changes it's requirements. So typically, even if a team gets it right the first time (which by itself requires enormous effort), the once perfectly specified requirements will have changed shortly after release.

Edit: sibling is right as well, it depends on what you're building. Sometimes there is nothing better than waterfall.

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

#18

Post by roel_v »

beaker52 wrote: post #12
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…

Can I suggest you involve your entire team in the discovery phase, meaning talking to the customer and interacting with the problem from the very start? Shared understanding (passing what you've learnt on behalf of the rest of the team doesn't count) can help everyone, (including the customer!) understand the whys, whats and hows of their own problem space. Then as a whole team you can come up with and vet the soluti…

This here. Having someone who doesn't have to social skills of a house plant to talk to the customers, and then have the neckbeards in the back room code it up, is not the way to go, and nowadays I refuse to work with partners who work like this (or with subcontractors who want to force this workflow on me, and not limited to software dev either - I no longer work with e.g. building contractors who work like this either). And yes, I understand the point of specialization and division of labor, and yes in the past I too would have much preferred to just be the guy being handed perfect specs and never having to talk to anyone from the outside, and then when things go wrong there is always 'the spec' to blame. But it just doesn't work that way. In the past, being a 'business programmer' was called being an 'analyst-programmer'. I never really understood that, until I got to a point where I realized that the actual 'programming' (i.e., 'coding') is the easy part; it's the 'analysis' of the problem (well, and the formulation of a solution to the problem that comes out of that analysis) is the key to delivering value. But still, the relationship between the problem understanding, the solution and the implementation of that solution is so close that you just cannot completely separate them.

I interviewed a bunch of firms for building a website last year; nothing particularly fancy. Several of them (at least the big firms) send in a guy who would always start off explaining their 'process' (all fancy sounding), that process essentially being 'you tell me what your problem is, then we will together design a solution, and then I'll hand you off to our project manager back at the office who will just have the programmers implement it; you'll never even have to see these guys face to face!'. Uh sure, probably to 95% of your customers, naive and gullible because of lack of experience, that sounds great and like it's an advantage, but no way I'm going to get caught with my pants down 6 months from now because there was some aspect we didn't cover in the 'design' but the programmers coded it up like that anyway because hey it say so in the spec, right?

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

#20

Post by mping »

BjoernKW wrote: post #2

I agree that what you describe is a huge problem. I'm not so sure though if that problem can be alleviated by additional tooling. More often than not the cause of this is defective processes and assumptions rather than deficient tools. DDD, ubiquitous language and bounded contexts in particular, can be enormously helpful with defining better requirements. I'm not so sure about BDD though in this context. While the no…

Agreed, it's not about the tools, but the process. I've worked with different agile coaches - most of them were crap, but one of them really struck a chord in how he would find flaws on the organisation that would reflect on the software side. He was really good at devising strategies to overcome this.

To address the specific question, I think most of the time there's a problem because there is no one that takes care of making sure everyone has the same vision and understanding of what needs to be done. And because sometimes words fail us, I think mockups are a great way of uncovering and sharing requirements.

Post reply on HN