Software Verification and Validation

Validation and verification are two different concepts in software engineering, each one can be abbreviated to the questions: are we building the right system? and are we building the system right?


Validation is concerned with checking that the software actually satisfies the customer’s needs and its objective is to demostrate that the product fulfills its intended use when placed in its intended enviroment, whereas verification is the process which checks if the software is functioning correctly and its objective is to ensure that work products meet their specified requirements.


The difference between Verification and Validation

Verification vs Validation

User Interface Design

User Interface Design focuses on anticipating what users might need to do and ensuring that the interface has elements that are easy to access, understand and use to facilitate those actions.

The reaction or the experience of the user when ising software doesn’t only depend on the functionality and the aesthetically design, what more influences the user to feel comfortable or not is the user interface.


Gestalt Design Principles

Similarity: occurs when objects look similar to one another.

Continuation: occurs when the eye is compelled to move through one object and continue to another object.

Closure: occurs when an object is incomplete or a space is not completely enclosed.

Proximity: occurs when elements are placed close together.

Figure and Ground: The eye differentiates an object from its surrounding area. a form, silhouette or shape is naturally perceived as figure, while the surrounding area is perceived as ground.


flickr photo by Isaac Kohane shared under a Creative Commons (BY-SA) license

Best practices for User Interface Design

  • Keep the interface simple
  • Create consistency and use common UI elements
  • Be puposeful in page layout
  • Strategically use color and texture
  • Use typography to create hierarchy and clarity
  • Make sure the system communucates what’s happening
  • Think about the defaults


Requirements Elicitation and Specification


Elic… what? that sounds complicated. Well, it actually isn’t. I’ve talked about functional and non-functional requirements before, but this is something completely different.

As you may remember, the first step of the SDLC is collecting infomation, requirements elicitation and specification are part of this step.

Requirement elicitation, is actually the first thing you have to do in the software life-cycle and is the practice of finding out what the customer or user wants. In an informal concept, is more like a wish list of requirements. But there are many problems that are almost impossible to avoid because it depends more of the customer, for example: he doesn’t know exactly what he wants, he thinks that some specifications are obvious or his needs changed and want the software to do something else.

Requirements elicitation practices include:

  • Interviews
  • Questionnaires
  • User observation
  • Workshops
  • Brainstorming
  • Use cases
  • Role playing
  • Prototyping

Once you know what the customer wants, you’ll be able to do the software requirement specification (SRS), which is a process of recording the client’s requirements in any form, like a document, a graphical representation, a graph, a pie, a cake, brownies, etc.

SRS also contains the functional and non-functional requirements and other specification types, for example: performance, maintainability, reliability, resource, etc.


History of software engineering

The first time the term “Software Engineering” was heard by a human being was in 1968 at a conference organized by NATO, to discuss the difficulties encountered when developing large and complex systems, It was proposed that the software development process should adopt an engineering approach to reduce the costs and to lead to more reliable software.

In the 70s the fist programming environments were developed, first notions of structured programming, the Pascal programming language, Parnas’s papers on information hiding and the development of Smalltalk, which introduced the notions of object oriented development. Early use of software design methods.

In the 80s the Ada programming language introduces structured programming and information hiding. CASE (Computer Aided Software Engineering) tools are introduced to support design methods, these tools are designed to increase the productivity and reduce the cost of software development. Development of algorithmic approaches to software costing and estimation, the first student textbook on software engineering is released. Later in the 80s OOP had a huge increase in popularity, through languages such as C++ and Objective-C. The first object-oriented design methods.

In the 90s Java is released. The rise of the Internet, international information, e-mail systems. Client – Server distributed architectures are widely used. Component-based software engineering (CBSE) is developed, it is a reuse-base approach to defining, implementing and composing loosely coupled independent components into systems. The Unified Modeling Language (UML) is proposed, integrating several separately developed notations for representing object-oriented systems. Sam Kass created rock, paper, scissors, lizard, Spock.

in the early 00s the use of UML becomes widespread, whereas the use of CASE tools declines. There is a huge increase of scripting languages, such as Python, for software development. C# is developed.  Inexpensive software solutions led to the development of simpler and faster methodologies for software development. Extreme Programming (XP) attempted to simplify many areas of software engineering.