My Internship Experience…

Gathering Requirements Specification: The first steps

Developing a software requires you a work of a journalist, taking notes of details and maintaining a list of the functionalities and behaviors of the software to be developed. This is the first and main step of developing a software is when we gather the System Requirements, or all the details of the Business Logic of the software, to be translated later to a working Software.

In my first years as a Software Developer during my undergraduate university I used to ask the client about everything they wanted in the software. During an informal conversation, I used to get general information about the system and used to start coding from scratch without any sort of organization or even prioritizing what’s to be developed and worked. What was wrong on the perspective of Software Engineering was that I wasn’t keeping notes of the types of requirements. Furthermore, I was not used to use common Models and Languages, used by the community of software, to describe what my client wanted. So, I’m going to start the story about it, describing a better way to maintain the requirements specification during your development.

Requirements Specification

First of all you need to understand the needs of your client, the one who made the request for the software. Requirements are the most basic understanding about the business logics of the problem to be solved. That means, if your client wants to develop a software to control the library, you need to keep track of the books to be rented, the customers that borrowed the books etc. They start saying that this software must be online on the internet to let the customers search the available items 24h a day online, among other details. When you read theses small sentences, depending on how rich they are about the specification of the system to be developed, you need to extract the main ideas the client wants to tell you. Sometimes, they even don’t know what they want and keep changing functionalities, or does not understand about software at all. In order to start any software development, from the most basic to the most complicated one, is to create something called User Stories, followed by the list of Functional and Non-Functional Requirements. Later on, you have to represent the Functional Requirements using some kind of documentation tool such as diagrams, which most people (let’s say, stakeholders, developers, software engineers) can understand. Since it’s proved in the computer community that the use of conventions is the best way to transmit the ideas, it’s easy to use a language known by Unified Modeling Language, or just UML. In our problem, we would use the Use Cases Diagram to represent the basic functionalities of our system. We have to translate our requirements into those diagrams to better present our understanding to our clients. So let’s organize the general ideas and how to maintain and update them during the development cycle.

1. Start wit the interview with the client, taking notes of the functionalities they want on their system; It can be from a text that they provide, explaining the kind of system they want etc;
2. The next step is to create the user stories. These stories on the extreme programming world are created by the customers as explained on http://www.extremeprogramming.org/rules/userstories.html and used for different purposes. They are going to your own understanding about the software to be developed;
3. Create the list of Functional and Non-Functional Requirements, extracted during the interview and/or documentation provided by your client;
4. Represent these requirements using diagrams such as Use Case Diagrams
from UML.

So, What are the Functional and Non-Functional Requirements?

Functional Requirements are the basic functionalities of the system to be developed. We would extract these ideas from the text during our interview or in the text provided by the client. Sentences like “Only 5 books can be borrowed by the customer” are translated into a Functional Requirement. Moreover, negative sentences like “The user cannot login without confirming an email during the subscription” are considered functional requirements too. But they are considered different flows of information. This is to be related to the Use Cases Diagram, discussed on the next topic. For more information check

http://en.wikipedia.org/wiki/Functional_requirements

On the other hand, if you reads sentences like “The online store must be online 24/7 a day on the Internet” or “The system needs to respond to any request in 2 seconds”, we are talking about Non-Functional Requirements. They are specifications on how the system must work, not what the system does. So, pay attention to each sentence of the source of information for the software to be developed. There are more than these kind of ideas to be related to Non-Functional requirements. For more information, check

http://en.wikipedia.org/wiki/Non-Functional_Requirements

Use Case Diagrams

Use Cases are basically the ideas that you understand about the business logics of the software to be developed, translated into diagrams that are easy to read. They organize the general ideas of the functional requirements in a way that’s easier to identify the relationships between the list. Furthermore, it’s not only easy to maintain a list of the tasks related to each use case to solve each functional requirement, but also it’s a way to track the changes in your system requirement. The requirements are associated with Use Cases that relate the behavior or functionality. For more information about them, check

http://en.wikipedia.org/wiki/Use_case

Each Use Case are transformed later on components, in our case, Java components