• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Liutauras Vilda
Sheriffs:
  • Rob Spoor
  • Junilu Lacar
  • paul wheaton
Saloon Keepers:
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
  • Scott Selikoff
Bartenders:
  • Piet Souris
  • Jj Roberts
  • fred rosenberger

Non functional requirements

 
Ranch Hand
Posts: 904
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

If we summarize a projects lifecycle to:
Business goals -> Specification -> Architecture/Design -> Implementation

When would you start to discuss the quality attributes (modifiability, usability, performance ect.) ?

Is it possible to make the requirement specification without including any
considerations about QA's (ie. assuming perfect impl. platform), and only
think about it when your making the architecture of the system ?

Thanks in advance,

/Svend Rost
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Some of the "ilities" drive architecture from the very beginning. From recent experience ...

* Accessibility: App is used by "the public" or only by "a fixed number of captive users within the company" might drive browser vs fat client, security, firewalls, scalability, etc.

* Availability: "24x365, loss-of-life critical" implies a lot of redundancy, even geographic redundancy, maybe some tricks to deploy new releases without shutting down.

* Release requirements: "update functions for different groups of users on independent schedules" influences how you manage dependencies.

I think you were asking if the functional requirements - use cases and stories and such - can be done without much consideration of these QAs. I think so usually. But you really have to watch for the functional requirements analysis casually slipping in new QAs. A subtle change in wording about actors might change your whole scalability or availability plan.
 
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One way to look at development is not as a waterfall but instead as an evolutionary process. When you do this, the answer to "when should we consider X" becomes "when it is most appropriate, often just in time".

- Scott
 
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
RUP advises prototyping in the analysis phase to make sure some of the non functional requirements can be met. Iam not sure how viable this might be, but that atleast points out that we should start thinking about such requirements from the very early stages and ensure our design and choice of frameworks/tools/technologies are not going to pose an issue later on.
 
Scott Ambler
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
RUP doesn't have an analysis phase, but it does have an Analysis & Design discipline, the activities of which you perform throughout the project in an iterative manner.

You might be thinking of RUP's Elaboration Phase where you build an end-to-end technical prototype, or skeleton, of your system. This helps to address your major technical risks on the project.

For more details, the Agile Unified Process (AUP) product might be an interesting (and free) download.

- Scott
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Sabarish Sasidharan:
RUP advises prototyping in the analysis phase to make sure some of the non functional requirements can be met. Iam not sure how viable this might be, but that atleast points out that we should start thinking about such requirements from the very early stages and ensure our design and choice of frameworks/tools/technologies are not going to pose an issue later on.



Not only think, but also get feedback about your thoughts using a running system. Building the skeleton Scott mentioned and having your customer play with it might even uncover new non-functional requirements.
 
Ranch Hand
Posts: 214
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Deliver frequent, tangible, working results.
 
Svend Rost
Ranch Hand
Posts: 904
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Doing abit research on the topic shows, that some people thinks that
discussing QA with the customer in the specification phase is a vital
part of the specification/requirement phase. Others argue, that they
dont wish to put constrains up, by introducting the implementation
platform/discussing QA's - plus they feel that they know what the
user needs, QA wise.

I think that it boils down to the type of system your developing. For
instance, If I should develop a mission critical system I wouldn't choose
a "feed back method", but a "feed forward".. were I do develop a
system with uncertain demands, and little focus on QA's then an agile
method might be preferable.

/Svend Rost
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Svend Rost:
Others argue, that they
dont wish to put constrains up, by introducting the implementation
platform/discussing QA's



Discussing things doesn't put up any constraints, as far as I can tell. *Committing* to something does.

If I should develop a mission critical system I wouldn't choose
a "feed back method", but a "feed forward".



I wonder why. Looks to me like *especially* in mission critical projects you need to know when something's wrong as early as possible.
 
Svend Rost
Ranch Hand
Posts: 904
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:
Discussing things doesn't put up any constraints, as far as I can tell. *Committing* to something does.


I agree - I was merly reciting from an article.

Originally posted by Ilja Preuss:
I wonder why. Looks to me like *especially* in mission critical projects you need to know when something's wrong as early as possible.


It's true, that the earlier you get the information, the easier (and cheaper)
it is to make changes. A feed forward method doesn't exclude the use of
feedback. I've never worked on, for instance, a controller for a nuclear
power plant, but my guess is that
a) Your specification technieques should have a semantic (read: UML
might not be my first choice)
b) You need to consider things as early as possible... and not along the way.

/Svend Rost
 
Scott Ambler
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

a) Your specification technieques should have a semantic (read: UML
might not be my first choice)


Perhaps. It depends on your situation and on your toolset.


b) You need to consider things as early as possible... and not along the way.


Yes. Agilists do that. See AMDD's Initial Modeling effort. Agilists model and think things through before we build systems, we just don't waste our time with extraneous documentation.

- Scott
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Svend Rost:
It's true, that the earlier you get the information, the easier (and cheaper)
it is to make changes. A feed forward method doesn't exclude the use of
feedback.



Perhaps I don't understand what you mean by "feed forward"...

