Functional Software Requirement Specification (FSRS) & Agile development

2.7k views Asked by At

i am on the way to learn how to lead a group of developers for projects in RoR using agile methodology. I have found some tools online like VersionOne or PivotalTracker, that can help you create iterations, backlog, stories, etc., so you can divide the work with the front and back-end, and make your developers focus exactly on a specific task.

My question is about the step before you start to use this Agile tools, create stories and iterations, and your developers start to make it grow on each one. My doubts are about the step of Technical, Functional and Non-Functional Software Requirements Specification, so after you have it clear, you can start writting up the stories:

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

Are there tools that can guide you how to convert the idea of web app (or mobile app) into a list of stories/iterations in a successful way? some kind of visual representation of states, features or functions (and its relationships) where you can specified functional, non-functinal and tecnhical specs, so after that you can create stories?

thank you very much for your time and patient in advance.

1

There are 1 answers

5
Aravind Yarram On

You have to change your thought process here.

A user story is one or more sentences in the everyday or business language of the end user that captures what the user wants to achieve. For e.g.

As a front desk representative, I would like to make a room reservation quickly.

As you can see they are

  1. From the user/role (front desk representative) perspective
  2. Goal oriented (make a room reservation quickly)

But they lack details like various flows (payment etc), acceptance criteria, non-functional requirement specific (what does quickly mean in the e.g. story?). You create sub-stories to provide more details.

What makes a good story?

INVEST : Independent, Negotiable, Valuable, Estimatable, Small, Testable


Are there tools that can guide you how to convert the idea of web app (or mobile app) into a list of stories/iterations in a successful way?

Tools like Rally and JIRA allow you to organize stories, sub-stories, sprints/iterations etc.

Some kind of visual representation of states, features or functions (and its relationships) where you can specified functional, non-functinal and technical specs, so after that you can create stories?

These tools provide rich text editors that help us write the stories. Sometimes you have a requirement that doesn't fit as a story

  • A use-case
  • User interface guidelines
  • A list of business rules etc.

Then write something else. Tools like JIRA provide provision for attachments.

so after that you can create stories?

** Stories should be the first activity that should happen. That is the whole point. It is not the after thought. Stories is the way of forcing you to think from a user and goal perspective so you are writing software to meet user goals. **

Stories represent requirements, they do not document them. - Rachel Davies


Agile approach encourages just enough architecture with continuous refactoring.

The sprint delivery team generally includes all the necessary stake holders like business analyst, tester, architect, dba, developers. They collectively are responsible completion of a story/sprint and at the end of the spring, you would have a production ready deployable application. Idea is to incrementally add features.

As you can see from the team composition architect/lead are also involved in each sprint. He, with the help of the team will architect and design just for the stories that are part of the current sprint/iteration (Just enough architecture, Emergent Design). The stories they pick for first sprint are either high risk or architecturally significant ones.

When it comes to design, mostly it is brainstorming and paper or black board based. Idea is to use code as the reference documentation as much as possible and build collective knowledge across the team by pair programming etc etc.

So you wouldn't end up with a poor quality software. You would in fact have the minimum code base that can exercise the stories (you are not accumulating code base for future requirements or nice to have features). Somewhere I read that only 40% of the features built are every used by customers.