1 / 7

Non-functional and functional requirements: are they equally relevant?

Non-functional and functional requirements: are they equally relevant?. Herwig Mannaert. Many Gaps in Software Engineering. Business <--> IT Theory <--> Practice Industry <--> Academics Architects <--> Developers Functional <--> Non-Functional …. Is there a mother or root gap ?

rossa
Télécharger la présentation

Non-functional and functional requirements: are they equally relevant?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Non-functional and functional requirements: are they equally relevant? Herwig Mannaert

  2. Many Gaps in Software Engineering • Business <--> IT • Theory <--> Practice • Industry <--> Academics • Architects <--> Developers • Functional <--> Non-Functional • … Is there a mother or root gap ? Can we build theory to bridge ?

  3. The Dream: Doug Mc Ilroy “expect families of routines to be constructed on rationalprinciplesso that families fit together as building blocks”from: McIlroy, Mass Produced Software Components, 1968 NATO Conference on Software Engineering, Garmisch, Germany.

  4. The Reality: Manny Lehman The Law of Increasing Complexity Manny Lehman “As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it.” Proceedings of the IEEE, vol. 68, nr. 9, september 1980, pp. 1068.

  5. Our Embryonic Theory: Stability • Applying the concept of systems theoretic stability to software evolvability, we demand that a bounded amount of changes has a bounded impact for an infinite time period and an unlimited system evolution. This leads to stable design theorems: rational principles. • In order to obtain stable building blocks, we propose the encapsulation of software entities into higher-level stable elements according to structures implied by the stability theorems.

  6. Stability theorems No stateless sync pipelines are allowed Calling an action needs to exhibit state keeping We do not have a theorem for this No stateless sync pipelines are allowed An action can only contain a single task OLTP commandments Do not lock a system resource too long Use transactions to clean up your mess Reuse resources across clients Come in, do your work, and get out Deal with large number of small things 1: Rational Principles  Performance

  7. 2: Building Blocks  Testing / Docs • The structured composition of entities into the higher-level elements can be described as “design patterns”, that are detailed, unambiguous, and parametrized. Therefore: • Both unit and integration testing of such a stable building block should become a trivial thing. • The complete and unambiguous documentation of the building block should consist of the documentation of this design pattern and the expansion parameters. • Example: CRUDS In order to obtain stable building blocks, we propose the encapsulation of software entities into higher-level stable elements according to structures implied by the stability theorems

More Related