I've never worked on, for instance, a controller for a nuclear
power plant, but my guess is that
a) Your specification technieques should have a semantic (read: UML
might not be my first choice)



How does that connect to "feedback vs. feed forward"?

b) You need to consider things as early as possible... and not along the way.



Before you can only consider things you noticed. One (but not the sole) effective way of *noticing* what is important is to get feedback from an early running system.

Nuclear plants weren't designed by thinking everything through up front, they were designed by thought combined with many small experiments.
 
Svend Rost
Ranch Hand
Posts: 904
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for replying...

@ Scott:
ad a):
True. You can come a long way with "precision".

ad b):
Thanks for the link - interesting read. I guess I've made the wrong
assumptions about agile development.. I recall Robert C. Martin's
book Agile Software Development book stating that you should not "do" X
before you had a test stating the need for X.

I like the "Initial Modeling phase"; you state the mission of the
product, you have a descriptive (model the environment) diagram and a
prescriptive (design of the product).

@ Ilja:
1)
In a feed forward method you try to "engineer" the product, ie. you
try to predict alot of features about your product and it's environment,
plus you make assumptions. Please note, im not saying the waterfall
method is "the way" to develop software

2) it doesn't. Can't remember what my point was.. sorry

3) I agree. As a side note, this can ofcause be done on several levels,
on the "code" level, but also on a more abstract level by using
architectural prototyping.

/Svend Rost
 
Sabarish Sasidharan
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Scott Ambler:
RUP doesn't have an analysis phase, but it does have an Analysis & Design discipline, the activities of which you perform throughout the project in an iterative manner.

You might be thinking of RUP's Elaboration Phase where you build an end-to-end technical prototype, or skeleton, of your system. This helps to address your major technical risks on the project.

For more details, the Agile Unified Process (AUP) product might be an interesting (and free) download.

- Scott



Yes, analysis was not the right word. It should have been 'Inception' phase. Architectural Proof of Concept is a workproduct in Inception phase. Ensuring non functional requirements can be met is one of the possible reasons for taking up this proof of concept.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Scott, I'm curious, does the XP "System Metaphor" qualify as an initial domain model to you?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Svend Rost:
I guess I've made the wrong
assumptions about agile development.. I recall Robert C. Martin's
book Agile Software Development book stating that you should not "do" X
before you had a test stating the need for X.



That's true for the practice called "Test Driven Development" if you replace "do" with "write the production code for". You don't have to do TDD to be Agile, although it seems to help a lot.

IXP takes this even one step further: http://industrialxp.org/testDrivenManagement.html

I like the "Initial Modeling phase"; you state the mission of the
product, you have a descriptive (model the environment) diagram and a
prescriptive (design of the product).



I think "prescriptive" is the wrong word. The goal isn't to prescribe something, but to get a very rough first idea of what might be a good way to go - to get enough confidence to go the next step.

A better way than thinking something through and then commiting to a single solution is what is called "set based decision making" in Lean Software Development: Work in a way that you can make progress while keeping your options open as long as possible. Especially in risky areas, work on being able to easily switch to a different solution should your initial idea be proven to be inappropriate - or even try different solutions in parallel to find out which one works better for your project.

3) I agree. As a side note, this can ofcause be done on several levels,
on the "code" level, but also on a more abstract level by using
architectural prototyping.



Yes. But the "code" level - that is an actual running system - gives you the most accurate feedback, because it is the real thing. An abstraction from the code can have the advantage of being simpler to handle or understand, but always also has the risk of missing a critical detail. Therfore it's important to not fully believe in what your abstractions tell you, but to rapidly verify that the code "agrees".

By the way, there is an important difference to the building of nuclear power plants: I assume that the engineers of a nuclear power plants use a lot of simulations to get feedback about their ideas - software simulations, small models etc. But they don't primarily do that because it gives them better feedback than a real plant, but because building a fully fledged plant and having a plane crash on it or imitating an earth quake to see wether it survives is so much more costly. Doubly so if you want to do it a hundred times a day, every time you changed a tiny little detail in the blue prints.

In software development, that's a huge number of order of magnitudes cheaper. For many teams, it is daily routine.
 
Scott Ambler
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Scott, I'm curious, does the XP "System Metaphor" qualify as an initial domain model to you?



No. The system metaphor is more along the lines of an initial architecture model. Unfortunately, few teams actually get the metaphor concept. Instead they have a tendency to whiteboard the architecture instead.

An initial domain model looks like this.

- Scott
 
Ranch Hand
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Svend Rost:
Hi,

If we summarize a projects lifecycle to:
Business goals -> Specification -> Architecture/Design -> Implementation

When would you start to discuss the quality attributes (modifiability, usability, performance ect.) ?

Is it possible to make the requirement specification without including any
considerations about QA's (ie. assuming perfect impl. platform), and only
think about it when your making the architecture of the system ?

Thanks in advance,

/Svend Rost


I think QA is different for each entity. What is the quality of the Goals? What is the quality of the specification? What is the quality of the architecture/design? Waht is the quality of the implementatin?

You can't discuss meeting a requirement without discussing the acceptable +/- of that meeting. Which means you are discussing the quality.
 
pie. tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic