*insert clickbait title here*

Okay, so you’ve come to my blog post. You want to know about software requirements elicitation and specification? Then stay with me.

I’ve talked about software requirements before, so what’s this deal with elicitation and specification, then?

First, let me explain the elicitation process. We start by gathering the requirements through discussions with the client and end users (through interviews, surveys, etc), then we make some sort of prioritization on these (through task analysis, etc). Now that we have all this, a discussion/negotiation with the stakeholders is made (here you might want to come up with some prototype to have more valuable feedback). At any point you might realize you have to go back to a previous phase to do modifications, or repeat them entirely. Everything must be documented.

Now, software requirement specification is supposed to be this document you create ONCE the requirements have been collected. This document will have specifications on how the intended software will interact with hardware, external interfaces, response time, limitations, etc. You can imagine things get pretty technical at this point, so it’s preferred that this document is written by some sort of system analyst. You’re going to want this document to be useful for the software development team, so…

This document’s appendix would hopefully look something like:

• user requirements in natural language
• technical requirements in structured language
• design description in pseudo code
• GUI screen prints
• conditional and mathematical notations

You definitely don’t want this to happen:

All this is meant to be valuable information upon which you’ll know what has to be accomplished. Even if done simultaneously with other phases of the project (agile) or all focus is put on this phase until it’s complete (waterfall), this phase is one you definitely don’t want to miss. Knowing what your users want and what they think of your product is vital.

If you want to take your readings any further, these were my sources:

http://www.tutorialspoint.com/software_engineering/software_requirements.htm

Would you drop your mouse for your eyes?

How long did it take you to click on this blog? You had to scroll your way with your mouse until you reached the clickable text, right? Or you clicked at it with your finger directly on the screen… On the other hand, how long did it take you to look at this blog’s title? Milliseconds. Yeah. That’s what I mean.

It’s now been over a decade that we’ve been using the computer mouse as a fundamental tool in our interaction with computers. It’s not the only way we point at things, though. Mobile phones, mainly thanks to the explosion the iPhone brought, have also taught us we can directly touch with our fingers on the screen. Augmented reality has also taught us to use the movement of our body, with cameras and motion detectors.

But, think about it. All these interactions I’ve mentioned need another type of interaction none of them are truly taking into account. Before you ever move your mouse, touch your screen or move your hand in the air, the first thing you do is point your eyes at that thing. What if we took approach of this very first thing everybody does? Eye-tracking technology. That’s what many predict the future holds for us all. A multimodal computer interaction.

What most of us have now in our pockets would have been considered a supercomputer 15 years ago. And the revolution’s not stopping anytime soon. “The general notion of pointing at things to navigate through a menu can be done in tens of milliseconds with you eyes versus the time it takes you to use your hands”, says Jim Magraff, CEO of Eyefluence, a company that now builds eye-tracking technology for AR and VR.

Communication with computers should be seamless, no delays nor interruptions. An “iPhone moment” could happen anytime soon with eye-tracking technology, with the potential propagation of multimodal human computer interaction. What do you think? Imagine how big a leap this would be for disabled people.

I can personally think of some very cool analytics you could do… Imagine if you could know which parts of your webpage people look at immediately, which hold their attention the longest, if they read through your blogs from beginning to end (though for you to be reading this far, you hopefully did! 😄). But, I can also think of some very obscure ways this could be used… Or even some annoying ones like an ad pausing yourself if you look away from it. You couldn’t help it but LOOK through the entire thing...

Have a look at this. I dare you not to use your mouse:

If you want to take your reading any further, this is the source I used:

https://techcrunch.com/2016/09/14/the-future-of-human-computer-interaction-will-be-multimodal/

Nonfunctional is worthy, too.

Okay, so you’ve most certainly heard about requirements before. At least you’ve read about it on my blog (please? 😢). And probably you don’t have the full mental image of actual requirements, because most requirements definitions only focus on functional requirements, actually.

These so called functional requirements are based on the expected functioning of the product/service. This is typically represented in features such as menus or buttons. Here is where you want to think about potential use scenarios. For most cases, though, if you fail to identify some nonfunctional requirements, you’ll have some trouble later. Trust me.

A milk container has the functional requirement of being capable to contain fluid without leaking. Of course, milk containers can also be used for other things:

Now, nonfunctional requirements are those regarding attributes such as performance levels, security, usability, reliability and availability. Here is where you you want to think about user narrative statements, acceptance criteria. When these factors are not taken into account, not even your perfectly well functional requirements will save you from some very unsatisfied resulting customers. This highly increases the chances of abandonment.

A hard hat has the non-functional requirement of not breaking under pressure of less than 10,000 PSI. Now, let me just say there are some pretty cool things you can do with hard hats:

