Starting software projects: Requirements

First of all, I’d like to emphasize that all post are based on my experiences, and all of them are addressed to students, people without experience developing software, or people who have never started a project for themselves and they don’t know how to start. I don’t want to expand on to infinite and beyond so with these post I try to summarize the process to start a new project focusing on the main elements.

In a previous post, I said that it was quite important to have a good document with all the software requirements about our new application. Right, how should we write this document up and don’t die trying? You just have to google and search SRS document, or Software requirements specification, or whatever synonym that comes to your mind. In fact, you could use one of the IEEE standards related to SRS documents:

  • IEEE 830-1998 – IEEE Recommended Practice for Software Requirements Specifications,
  • or more recently 29148-2011 – ISO/IEC/IEEE International Standard – Systems and software engineering — Life cycle processes –Requirements engineering).

But this process can be very complex or even it can take too much time. In my own experience, we could have a great SRS document just following this tips for each requirement:

  • The requirements should have an unique ID, such us REQ001, or if it’s a functional requirement RQF001 and so on.
  • The requirement should have a descriptive title, i. e., Application should provide a Login form.
  • The description of the requirement should be as extensive as possible, with all the details: we should describe what the requirement should do, how it interacts with the user, what possible errors could throw, how to deal with those errors, etc. A use case diagram may be useful.

For example, one of the most common requirements is a login form for our app (mobile or web). Therefore, we should write up our requirement as follow:

  1. REQ001: Users will login into the application.

1.1. Description

When an user starts the application, he or she must login to see the private area.

1.2. Step-by-step description

1) The user starts the application

2) The user should insert a username and a password.

3) The user should click the login button.

4) The system should check the username and the password inserted by the user against the database.

5) If the username and password exist, then the app will redirect to the private area. If it fails, the system will return an error indicating what’s wrong.

NOTE: An use case diagram may be attached here.

1.3. Functionality.

This requirements is useful to increase the security of the application. Only registered users will be able to use the private functions.

1.4. Technical Requirements.

  • The UI will be developed using AngularJS/Android/etc.
  • The communication with the server will be made using an API RESTfull.
  • The API REST will be developed using NodeJS and Express.
  • The data will be stored using MongoDB.

That’s it. Our first requirement is well defined. This kind of documents are useful if we want to define all the requirements before we start to develop. But if we want to follow an agile approach, we should write user stories and tasks instead of this kind of requirements. A user story has the following structure:

As a <kind of user>, I want <do something> so that <reason of what I am doing>

For example:

As a app user, I wan to login so that I can see my private area.

The developer responsible to work with this user story should create meaningful tasks, for example, “Develop login form”, “Develop login into the backend”, “Develop password encrytion method”, “Create method to store the user into database”, etc. These tasks should be as small as possible. Once the tasks have been defined, we should create a checklist (usually knows as Definition of Done) that includes all the items to be completed to indicate that the user story is done. An example of this kind of items are:

  • Check the acceptance criteria.
  • All the tasks has been developed.
  • All unit test has been developed and passed.
  • All E2E test has been developed and passed.
  • Developers have carried through with code reviews
  • User story accepted by product owner.
  • Automated unit test has run.

Both tasks and checklist should be discussed by the members of the development team. I mean with words and arguments, nor fighting. All the members of the team should come to an agreement peacefully.

In both cases, following a traditional approach or an agile approach, requirements or tasks should be sufficiently described for the developer and therefore the development process be simpler. Our requirements are defined, next step: design.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s