Managing nonfunctional requirements: what? where? when?

- Software requirements/elements (features/classes) are tipically modeled either as a hierarchical set of components (FDD: Major feature set, Feature set, Feature) or as UML diagrams. None of these models can directly expose the relation/difference between functional and non functional requirements/elements. (Note: I do not know any methodology where "technical"/"business" would be base terms, eg. first class citizens.)
- Meanwhile many software projects are dealing with key/innovative and/or complex technologies. Thus I would say that non functional- or technical requirements may be good candidates for being managed components...

- What are the best practices for managing nonfunctional requirements within the FDD space? Is it an optional task?
- Are there any experiences from the following areas: heavyweight business domains implemented upon/using up-to-date technologies? ligthweight business domains implemented upon/using up-to-date technologies?
- Are complex/up-to-date technologies outside of PM scope (eg. they should be rather managed at company level and not project level)?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Jeff De Luca's picture

Try this previous thread.