9 ms·

Agile enthusiasts really enjoy applying agile methodologies to functional requirements such as user stories. But non-functional requirements are rarely explici

Agile enthusiasts really enjoy applying agile methodologies to functional requirements such as user stories. But non-functional requirements are rarely explicit: security, reliability, redundancy, durability, concurrency, performance, scalability, configuration, deployment, documentation, logging, monitoring, supervision, maintainability, construction for verification... You don't get a user story saying: "as a user i would like my information to be private" or "as a user i would not like to experience a concurrency bug". To neglect those non-functional requirements in favor of perceived progress is not in the company's best interest. A solution that doesn't comply with those requirements also has a name: a functional prototype. There's a difference between developing production software and developing prototypes, even if you consider yourself agile. Now, as a software engineer, you should be able to identify these requirements and include them in estimations. You can also ignore them, and project an image of a highly productive engineer, but some day your code will crash and you won't have 10 days to fix it. That day you will be miserably fired to the sound of a trumpet.

robinwarren 11y ago
I think most successful agile teams would adopt those non-functional requirements not as tasks to be implemented but as cross-cutting concerns of all work. Ie, on a Scrum team they could be part of the Definition of Done, ie "Is the code maintainable" which would not allow some work to be considered completed until it met that definition. I'm not 100% clear on what you are saying but it sounds like you think agile teams ignore these non-functional requirements in favour of perceived progress on features. I think that may well be true in practice but it is also true of non-agile teams. It is in fact just true of immature development teams the world over. Being agile or not has nothing to do with it. Scrum and other processes do at least try to have something in place to cater for these requirements, which often sadly get overlooked when pressure is applied to make flat out progress on features.
- partycoder 11y ago
  I concur. But it was mostly in response to the article. I do believe though that there are many engineers that highly disregard good practices because they get a political benefit from releasing more. Just like politicians get appraisal when doing ribbon cutting at inaugurations, and never when repairing a bridge, many organizations promote the engineers that deliver more features, not the ones that keep the system working. By doing this they create a culture of technical debt and failure.
jacques_chester 11y ago
> You don't get a user story saying: "as a user i would like my information to be private" or "as a user i would not like to experience a concurrency bug". Uh, you do. You totally do. "As a User, I want the site to appear on my browser quickly". In acceptance criteria, "Quickly is defined as 98th percentile 400ms full roundtrip to AWS US-east-1". How do you do this? You write a test. What kind? A performance test. When does it run? Every time you check into CI. How is this different from standard agile practice? It isn't.
- zby 11y ago
  The quote is about 'privacy' and your user story is about 'speed' - these are different criteria and 'privacy' is much harder to specify in a user story.
  - jacques_chester 11y ago
    That's what I get for reading too quickly :) I focused on performance because that's one example I've had brought up several times. And it's probably the easiest one. I've seen privacy stories too. The style I like is to create a malicious user and deny them. As a Malicious User I want to steal credit card numbers So that I can sell them on the black market Given I have access to the web app When I supply malformed URLs I am ignored A/C Pentest tool with decent corpus Another approach, also used, is exploratory testing. Security and privacy are tricky because you're dealing with humans who can react creatively; so the best test is humans who react creatively.
- partycoder 11y ago
  A functional requirement is like adding a room to your house. A non functional requirement is defining what the construction material is and what the construction standards are. What you describe is like constructing a house, then once it is constructed, specify it needs to be earthquake resistant. That should be specified as an upfront requirement not a story. If you construct it, and it was already earthquake resistant, should not be a problem. But if it wasn't, you will need to rebuild.

robinwarren 11y ago

I think most successful agile teams would adopt those non-functional requirements not as tasks to be implemented but as cross-cutting concerns of all work. Ie, on a Scrum team they could be part of the Definition of Done, ie "Is the code maintainable" which would not allow some work to be considered completed until it met that definition. I'm not 100% clear on what you are saying but it sounds like you think agile teams ignore these non-functional requirements in favour of perceived progress on features. I think that may well be true in practice but it is also true of non-agile teams. It is in fact just true of immature development teams the world over. Being agile or not has nothing to do with it. Scrum and other processes do at least try to have something in place to cater for these requirements, which often sadly get overlooked when pressure is applied to make flat out progress on features.

partycoder 11y ago
I concur. But it was mostly in response to the article. I do believe though that there are many engineers that highly disregard good practices because they get a political benefit from releasing more. Just like politicians get appraisal when doing ribbon cutting at inaugurations, and never when repairing a bridge, many organizations promote the engineers that deliver more features, not the ones that keep the system working. By doing this they create a culture of technical debt and failure.

jacques_chester 11y ago

> You don't get a user story saying: "as a user i would like my information to be private" or "as a user i would not like to experience a concurrency bug". Uh, you do. You totally do. "As a User, I want the site to appear on my browser quickly". In acceptance criteria, "Quickly is defined as 98th percentile 400ms full roundtrip to AWS US-east-1". How do you do this? You write a test. What kind? A performance test. When does it run? Every time you check into CI. How is this different from standard agile practice? It isn't.

zby 11y ago
The quote is about 'privacy' and your user story is about 'speed' - these are different criteria and 'privacy' is much harder to specify in a user story.
- jacques_chester 11y ago
  That's what I get for reading too quickly :) I focused on performance because that's one example I've had brought up several times. And it's probably the easiest one. I've seen privacy stories too. The style I like is to create a malicious user and deny them. As a Malicious User I want to steal credit card numbers So that I can sell them on the black market Given I have access to the web app When I supply malformed URLs I am ignored A/C Pentest tool with decent corpus Another approach, also used, is exploratory testing. Security and privacy are tricky because you're dealing with humans who can react creatively; so the best test is humans who react creatively.
partycoder 11y ago
A functional requirement is like adding a room to your house. A non functional requirement is defining what the construction material is and what the construction standards are. What you describe is like constructing a house, then once it is constructed, specify it needs to be earthquake resistant. That should be specified as an upfront requirement not a story. If you construct it, and it was already earthquake resistant, should not be a problem. But if it wasn't, you will need to rebuild.