Software Requirements…and stuff

As easy as it sounds, software requirements are requirements for software. But let’s dig a little bit deeper. Requirements are not only the functions required, actually this might be the least of the concerns in terms of requirements. Requirements must surpass all of the client’s expectations.

There’s even a science in charged of this analysis; and it is called Requirement Engineering its goal is to develop a very very very special and important document called the System Requirements Specification.

It involves mainly four steps, although there are text that claim it to be more than that and they are:

Feasibility Study: This is the initial stage. In this one, the requirement engineer must meet the client in order to talk about the general expectations. Then, he produces a very wide and thorough analysis on the possible constrains, implementation cost, and objectives. It also explores the technical aspects of the project wit the future always in mind.
Requirement Gathering: This is the solid, concrete and full list of requirements. Usually, this list contains the explicit requirements and specifications of the project.
Software Requirement Specification: This is the formal and official document I talked about in the introduction. This is a natural language document in which all the interactions must be stated. And by all, I mean it. Every single interaction between hardware and software must be in there. Cross-plattform specification, security, limitations, maintainability must be there too.
Software Requirement Validation: All the previous was never validated nor analyzed. In this stage, the document is impressively analyzed. All variables are taken into account, feasibility, ethics, security, ambiguities, cost and many others. This is the most important stage, because what is stated in this final revision is what devs are going to work with.

