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.


Functional and non-functional requirements

A functional requirement is something the product needs to work, perform an action and fulfill the purpose. It answers the question of “What does it do?”. They describe the minimal requirements of the product functionality. A non-funtional requirement is something that the product have to increase it quality. It answers the question of  “How does it do it?”. Non-functional requirements are extras made to improve the functionality of the product.

To be more precise, in software engineer, functional requirements define the functions of the system, is the description of the feature required. It also includes description of the required functions. Some examples of functional requirements are calculations, technical details, data manipulation and processing.

Non-Functional requirements focus on quality factors and effectiveness. These factors are what give value to the software and make the functional requirements function appropriately.


Some non-functional requirements may be:
1. Usability
2. Availability
3. Reliability
4. Flexibility
5. Supportability
6. Performance

References: (2016). Functional and Non-Functional Requirements. [online] Available at: [Accessed 13 Sep. 2016].

SearchSoftwareQuality. (2016). Functional vs non-functional requirements, what is the difference?. [online] Available at: [Accessed 13 Sep. 2016].

Application Programming Interfaces

Application Programming Interfaces (APIs) allow applications to talk to other applications, but that is just one small aspect of their true power. Websites, Mobile Apps, Buttons, Badges, Widgets, Spreadsheets and Devices are all benefiting from the power of APIs. API driven interactions allow you as an user to generate your own content, acquire API access to valuable data and pull content from API resources and  various databases.

Every time we visit a website or application we leave a digital footprint on them that helps them evolve based on our experience. With the innovation of all digital things, websites and applications have evolved to being generated through development software and software as a service platforms.

Machines just need a shorthand way to do things like checking the current weather or adding an event to your calendar.  That’s what an API provides.


APIs can be web-based, or specific to a platform.  Google has APIs for search, calendars, translations, etc.  Facebook and Twitter have APIs that allow software to automatically post status updates.  Apple provides many APIs for building iPhone apps.pexels-photo.jpg

You might think that APIs are very recent, but they’re not. The function of an API, at first, was to connect one program to another. Then in 2007 the iPhone was released and there the power or APIs got 10000 times bigger and more important, because thanks to the iPhone, mobile apps became part of our lives.

This video might help you understand APIs.


API Evangelist

What APIs Are And Why They’re Important

The waterfall method

The waterfall method was the first Software Development Cycle Model used widely in Software Engineering. In this method, the process of software development is divided into separate phases, the outcome of one of phase acts as the input for the next phase sequentially.

A representation of different phases of waterfall model.

SDLC Waterfall Model

The phases of the waterfall method are:

1. Requirement Gathering & Analysis: Ask the client what their needs and expectations are.
2. System Design: Requirements for the System and Hardware specification to define overall architecture.
3. Implementation: Program is developed in small units and tested (Unit Testing).
4. Integration and Testing: All units are put together and tested for faults and failures.
5. Deployment: After functional and non functional testing, the product is delivered.
6. Maintenance: Regular updates and issue resolving.

The advantages of using the Waterfall Method are:

  • Is easy to comprehend
  • Allows for departmentalization and control
  • Each stage can have a predetermined due time



Although, it has the disadvantage of being unable to go back if one of the steps has a mistake that was discovered in the next stages.

Tech Target. (2016). waterfall model. August 8th, 2016, from Tech Target Website: (2016). SDLC – Waterfall Model. [online] Available at: [Accessed 12 Sep. 2016].