Functional and Non Functional Requirements

I’ve already wrote about the Software development lifecycle, in that post I mentioned the steps in the SDL, the first of those steps is Software specification. Is here when we define the requirements of our project, the requirements we define for it must be well thought. There are two kinds of requirements, functional and non functional, both are equally important and I’ll talk about them in this post.

 

Functional requirements

Functional requirements specify something the system should do, according to the SQA, they are a description of the required functions, outlines of associated reports or online queries, and details of data to be held in the system.

Some examples are:

  • Business Rules
  • Transaction corrections, adjustments and cancellations
  • Administrative functions
  • Authentication
  • Authorization levels
  • Audit Tracking
  • External Interfaces
  • Certification Requirements
  • Reporting Requirements
  • Historical Data
  • Legal or Regulatory Requirements

 

Non Functional requirements

On the other hand, Non Functional requirements describe how the system should behave SQA says they should have a description and, where possible, target values of associated non-functional requirements. Non-functional requirements detail constraints, targets or control mechanisms for the new system.

Some examples are:

  • Performance – for example Response Time, Throughput, Utilization, Static Volumetric
  • Scalability
  • Capacity
  • Availability
  • Reliability
  • Recoverability
  • Maintainability

 

The following video illustrates this topic really well, I recommend you to watch it.


Software development lifecycle

Fundamental Activities

There does not exist a unique or absolute software process, anyways there are some fundamental activities that are common to all software processes:

  1. Software specification. In this activity the functionality of the software and constraints on its operation must be defined.
  2. Software design and implementation. The software that meets the specification is produced.
  3. Software validation. The software must be validated to ensure that it has all the functionalities what the customer needs.
  4. Software evolution. The software must evolve to meet changing customer needs.

 

Software Development Paradigm

This are strategies that a developer can select to work in a specific project based on the requirements of the projects and the methods, tools and procedures of the paradigm. Some examples of paradigms are:

  • Waterfall model
  • Spiral model
  • Iterative model
  • V model
  • Big Bang model

 

 


Agile Development

In 2001, 17 software developers met at Utah to put together ideas they had on lightweight development methods. They agreed on 12 Principles that turned into “The Agile Manifesto”.

Agile software development is about doing things based in short term plans instead of spending a lot of time planning a big strategy. According to the Agile Manifesto individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan.

Scrum is the most common approach to agile development. It’s an alternative to the traditional waterfall method, as each process isn’t dependant on its previous process. All processes happen at the same time, quickly and in an interconnected, multifunctional matter. Then, after all processes are done, analysis and conclusions are reached and a whole set of new interactions can start.

If you want to know more about scrum you can watch the following video:

Agile development provides a way to know the direction of a project THROUGHOUT the development cycle, not before.

By: Carlos Martell and Lucía Velasco.


Is Software Engineering really Engineering?

To be honest, I didn’t understand this question until I googled it and found out that there are many people who think Software Engineering should not be considered as Engineering but as a craft. I read a publication by Bill Curran, a guy who thinks that SE has a misnomer. Apparently, early practitioners of Software Engineering wanted to call it “Software Physics” but the term was already taken.

After reading some more posts and discovering that some of they had a point. I decided to first know more about Engineering itself, so I could find whether SE was Engineering or not.

I read some definitions and I found a video made by the Faculty of Engineering and Built Environment at the University of Newcastle. It explains in four minutes and in an easy to understand and enjoyable way. You can watch it bellow.

According to the IEEE computer society SE is “The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.”

As an engineering student I think Software Engineers are truly Engineers.