And I don’t blame you, the fact that they’re called NONFUNCTIONAL requirements already makes you think it’s not worth of your time, as if nonfunctional meant pointless, secondary, negligible. I hope you’ve learned here otherwise. It might help to make a mental image of them more as “quality requirements”. That rings more the bell for most of us.

Functionality and quality don’t cancel each other out, in fact, they live as one in all successful software. Both functional and nonfunctional requirements are actually considered part of high-level design, as the two serve the purpose of product specification. Now you know the difference between functional and nonfunctional requirements, as well as some awesome things you can do with milk containers and hard hats ;)

If you want to take your reading any further, these were my sources: http://searchsoftwarequality.techtarget.com/answer/Functional-requirements-and-nonfunctional-requirements-in-software-engineering-explained

Hey, listen. Software Processes. Yeah…

You might get some idea from reading it. And you might not be too wrong. Not too much.

Officially, it’s the structured set of activities you do to develop a software system. This commonly involves the steps: specification, design and implementation, validation and evolution. Some sort of perspective of a process.

If you’re a reader of my blogs (Hi there, then!), you’ll find familiar some of the processes I’ll mention now.
There are also various different ways of executing these processes:

• plan-driven: All activities are planned in advance. Upon the realization of these, progress is measured.
• agile-processes: This one’s different. Cooler, in my opinion. Planning is incremental, so the process changes with respect to changing customer requirements.
• both: Yes. In reality, most real-world practices are done with a combination of the previous two.
• Waterfall model: Another plan-driven one. Although here, it’s typical to separate each phase of development.
• Incremental development: This one is also a combination. Specification, development and validation are over-lapsed. It’s not necessarily agile, though. It can also be plan-driven.
• Reuse-oriented: It’s assembled from existing components. Also, plan-driven or agile. You’re finding this weird already? Stay with me. Please :)

             

You see, it’s not like there are some wrong, never-do software processes. It really all comes down to each particular case. Let’s analyze some of these in more detail.

The waterfall method consists of, mainly, 5 different phases:

• requirements definition
• system and software design
• implementation and unit testing
• integration and system testing
• operation and maintenance

Now, don’t get too excited. This method’s most important weakness is that once the process starts, it’s very hard to go back (try going backwards in a real life waterfall!) some phases in case somethings needs to be changed. One phase must be completed before you move on to the next, also. You might think these so called “changes” would not be such a problem, but they can surely be. Customer requirements can change anytime, as they should. The circumstances around us define our needs, and none of them are constant. Neither should your software process.

That said, the waterfall method is used in some large systems engineering projects where development occurs at multiple sites. In this cases, this method can help coordinate the work.

Now let’s focus on the Incremental Development. This one’s a bit more merged than the waterfall. Also, much less analysis and documentation needs to be done. Mainly, because customer feedback is received in multiple steps of the process. This all leads to faster software delivery and deployment.

But as always, there are some downsides too. One of these is that it may not be very cost-effective to have continuous deliverables.

This process has the following stages:

• component analysis
• requirements modification
• system design with reuse
• development & integration

I hope you now have a different, wider view of what processes are, why we should make a careful analysis of which can be of better purpose to us and how these decisions can impact you and your team, overall.

Time to talk about APIs

This means Application Programming Interface, by the way. That may not help much, though. Even so, most surely you’re already using them every single day… Let me just mention you a few ways APIs involved in your daily activities: Facebook, Yahoo, Youtube, Amazon, Twitter, Pinterest, Reddit, Foursquare, Instagram, Pandora and even WhatsApp. Don’t tell me you don’t use any of these. There are widgets, buttons and badges everywhere making you pull and push content to other sites.

You might want to think of APIs as a wall socket. These electrical sockets are essentially interfaces to a service. You’re a consumer of this service. You don’t need to have your very own power source for you to be able to charge your electrical devices.

Now, back to reality, you use APIs as an interface to some other application/website service. You’re a user of this application/site. It’s through this API (make it widget, button, badge or whatever), that you don’t need to use the application/website as a whole, but only a small part for which the API was specifically made for.

There are even more detailed ways of having an API. A few examples: thermostats, smoke detectors, automobiles, clothing, glasses, etc.

And it’s logical. I mean, if you want as many people as possible to use your product/service, why wouldn’t it be a magnificent idea to split your product/service into tiny, functional, very specific parts (APIs) that can be implemented through other applications/websites or whatever; your users won’t have to be moving from one place to another to do as they desire. And that’s very, VERY important :)

Here I leave a video showing IFTTT (one of many API enabled orchestration platforms), a service that takes approach of many, many APIs out there and lets you combine them in practically infinite ways to do pretty much anything you want. Specifically, a video showing what 2 guys can accomplish in just one day of playing around with APIs. Enjoy!

Thanks for reading my blog, you're an awesome person.

If you want to read further, these were my sources:

http://www.programmableweb.com/news/what-is-an-api/analysis/2015/12/03#apiu#What Are APIs and How Do They Work?

http://101.apievangelist.com/