There are several types of requirements, (mainly two, read more

Continue reading →

Software Architecture

Software Architecture is the way software solutions are structured for all the project itself. Software architecture takes into account all of the aspects. It takes into account performance, security, quality and plenty of other stuff including the requirements asked by the client. Just as in a house or a building, software must have solid foundation. Not taking into account all of the requirements can lead to expensive delays. Delays might be the best-case scenario, because sooner or later, it’s going to be fixed, but if engineers just ignore the requirements, this can lead to unhappy customers that have poor, lame, and unstable software. Also, your job might be in a risk.

When designing the blueprints of the software you must take into consideration three things, the final user, the company goals, and the platform itself. And most important, they all have the same weight while taking decisions. There are no biased decisions in this topic. They all weigh the same because each one impacts the others in a certain way. For example, if the system is more complex, we might need the final user interface to be even more friendly due to the business requirements.

When designing the structure, the developers might want to take a look to the following questions.

How will the users be using the application
How will the application be deployed into production and managed?
What are the quality attribute requirements for the application, such as security, performance, concurrency, internationalization, and configuration?
How can the application be designed to be flexible and maintainable over time?
What are the architectural trends that might impact your application now or after it has been deployed?

When the project team has all of these answered, now, it’s time to begin. Once we all know all of the project

Continue reading →

UML: The Best Diagrams

1. Class Diagram

2. Activity Diagram

3. Deployment UML Diagram

In these type of diagrams, developers focus in the interaction between hardware and software. It is commonly used in network environments. It involves allof the harwdare equipment, from a single ethernet socket, all the way to racks from a data center, but it also involves databases, the software itself and many other things. This diagram is more useful when working with more than just code, and when you need interaction between hardware and software. Below you can find an example of a deployment diagram for a university.

4. Sequence Diagram

UML Developers finally understanding each other.

The Unified Modeling Language or UML for short is a standard graphical notation that is made up of sets of diagrams that illustrate what the software architecture of a certain system looks like, it is easy to read so any developer can take a look at it and have a basic understanding of the project.

The design and structure of the system is modeled with UML, it can be applied to any kind of application, independently of the platform used to build it, it is a tool that helps manage large and complex systems because it brings a clearly visible structure to the architecture and design.

Ola Løvholm - DMSP UML — Ola Løvholm –
DMSP UML

UML’s main purpose it to have a stable and common design language so applications can be build and analyzed by other developers, it is a sort of blueprint to software design and architecture.

One uf the main features is the use-case diagram:
It helps development teams visalize what the functional requirements of a system are and how they are related to each other.

Sources:

The Unified Modeling Language (UML)

An introduction to the Unified Modeling Language

History of software engineering

From its beginnings in the 1960s, writing software has evolved into a profession concerned with how best to maximize the quality of software and of how to create it.

How best to create high quality software is a separate and controversial problem covering software design principles, so-called “best practices” for writing code, as well as broader management issues such as optimal team size, process, how best to deliver software on time and as quickly as possible, work-place “culture”, hiring practices, and so forth. All this falls under the broad rubric of software engineering.

You’ve probably heard of the first widely used programming language — IBM’s Fortran — which was released in 1957 for mathematical and scientific computing. Another, Cobol, was released by the US Department of Defense in 1962 for use in business applications.

Over the following decades, the discipline of programming saw a familiar tension between the scientific thinking of academia, which tended to seek idealized solutions to engineering challenges, and the practical needs of an industry faced with real-life time and cost pressures (and bloated code bases). The early 70’s saw the emergence of key ideas in systems thinking which allowed engineers to break these giant projects into modular (and much more manageable) pieces that communicated via interfaces.

Non-functional requirements matter too

Defining requirements can be difficult because there needs to be a distinction between functional and non-functional requirements; however, both of these requirements are important to the system, and without them the system can crash or fail. The problem is when people miss these non-functional requirements, either they know about it or not.

What is a functional requirement?

Refers mainly to the expected function of the product. Product or system features, or what the program does is what the functional requirements are. Definitely it is easier to determine the functional requirements than the non-functional because they are almost obvious.

What is a non-functional requirement?

These requirements refer mainly to the attributes that include performance, security, usability, etc. Developers usually miss these requirements because they focus mainly on the functional requirements. When addressing incorrectly these non-functional requirements, the system actually fails. For example, the lack of usability or performance can lead to frustration or system problems. This is why non-functional requirements are so important for a system to succeed.

Example

Both of them are needed specifications.

References:

http://searchsoftwarequality.techtarget.com/answer/Differentiating-between-Functional-and-Nonfunctional-Requirements

What about the waterfall method?

Briefing:

Known as linear-sequential life cycle model, the waterfall method was the first process model to be introduced. Basically, no further phase can begin if the previous one hasn’t finished. This means that phases never overlap each other.

Model design:

To ensure the success of the project, the waterfall method was the first SDLC to be used. As a Software Development Life Cycle, it divides the process into phases, where the outcome of each phase works as an input for the next phase.

1. Requirements needed for the software to be developed.

2. Requirements are studied, and designing a system.

3. Inputting the design of the system, programs (or units) are created

4. All units are combined into a single system to test the software system.

5. The product is released into the market for customers to buy.

6. Release patches to fix issues in customers systems, enhance the functionality of the product.

Greatest benefits:

It is very simple to use and document. Also, each phase has a specific product and review process. Clearly defined objectives, goals, milestones, purposes, etc. Processes are easily arranged. Each phase is completed one at a time, which ensure success for that specific phase.

References:

http://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm

Software Engineering Historayyy lmao

Back in the good ol’ days where I wasn’t born and maybe you weren´t either, I’m talking about the 50’s and 60’s, software was delivered by hand and tested for a few hours before they could have the results back. The first widely used programming language was Fortran by your holyness IBM in 1957, along with Cobol, released by the US Department of Defense in 1962. But the processes of making software were still very slow and people accepted that they didn’t have the best methods, which led to something they called a Software Crisis, so in 1968 a conference was organized to find better ways of doing programming magic. At this conference is were the roots of Software Engineering were finally established.

Over the following decades, the discipline of programming saw a familiar tension between the scientific field, who gave the ideas of how to solve engineering challenges, and the crafty men that solved the practical needs of an industry faced with real-life time and cost pressures. Over the time more ideas came around, at the 80’s Object Oriented Programming came up as well as the use of GUIs to make interaction with the machine easier.

The next years leading up to these days the computing power of the machines programmers used was increased significantly, but many don’t see this as a good thing, because before you had to write code as efficiently as possible with the little things you had, and now with so much capacity and memory, the quality of code has been downgrading leading up to wasteful software. Even if this phenomenon is true, recent years have been when there has been such an incredible development in the software industries, with the introduction of the Cloud, APIs and almost every industry realizing that they needed online presence

Continue reading →

Application Programming Interfaces (API)

Natively, APIs are tools for other apps to communicate with each other. APIs started to grow since 2000. You might think that 16 years is a lot for technology growth. But APIs, natively, do the same stuff. The unique difference is that there are much more now, than 16 years ago. And obviously, they are much more complex, yet easier, to use.

Some famous APIs are developed by huge companies like Google, Facebook, Twitter…etc Google is a really diverse company, and guess what, it has an API for every single product they offer (Ads, Google Maps, Google Drive, Search, YouTube, Google+, and much more).

You might think that only huge Silicon Valley companies have APIs, but NO. There are plenty of smaller companies that also have their APIs available to everyone in the world.

APIs are one of the most important things when a new startup emerges, APIs allow developers to build something cool that might be useful for the startup product.

For example, Phillips Hue has their API available for making third-party apps that might exploit all the possibilities that Hue has to offer. There are awesome things you can try just by using an API.

APIs work for web, mobile devices, and computer software. You can use Amazon on your site, tweet from your site, and much more things you can do with the use of APIs.

When you are thinking about something awesome, and start worrying about how to implement it, believe me, there is an API for that.

With APIs, possibilities are limitless.

Easter Egg: Check out this amazing API for IBM’s Watson.

APIs

APIs (Application Programming Interfaces) allow interaction between applications or websites. Most of the current webpages have APIs and sometimes we don’t even notice that.

While having this type of “relationship” among websites,these are being enriched with the connection and interaction as the content interlinks and relates seamlessly.

At Kin Lane’s site, 101.apievangelist.com, there is ia huge explanation and analysis of the most commonly used websites back in 2014, which most of them are still part of the daily life of a tech-average person. He shows these sites have APIs working throughout the whole sites.

What is really interesting is how this analysis at some point may start to be obsolete, since most of the websites/apps that he describes have evolved and been modified already. Take a look at the following picture for example, Instagram back in 2014 compared to nowadays Instagram.

Almost everything has changed in the user interface that Instagram had compared to what it offers right now. Even the font has been tweaked a little.

What’s important about this is that back in 2014 and now in 2016, APIs were used throughout the web without any problem letting users experience a much easier way to interact with others and explore the internet universe.