5 ms·

Non-Functional Software

36 points by rfreytag 10y ago

taylodl 10y ago
Where I work we no longer use the term 'non-functional requirements', having replaced it with the term 'operational requirements.' We discovered the business was disinterested in discussing 'non-functional' requirements but are actively engaged in discussing 'operational' requirements. It's psychology, they equated 'non-functional' with 'not important to me.' That psychology cascaded down the entire development team: project managers, lead developers, QA analysts. Everyone but architects. Now everyone is on the same page recognizing the importance of these requirements and as a result we're doing a much better job implementing them.
- nickpsecurity 10y ago
  That's great. I like that. Terms that bridge how laypeople think and perceive with tech are the best.
- dragonwriter 10y ago
  That's a fantastic improvement in word choice that I plan to steal.
dahart 10y ago
> A pet peeve of mine is that libraries often don't document what thread a piece of code will run on. What's wrong with you people? ... Similarly, when is something blocking and when is it non-blocking? Totally agreed about blocking calls, if something's blocking and doesn't say so: boo. Usually boo if something's blocking at all, but I'm sure it depends. Threading ... is documenting "what thread code will run on" talking mainly whether the callback could happen on a different thread than the caller? Or is there some more specific language or context here?
- kazinator 10y ago
  Possibly, the concern is whether multiple callbacks from the API share the same thread, or is there a pool, or does it create a new thread? Can you keep that thread as long as you want without impacting the ability of that API to deliver callbacks to other contexts, or must you return that thread ASAP? Can the callback re-enter the API? If there are multiple callbacks pertaining to the same logical transaction do they use the same thread (so that I can, for intsance, lock a mutex in one callback and release it it another?)
- dozzie 10y ago
  > Totally agreed about blocking calls Sorry, where are you coming from again? Most of the languages out there use blocking call semantics, it's non-blocking (a.k.a. asynchronous) calls that are rare.
awinter-py 10y ago
hmm -- confusing to use 'requirements' for software behavior required by users as well as dependency behavior required by the software. Is the author just saying we should have a spec for software? Ok but that's a different blog post.
- ozten 10y ago
  The usage of the term 'requirements' is traditional in the software development industry. It may be unusual for many teams, but it is common in the literature as well as larger, older organizations.
- tyingq 10y ago
  Confusing to me as well. Generically, he's saying that "non functional" requirements should be documented at least as well as "functional" requirements. But then his example isn't really a "non functional requirement". The example is basically saying that implementation details/choices that might have an impact should be documented. An example of an actual non-functional requirement would be some specific, defined, metric for privacy, performance, etc. ( vs an implementation choice...blocking vs non-blocking, method creates a new object under the covers, etc)

36 points by rfreytag 10y ago

Where I work we no longer use the term 'non-functional requirements', having replaced it with the term 'operational requirements.' We discovered the business was disinterested in discussing 'non-functional' requirements but are actively engaged in discussing 'operational' requirements. It's psychology, they equated 'non-functional' with 'not important to me.' That psychology cascaded down the entire development team: project managers, lead developers, QA analysts. Everyone but architects. Now everyone is on the same page recognizing the importance of these requirements and as a result we're doing a much better job implementing them.

nickpsecurity 10y ago
That's great. I like that. Terms that bridge how laypeople think and perceive with tech are the best.
dragonwriter 10y ago
That's a fantastic improvement in word choice that I plan to steal.

dahart 10y ago

> A pet peeve of mine is that libraries often don't document what thread a piece of code will run on. What's wrong with you people? ... Similarly, when is something blocking and when is it non-blocking? Totally agreed about blocking calls, if something's blocking and doesn't say so: boo. Usually boo if something's blocking at all, but I'm sure it depends. Threading ... is documenting "what thread code will run on" talking mainly whether the callback could happen on a different thread than the caller? Or is there some more specific language or context here?

kazinator 10y ago
Possibly, the concern is whether multiple callbacks from the API share the same thread, or is there a pool, or does it create a new thread? Can you keep that thread as long as you want without impacting the ability of that API to deliver callbacks to other contexts, or must you return that thread ASAP? Can the callback re-enter the API? If there are multiple callbacks pertaining to the same logical transaction do they use the same thread (so that I can, for intsance, lock a mutex in one callback and release it it another?)
dozzie 10y ago
> Totally agreed about blocking calls Sorry, where are you coming from again? Most of the languages out there use blocking call semantics, it's non-blocking (a.k.a. asynchronous) calls that are rare.

awinter-py 10y ago

hmm -- confusing to use 'requirements' for software behavior required by users as well as dependency behavior required by the software. Is the author just saying we should have a spec for software? Ok but that's a different blog post.

ozten 10y ago
The usage of the term 'requirements' is traditional in the software development industry. It may be unusual for many teams, but it is common in the literature as well as larger, older organizations.
tyingq 10y ago
Confusing to me as well. Generically, he's saying that "non functional" requirements should be documented at least as well as "functional" requirements. But then his example isn't really a "non functional requirement". The example is basically saying that implementation details/choices that might have an impact should be documented. An example of an actual non-functional requirement would be some specific, defined, metric for privacy, performance, etc. ( vs an implementation choice...blocking vs non-blocking, method creates a new object under the covers, etc)