Non functional requirements.

-

How non-functional requirements makes a difference -

First of all  - what is functional requirements?

Functional requirement is what your product (or system) is supposed to do. A clear mapping of what the client wants as functionality from your application.

Let's understand it through a classic example -

Suppose you are purchasing a mobile. What are functional requirements? -
  • OS version? (Should be Lollipop)
  • Camera pixels? (More than 8 MP)
  • Memory? (should be microSD, up to 32 GB)
  • etc... 
Now let me ask you one question. Aren't all mobile companies give mobile according to your specifications? But why when you select a mobile for yourself. You get lots of suggestions from your friends and family that purchase Apple, or Samsung, or OnePlus? Is it because other companies don't build mobiles with that specification? Answer is NO. All companies have a mobile which belongs to different specifications/segments in general, all XYZ companies offers your functional requirements. 

There are non-functional requirements because of which you purchase Apple, or Samsung, or OnePlus, such as -
  • Brand value.
  • Robustness.
  • durability.  
  • Usability.
  • Price they offer.
  • look and feel.
  • Performance.
  • Status symbol.
  • etc.. 
Functional requirement like, I want a 12 MP camera which so many companies offer. Non-functional requirement of experiencing the same MP camera in Apple would be better than from any other mobile. 

Introduction -

A good designer always thinks about non-functional requirements. Now the question is how to understand non-functional requirements. I am listing out some points which may help you -
  1. Business needs - While understanding the requirement from the client. Try to understand what is the business need behind this functionality. Bring domain expert in conversation. That is why we have BA in SW team. If you know the business need behind the requirement, you will be able to design it better. The difference between a developer and designer is.                    "A developer knows WHAT, but a designer knows WHY we have to implement it."
  2. Cost - Estimate the cost of development. Keep in mind that non-functional requirements take more time to implement. If the client is not able to pay that much, then the designer cannot give all the services. Remember!!! what is the first word of CMMI. Its Capability (Capability Maturity Model Integration) CMMI5. Means we are capable of delivering CMMI 5 level solution. It can be a CMMI 1 or 2 level also. Depending upon the time, money, and effort we have put in to develop it. The company is capable of delivering CMMI 5 level. But it is not mandatory that it will always create a level 5 application that depends upon many factors, like how much time and money the client has given us to develop it.
  3. Time - You made a world-class product, but what if you have missed the market window? So even if some of the functionalities are not working correctly. But if you release your product on time with 70% working functionality. It's better to deliver it. Market will give you functional resonance if your product gets lunched when its in demand in the market. Simple demand and supply concept. Later on, we can fix the rest of the issues through patches and new releases. It is very common in the software industry :P).
  4. technical non-functional requirements - 

      • Performance.
      • Flexibility.
      • Usability.
      • Security.
      • Stability
        •
      • Modifiability.
      • Profitability.
      • Re-usability.
      • Integrability.
      • Testability.
      • Understandability.


Thanks for reading it. To learn more about design patterns and basic design principles, please see my web page.

Comments

Post a Comment

Popular posts from this blog

Non-virtual interface idiom (NVI)

-
In almost every cases, it’s recommended to follow OOAD principles, but sometimes we should try to look some other alternatives, provided by programming languages, which could be a better options for certain situations. In C++, we can implement virtual function in private and we can redefine its behavior in derived class's private  and it will work in same way(did you try that?). When we define virtual function as private and expose a non-virtual public function to outer world, we call it “ non-virtual interface idiom ”. Non-virtual public function will internally call virtual function, in other words you are not exposing your virtual function to client. You will achieve high encapsulation, plus we can add pre and post execution/condition in the body of non-virtual public function. Call some set of functions, as prerequisite of calling virtual function, and after call returns from virtual function, again call some set of function as part of post clean...
Read more

Factory method design pattern for beginners.

-
Image
Background - First, let me ask a simple question. Do you really think that "factory method design pattern comes because we had an issue with creating objects? Or it is only for creating objects? Or why we need a factory to create an object when we can create it through constructor? The answer is NO! Each class is capable of creating objects on its own. Through constructor (until and unless you have not put constructor in private).  Then why we need factory at all? Is there something like, without Factory method, I am not able to create my software? No, we can create objects without it, then why we are using it very extensively? Remember one thing, programming languages are very powerful . W e can build software without following any design principles. But then, it will be poor in some of these areas -  Maintainability. Extend-ability. Performance. Security. Robust. and many more... Developers have been developing...
Read more

Architectural patterns => Mud to structure => layers.

-
Image
Background - We apply mud to structure when a large system requires decomposition. If you notice, your application/requirement has verity of logical units which can be decomposed into a group of sub-tasks, first,  group them into different levels of abstraction. One abstract unit perform a totally different task(s) from other units, but any unit alone is not enough to give meaningful service to customer. Actually, different issues/solutions are splinted into different abstract units. Second,  after you divide them into different units, if you see a mix of low and high-level dependencies, where high-level operations depend on low-level operations, then assume those logical units as layers, third draw a dependency diagram between layers.  If control flows from high to low layer (or dependency diagram forms a stack, one layer on top of other), you can think of implementing it through layer pattern. Layer architecture - We can have many components in one...
Read more