Non-Functional Requirements

 Imagine you're finding a house. You have the blueprints which show the different rooms, hallways, and the overall layout of the house. These blueprints represent the logical components of your house, just like the components that make up a software system. However, there's more to a house than just the layout. You also need to consider other characteristics that will determine how well the house functions and meets your needs. Is it in a good neighbourhood, are there schools nearby, does it get 24 hours water (important if you are in Bangalore!!), does it offer good sunlight, etc. 

 

These characteristics are like the non-functional requirements or NFRs. NFRs are the system's capabilities that define how well it performs its intended functions. Just like a house needs to be sturdy, energy-efficient, and comfortable, a software system needs to meet certain requirements beyond its basic functionality.

 

We can think of NFRs as the "system's capabilities" that ensure it operates smoothly and effectively. These requirements can be explicitly stated in the system's specifications or can be implicit, like security, maintainability, or ease of use.

 

Some important NFRs or architecture characteristics to consider when building products in our world include: 

  1. Availability: How often the system should be accessible and functioning. Just like you expect your house to be liveable and habitable at all times, you want your software system to be available whenever you need it.
  2. Performance: How efficiently the system uses its resources to meet timing requirements. If your house takes too long to heat up or cool down, it's not performing well in terms of energy efficiency.
  3. Scalability: How well the system can handle an increasing number of users or workload without compromising performance. Just like a house needs to accommodate a growing family or changing needs, a software system should be able to scale up or down as required.
  4. Usability: How easy and intuitive the system is to use. A house with a confusing layout or poorly designed features would be frustrating to live in, just like a software system with poor usability can be frustrating for users.

 

When designing or requesting a software system, it's crucial to consider and prioritize the top 5 to 7 architecture characteristics or NFRs that are most important for your specific use case. Just like a homeowner would prioritize different features for their house based on their needs and lifestyle, the priorities for a software system will depend on the business problem it's solving.

Comments

Post a Comment

Popular posts from this blog

Logical and Physical Architecture

Image
  When you have defined the user stories (requirements) for a new system, the next step is to design the system architecture. There are two main parts to this: 1. Logical Architecture :  This is a high-level view of the system, focusing on the different components or building blocks needed to meet the requirements. It's like a blueprint for the system, showing how the different pieces should work together. ⠀For example, if you're building a system to report bugs, the logical components could be: * Ticket Creation * Ticket Assignment * Notifications (to the requester and resolver) * Communication (adding notes to the ticket) * Ticket Closure ⠀The logical architecture doesn't go into the technical details of how each component will be built. It just maps out what components are needed and how they should interact. 2. Physical Architecture:  This is the more technical view of the system, specifying the actual technologies and infrastructure that will be used to build the com...
Read more

Data Models

  When you think of system design,   Data Models   is a common term that you will hear. So what are Data Models? Very simply it is the way how data for a product or tech system is represented. And this represented ideally depends on the customer or the use case. Take the example of a car. One way to define a car can be to use the attributes like model, color, price, year of manufacture. Another way to define a car can be using attributes - License plate, owner name, history of accidents. If you are making a tech product for the use of a car buyer - then the Data Model 1 is more relevant and if you are making a tech system for the police, then Data model 2 is more relevant.  (One more reason to think customer backwards!!) . Broadly, there are three types of data models: 1) Relational; 2) Document; 3) Graph. The most well-known is the  relational data model . You can see this data typically in a tabular format where each row represents a relation. (SQL is a popula...
Read more

Deep Learning

Image
A few weeks ago, we discussed   representation learning , which allows an algorithm to automatically discover and learn the most useful features from the data itself (unlike classic machine learning that relies on human-defined features). However, representation learning has a limitation when it comes to intricate problems like voice or image recognition, where it becomes challenging to create a representation due to complexities. For instance, in speech recognition, accents pose a difficulty in representing them as a mere set of features. This is where deep learning steps in to solve this problem. Deep learning expresses the representation in terms of other simpler representations. For example, if we need to identify whether an image depicts a car or an animal, the first input to the model can be just the colors. These colors then serve as input to another representation of edges, which further feeds into contours, and so on, until after multiple layers, we can understand the type...
Read more